LinkedInTwitterFacebook

Roadmap TSM 6.3.4 (et bientôt 7.1) : les nouveautés prévues pour cette fin 2013

Par Gabriel | Publié le 2 août 2013

Lors du dernier Pulse Comes to You 2013 (PCTY2013), IBM a évoqué quelques nouveautés très intéressantes qui devraient selon toute vraisemblance apparaitre d'ici à la fin de l'année 2013.

Cross Server Migration 5.x > 6.x

Possibilité de migrer la DB d'un serveur vers un autre serveur fonctionnant sous un os différent.

Cela est actuellement impossible et offrira une plus grande flexibilité au nouveau des plateformes matérielles cible lors des plans de migration de TSM 5.x vers TSM 6.x

  • AIX -> Linux x86_64
  • HP -> Linux x86_64
  • Solaris -> Linux x86_64
  • Linux pSeries -> AIX
  • Solaris ->Linux x86_64

VMware : accès et récupérations instantanées

Nouveauté longtemps réclamés par les administrateurs VMware : la fonction d' "Instant Access & Recovery".
Il sera possible d'accéder directement depuis les pools de stockages à une VM sauvegardée.

VMware Instann Access
Cliquez pour agrandir l'image.
  • RPO améliorés
  • Possibilité de tester une VM directement depuis ses sauvegardes TSM

Autres nouveautés

User experience

  • Nouvelle version de la console d'administration graphique de TSM et reporting amélioré
Cliquez pour agrandir l'image.
  • Simplification des outils de protection TSM pour VMware
  • Installation améliorée du serveur TSM et de ses principaux composants

Virtualisation

  • Support d'Active Directory
  • Restauration granulaire d'une DB pour SQL
  • Restauration granulaire niveau objet pour Exchange (mails, contacts, agenda, ...)
  • Reporting optimisé et simplifié

Disaster Recovery

  • Réplication avec bascule et reprise automatique transparente des nodes en cas de sinistre
  • Réplication de tous les paramètres des nodes (informations, options, planning)

Divers

  • TDP for Exchange : support de Windows 2012
  • TDP for Domino : support de Windows 2012, 64-bit Solaris SPARC et de Domino 9
  • TDP for Oracle : support de Windows 2012 et de Oracle 12c
Posté dans la catégorie : TSM | Tag , , | Commentaires fermés

Avertissement : taille des blocs et lecture/écriture sur bandes LTO

Par Gabriel | Publié le 31 mai 2013

Fonctionnement

Lors des opérations d'écriture et de lecture sur des cartouches LTO Tivoli Storage Manager utilise une taille de blocs spécifique.

Cette taille est par défaut différente selon le type de HBA utilisé.

Exemple :
- SCSI : 64 KB
- FC : 256 KB

Description du problème

La conséquence directe de cette spécificité et que vous ne pourrez par exemple par lire une bandes LTO écrites par un lecteur FC sur un lecteur SCSI ! Cela est du à la taille maximum des blocs qu'est capable de lire ou d'écrire l'adaptateur en question.

Cela peut se révéler assez pénaliser si vous prévoyez par exemple, lors d'une opération de migration, d'utiliser temporairement un lecteur SCSI afin de lire vos cartouches générées depuis un système FC.

Vous obtiendrez alors l'erreur suivante au niveau de l'ACTLOG de TSM :
ANR8939E: L'adaptateur de l'unité de bande nom d'unité ne peut pas gérer la taille de bloc requise pour l'utilisation de ce volume.

Solution

Pour résoudre le problème vous devrez mettre à jour l'adaptateur afin qu'il soit en mesure de gérer une taille de bloc plus élevée. Ce paramètre est déterminé par MAXIMUMSGLIST

Windows :

HKEY_LOCAL_MACHINE->SYSTEM->Current Control Set->Services->{nom_unité_fournisseur}->Parameters->Device

"{nom_unité_fournisseur}" correspond au nom de l'unité du fournisseur. Par exemple, pour Qlogic 2200, le nom de l'unité du fournisseur serait "Ql2200".

La valeur de MAXIMUMSGLIST doit correspondre à la valeur hexadécimale de 41 pour que le bon fonctionnement de Tivoli Storage Manager soit assuré.

Vous pouvez aussi exécuter l'utilitaire DSMMAXSG pour attribuer la valeur 0x41(65) à MaximumSGList pour toutes les cartes de bus hôte (HBA).

Pour plus de détails, reportez-vous à la documentation de la carte de bus hôte (HBA) ou prenez contact avec le fournisseur de cette carte.

Posté dans la catégorie : TSM | Commentaires fermés

Comment fonctionne la réclamation hors site de TSM?

Par Jean-xavier | Publié le 27 mars 2013

Question

Comment fonctionne la réclamation hors site de Tivoli Storage Manager?

Réponse

La gestion hiérarchique des espaces de stockage a toujours fait partie de l'ADN de TSM.

Les espaces de stockage disque étaient plutôt restreints et utilisés uniquement comme "buffer" avant que les données ne soient migrées vers un espace de stockage bande. Ce principe de fonctionnement est toujours d'actualité avec les versions récentes de  TSM.

Dans le cas de la reclamation hors site, le traitement ne porte pas sur les bandes de copie hors site mais plutôt sur les volumes primaires.

Par exemple, prenez 2 volumes CPY1 et CPY2 hors sites prêts à être reclamés car ayant atteint le seuil  fixé par le paramètre PCT_RECLAIM. Tivoli Storage Manager va générer une liste de tous les volumes appartenant à l'espace de stockage primaire et qui contiennent des objets avec des copies non expirées sur les volumes hors site ; Ce sont ces derniers que le serveur va expirer.

Partons du principe que CPY1 a 4 copies : A, B, C, D  et CPY2  : E, F, G, H. Le serveur va créer une liste de volumes de l'espace de stockage primaire qui contiennent les fichiers A-H. Cette liste peut contenir un grand nombre de volumes. Le serveur va ensuite traiter chaque volume primaire un par un.

Donc, imaginons que le volume PRI1 contient les fichiers B et G. Le serveur va monter le volume PRI1 et copier les fichiers B et G sur un nouveau volume de copie (pour remplacer celui que le serveur essaye de réclamer). Il est possible que la liste de volumes en entrée soit consequente et ce n'est qu'une fois cette dernière entièrement traitée que le volume CPY1 devient "vide".

Si le process de reclamation est annulé avant la fin, il est possible qu'un grand nombre de fichiers de chaque volume hors site ait été traité mais pas tous. Il en resulte qu'un nombre limité de volumes hors site (voir même aucun) n'aient été libérés, même si la reclamation a tourné pendant de nombreuses heures.

C'est pour cette raison que la commande QUERY PROCESS ne renvoie pas quels volumes hors site sont traités car le serveur ne traite pas les volumes hors site, mais seulement les volumes primaires. Ce n'est qu'une fois tous les volumes primaires traités que tous les volumes hors site seront reclamés en fonction du paramètre du storage pool de copie PCT_RECLAIM. La liste des volumes de copie hors site à traiter est mentionnée dans l'ACTIVITY LOG au lancement du processus de reclamation.

Il existe un paramètre permettant de libérer des bandes scratch plus rapidement en limitant le nombre de volumes de copie hors site à traiter, il s'agit du paramètre OFFSITERECLAIMLIMIT. Limiter le nombres de volumes de copie réduis le nombre de volumes primaires à traiter. Cependant réclamer l'intégralité  des volumes nécessitera un plus grand nombre de processus et de ce fait un plus grand temps de traitement. Paramètrée correctement, cette valeur permet de vider les volumes les moins remplis plus rapidement.

Cela peut prendre un peu de temps avant de pouvoir determiner la valeur optimale pour ce paramètre. Commencez par le fixer avec une valeur réduite, 5 par exemple. Si la reclamation ne permet pas de vider 5 volumes dans un laps de temps acceptable alors diminuez ce paramètre à 4 et continuez jusqu'à ce que le processus de reclamation se déroule correctement pendant la fenêtre qui lui est impartie. Il est toutefois possible d'augmenter  le nombre de volumes hors site à traiter pour optimiser le traitement.

 

Source IBM 

Posté dans la catégorie : TSM | Tag , , , | Commentaires fermés

TSM et le cryptage des données

Par Gabriel | Publié le 15 mars 2013

Depuis la version 4 du client de sauvegarde, TSM permet de crypter les données à la source. La confidentialité est ainsi renforcée car les données sont transférées et stockées de manière cryptée.

Comment activer le cryptage sous TSM ?

L'activation du cryptage se faire directement depuis le client TSM.

Activation et sélection du type de cryptage à travers le GUI du client TSM 6

Il faut ensuite créer des règles d'inclusion afin de préciser les données que vous souhaitez crypter.

Sélection des fichiers à crypter

La dernière étape consiste à réaliser une première sauvegarde manuelle afin de saisir le mot de passe de la clé de chiffrement.

Le mot de passe de la clé de chiffrement

Le cryptage est assuré par la saisie d'un mot de passe de clé de chiffrement depuis le client TSM lorsque vous sauvegardez des données cryptées pour la première fois. Pour cette raison il est impératif d'effectuer une première sauvegarde de manière manuelle.

Saisie du mot de passe de clé de chiffrement

Une fois le mot de passe saisi il sera stocké sur votre système de manière cryptée.

Vous pourrez par exemple le retrouver sous Windows dans la base de registre sous la clé : HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\votre_node\votre_serveur_tsm. Sous Linux et Aix la clé est stockée dans le fichier TSM.PWD qui se trouve dans le répertoire d'installation du client TSM. Cette clé vous sera demandée lors d'une restauration de vos données depuis un autre poste physique ou si votre base de données ou votre fichier TSM.PWD ont été corrompus.

Attention :
Il est vivement conseillé de ne pas oublier ce mot de passe et de le copier en lieu sur et de manière pérenne. En cas d'oubli vous pourriez ne plus être en mesure de restaurer vos données !

Des questions ?

Vous avez des questions concernant cet article ? Laissez-nous un commentaire ou contactez-nous directement via notre formulaire de contact.

Nous vous répondrons dans les plus brefs délais.

Posté dans la catégorie : TSM | Tag , , , , | Commentaires fermés

La déduplication : questions & réponses

Par Gabriel | Publié le 13 mars 2013

Vous trouverez ci-dessous un ensemble de questions / réponses afin de répondre aux demandes récurrentes sur le sujet.

La déduplication ? Qu'est ce que c'est ?

La déduplication est une fonction qui va vous éviter de stocker des blocs de données (chunks) redondants dans vos pools de stockages. Vous réduirez donc vos besoins en espace disque, en temps de sauvegarde et vous économiserez donc de l'argent.

DEDUP_SDS
Ex : vous envoyez un email à vos 10 collaborateurs avec en pièce jointe un présentation Powerpoint de 5Mo. Cette présentation sera potentiellement sauvegardée 10 fois. Avec la déduplication elle ne le sera qu'une seule fois !

TSM propose d'autres moyens afin d'optimiser le stockage de vos données comme la compression client ou l'incrément en mode bloc (subfile backup).

Pourquoi utiliser la déduplication ?

La déduplication peut être très pertinente dans certains cas comme par exemple si vous souhaitez :

  • réduire vos besoins en espace disque
  • réduire les temps de sauvegarde de vos postes clients
  • mettre en place la réplication de vos postes vers un serveur cible (lisez notre article consacré au sujet)

Combien ça coute ?

Aucune licence TSM supplémentaire n'est nécessaire  !
Il faut cependant considérer que les pré-requis matériel sont plus importants avec la déduplication (quantité de mémoire, disques durs performants).

Existe t'il plusieurs méthodes de déduplication ?

Il existe deux types de déduplication bien différents :

  • la déduplication client : Les postes clients assurent le processus de déduplication. Particulièrement utile si vous disposez d'une faible bande passante et/ou si vous ne souhaitez pas augmenter la charge de votre serveur TSM. Vous obtiendrez par ailleurs de meilleurs résultats en la combinant à la compression client.
  • la déduplication serveur :
    Les données dupliquées sont identifiées une fois les données sauvegardées sur TSM. Le ou les processus d'identification doivent être lancés régulierement sur le serveur et auront pour conséquence une consommation accrue de CPU ainsi que des ressources de la base de données TSM. A utiliser si vos postes clients ne sont pas suffisamment robustes et si vous souhaitez être en mesure de créer rapidement des supports avec vos données non dédupliquées afin des les externaliser sur un site distant par exemple.

Quelles sont les limites de la déduplication ?

Si vous utilisez la déduplication, vous ne pourrez plus utilisez certaines des autres fonctionnalités proposées par TSM :

  • Compression cliente (ne doit pas être utilisé avec la déduplication serveur)

Dans le cas de la déduplication client :

  • HSM Unix
  • La sauvegarde incrémentale en mode bloc (subfile backup)
  • La taille minimum des fichiers élligibles est de 2Ko
  • Le cryptage des données à la source par le client TSM
  • Il n'est pas possible d'utiliser la fonction d'écriture simultanée (en Y) sur les storage pools TSM
  • Lan Free Backup

Ma déduplication est-t-elle performante ?

Vous savoir si votre déduplication est réellement pertinente il suffit de consulter le paramètre "Duplicate data not stored" de vos pools de stockage (q stgpool nom_du_pool f=d)
Vous verrez alors la quantité et le pourcentage d'espace économisé.

D'après IBM les taux de déduplication moyens observés oscillent entre 50% et 93% et dépendent bien évidemment du type de données sauvegardées. Un taux moyen de 66% semblent être une valeur raisonnable.

Efficacité de la déduplication en fonction du type de données

tableau_taux_dedup

 

Pourquoi ne pas utiliser une solution matérielle tierce dédiée à la déduplication ?

Les solutions matérielles de déduplication présentent l'avantage de pouvoir traiter rapidement des grosses volumétries de données mais leur cout reste assez élevé.
Elles sont donc à privilégier si vous disposez par exemple de plusieurs serveurs TSM pour lesquels vous souhaitez mettre en place la déduplication ou si vous êtes amenés régulièrement à sauvegarder de gros fichiers (de plusieurs centaines de Go)

La plupart des fabricants du marchés proposent leur propres solutions. (IBM, EMC, HP, NetApp, ...)

Des questions ?

Vous avez des questions concernant cet article ? Laissez-nous un commentaire ou contactez-nous directement via notre formulaire de contact.

Nous vous répondrons dans les plus brefs délais.

Posté dans la catégorie : TSM | Tag , , , , | Commentaires fermés

La réplication des nodes sous TSM 6.3

Par Gabriel | Publié le 8 mars 2013

Dans le cadre d'un PRA et afin de respecter les contraintes de RTO (Recovery Time Objective) et RPO (Recovery Point Objective) imposées il peut être très judicieux de faire appel à la fonction de réplication des postes disponible depuis TSM 6.3.

La réplication : qu'est ce que c'est ?

Pour rappel, la réplication consiste à copier de manière incrémentale les données appartenant à un ou plusieurs clients de sauvegarde/archivage depuis une serveur TSM source vers un serveur TSM cible en utilisant les liaisons réseaux disponibles.
On parle alors d'externalisation électronique puisqu'il n'est plus nécessaire de faire appel à des médias physiques (bandes LTO par exemple) afin de disposer d'une copie des données sur un site de secours.

La réplication peut être utilisée pour les différents types de données suivants :

  • données de sauvegarde actives & inactives ou uniquement actives
  • données d'archivage

Pré-requis techniques

Il est impératif d'utiliser une version TSM6.3.0 minimum sur les deux serveurs afin de pouvoir utiliser la réplication.

  • TSM 6.3.0
  • Liste des OS supportés
  • Administration Center v 6.3 (pour gérer la réplication en mode graphique)
  • 32GB de mémoire minimum, 64GB recommandé
  • Bande passante suffisante afin d'effectuer les réplications planifiées

Mise en place

Définition des serveurs

La première étape consiste tout d'abord à définir sur chacun des deux serveurs les paramètres qui leur permettront d'accéder l'un à l'autre.

Depuis le serveur cible :

Si ce n'est pas déjà le cas, il faut définir le mot de passe serveur. Ce mot de passe sera utilisé par la réplication lors des connexions server-to-server.

Il faut ensuite créer la définition du serveur source en précisant en autre son adresse IP (hla) ainsi que le port TCP qu'il utilise (lla)
Pour vérifier si cette dernière fonctionne correctement vous pouvez utiliser la commande "ping" depuis une invite de commande TSM.

Depuis le serveur source :

Il faut créer une nouvelle définition qui fera référence au serveur cible puis activer la réplication.

Règles de réplication par défaut

Lors de la réplication des données il est possible de spécifier le type de données que vous souhaitez répliquer (sauvegarde, archive, données actives uniquement, ...)
Si, pas exemple, vous souhaitez répliquer l'intégralité des données il suffit d'utiliser la commande TSM suivante :

set bkreplruledefault ALL_DATA

Vous pouvez par exemple choisir de ne répliquer que les données de sauvegarde actives via l'option ACTIVE_DATA.

Configuration des postes clients pour la réplication

Nous partons du principe que les postes clients n'existent pas sur le serveur cible et que leur première réplication sera effectuée à travers le réseau.
Pour chaque node que vous souhaitez répliquer il faut activer la réplication (option replstate)

Réplication de plusieurs postes clients. Comment gagner du temps ?

Si vous souhaitez répliquer plusieurs postes clients à la fois, voir même l'intégralité des postes présents sur votre serveur TSM source, il est conseillé d'utiliser des groupes de nodes.

Pour pourrez par ailleurs hiérarchiser vos réplications en mettant en place différentes règles de priorités.

Test : réplication manuelle

Pour tester le bon fonctionnement de la réplication, il suffit d'utiliser la commande TSM replicate node

Pour contrôler l'état de la réplication vous pouvez alors utiliser les commandes "q pr" et "q actlog" puis vous assurez que le node a été créé sur le serveur cible et qu'il contient bien des données.

ANR0327I Replication of node NODE1 completed.
Filesccurrent: 0. Files replicated: 15 of 15. Files updated: 0 of 0.
Files deleted: 0 of 0. Amount replicated: 15 KB of 15 KB.
Amount transferred: 15 KB.
Elapsed time: 0 Day(s), 0 Hour(s), 1 Minute(s). (SESSION: 3, PROCESS: 7)

ANR0986I Process 7 for Replicate Node running in the
BACKGROUND processed 15 items for a total of 15,360 bytes
with a completion state of SUCCESS at 14:34:30.
(SESSION: 3, PROCESS: 7)

Réplication initiale

Il existe plusieurs méthode qui dépendront principalement de vos besoins de réplication ainsi que de la bande passante disponible entre les deux serveurs TSM.

  • Réplication via le réseau : si vous disposez d'une bande passante suffisante que vous n'être pas pressés par le temps cette méthode reste la plus simple. Il suffit de lancer les réplications qui s’effectueront intégralement à travers le réseau. Vous pouvez effectuer les choses de manière progressive en sélectionnant les nodes ou les groupes de nodes les plus prioritaires.
  • Réplication des données actives uniquement : dans un premier temps vous pouvez choisir de ne répliquer que les données actives de vous comptes, ces dernières étant généralement les plus stratégiques. Une fois cette première réplication terminée, vous pourrez alors modifier les règles en activant la réplication des versions actives et inactives.
  • Export/Importe via médias physiques : si vous devez répliquer une grosse quantité de données et que vous ne pouvez pas vous permettre d'effectuer rapidement cette opération à travers le réseau, vous avez la possibilité d'effectuer des exports / imports entre votre serveur source et votre serveur cible en utilisant par exemple des cartouches LTO. Il faut cependant être rigoureux au moment de l'activation de la réplication afin que les données soient dans un premier temps synchronisées (options syncsend et syncreceive) Une fois la synchronisation terminée les comptes seront automatiquement mis à jour par TSM pour se répliquer.

Automatisation de la réplication

Il suffit de créer un schedule de type commande.

define schedule REPLICATION_NODE1 type=admin cmd="replicate node NODE1 wait=yes" desc="Replication quotidienne du poste NODE1" dayofweek=any period=1 perunits=days active=yes starttime=00:00

Gestion de la réplication via l'Administration Center (AC)

Il est possible de gérer la réplication de manière graphique à travers l'AC en version 6.3 minimum.

Règles de serveur :

11

Sélection des postes clients à répliquer :

22

Récapitulatif des règles :

33

Historique des réplications :

44

Optimisation : réplication & déduplication

Mettre en place la déduplication peut vous permettre d'améliorer les temps de réplication car les blocs de donnés (les chunks) déjà existants sur le serveur cible ne seront pas à nouveau transférés.

Cela implique cependant de revoir les pré-requis en terme de RAM, ce process était relativement gourmand. Tout dépend bien évidemment de la taille de votre architecture, mais il est cependant recommandé par IBM d'avoir un minimum de 64GB de mémoire pour utiliser la déduplication en combinaison de la réplication. Ne pas respecter ce minimum peut entrainer des baisses de performances globales de votre architecture TSM en pénalisant les autres opérations.

DRP TSM : 100% electronic vaulting

En associant la réplication des comptes TSM à la synchronisation de vos bases TSM via HADR il est alors possible de mettre en place un DRP 100% électronique (eletronic vaulting)

Pour plus d'infos sur DB2 HADR consultez notre article sur le sujet : Optimisation du DRP TSM avec DB2 HADR

Des questions ?

Vous avez des questions concernant cet article ? Laissez-nous un commentaire ou contactez-nous directement via notre formulaire de contact.

Nous vous répondrons dans les plus brefs délais.

Posté dans la catégorie : TSM | Tag , , , , , , , | Commentaires fermés

AIX tools : optimisez les performances de TSM

Par Jean-xavier | Publié le 4 mars 2013

Les performances du système impactent particulièrement les serveurs TSM. Pour qu'un serveur TSM réponde de manière optimale, il faut d'abord et avant tout que le système soit convenablement configuré.

IBM propose une séance Web pour se familiariser avec les outils d'optimisation de performances sous AIX.

Sujets traités lors de ce webcast :

- Optimisation des performances TSM grâce à AIX tools
- CPU
- Commandes de monitoring de la mémoire
- Réseau
- Supervision
- Optimisation disque
- LPAR (Logical PARtitions)

Présenté par : Dave Canan et Thomas Hepner

Veuillez cliquer ici pour vous inscrire à cet événement.

Posté dans la catégorie : TSM | Tag , , , , , , | Commentaires fermés

ROADMAP TSM 2013 : une nouvelle interface graphique d’administration

Par Jean-xavier | Publié le 22 février 2013

Pour cette fin d'année 2013 IBM annonce une toute nouvelle interface graphique d'administration TSM.

Quelques-unes des nouvelles fonctionnalités :

 - Interface Web accessible depuis n'importe quel terminal : poste fixe, tablette ou mobile

- Vue synthétique de l'état du serveur, des storages pools et de la base de données TSM

- Analyse automatique des problématiques de sauvegarde

- Alertes customisables

- Team collaboration

 Vous n'avez plus qu'à tester !
Attention il faut impérativement être en TSM 6.4.

Posté dans la catégorie : News, TSM | Tag , | Commentaires fermés

IBM Tivoli Storage Manager serveur V5.5 Fix Pack 7 (5.5.7.000)

Par Jean-xavier | Publié le 20 février 2013

La dernière version du serveur TSM 5 (V5.5.7) est disponible depuis le 18/02/2013.

Liste des APARS corrigés dans cette version.

 

Posté dans la catégorie : TSM | Tag , , , , | Commentaires fermés

TSM4VE 6.4 et le mode incremental forever

Par Jean-xavier | Publié le 18 février 2013

vmware-logoLa dernière version de l'agent TSM4VE (Tivoli Storage Manager for Virtual Environments) intègre désormais la fonction incrémental permanent ou sauvegarde progressive pour la protection des environnements VMWare.

Cette fonctionnalité dispense dorénavant de déclencher des sauvegardes Full hebdomadaires mais nécessite toutefois un remaniement des politiques de rétention des données. Précédemment les sauvegardes Incrémentales étaient toutes rattachées à la sauvegarde Full qui les précédait. Elles ne passaient à l'état Inactive qu'à la suite d'une nouvelle sauvegarde Full. Chaque sauvegarde incrémentale étant désormais considérée comme indépendante, la sauvegarde Full n'est plus nécessaire pour faire expirer les versions antérieures obsolètes.

Combinée au (CBT) Changed Bloc Tracking, cette fonctionnalité réduit donc de manière drastique la quantité de données ainsi que les temps de sauvegarde.

Nous attirons votre attention sur le fait que contrairement à la sauvegarde des fichiers, le mode incrément permanent TSM4VE nous impose d'effectuer la première sauvegarde avec l'option -mode=IFFULL alors que toutes les suivantes seront lancées avec l'option -mode=IFINCR.

En terme de restauration, cette nouvelle version optimise aussi les temps de traitement, en ne restaurant qu'une seule et unique fois les Blocks modifiés à plusieurs reprises.

Ces diverses optimisations vont donner la possibilité à un même Proxy Backup Server de traiter plus de VM qu'auparavant et donc d'accompagner le client dans sa croissance à moindre coûts.

D'autre part, du point de vue du serveur TSM et du monitoring des sauvegardes, une nouvelle table SUMMARY_EXTENDED apparue avec la version 6.3.3.x du serveur, permet d'afficher un compte rendu des sauvegardes des VMs plus détaillé et exhaustif.

Ci dessous un exemple de rapport, généré à partir de cette nouvelle table:

summary_extended

Ce genre d'informations restait très difficile à extraire des versions précédentes de TSM.

En résumé, TSM4VE version 6.4 étoffe les fonctions de TSM dans un environnement VMWare par:

  • Une optimisation des performances en sauvegarde et restauration
  • Une réduction des espaces de stockage nécessaires
  • Une optimisation des coûts en augmentant les capacités de traitement du Backup Proxy
  • Une plus grande flexibilité et une meilleure protection en permettant des sauvegardes de VM aussi fréquentes que désirées

 

Toutefois, tout comme pour le client TSM Standard et son incremental Progressive, il restera toujours des cas où une sauvegarde Full restera nécessaire pour disposer d'un Disaster Recovery encore plus rapide, pour la première sauvegarde ou encore lorsque la fonction CBT n'est pas active.

Posté dans la catégorie : TSM, Virtualisation | Tag , , , , , | Commentaires fermés