Tags

mardi 11 février 2014

Utilisation des "Custom Attributes" pour VMware sous NetBackup

Depuis NetBackup 7.5 et vSphere 5, il est possible de mettre en place des attributs personnalisés sous le vCenter, et qui seront utilisés par NetBackup dans les requêtes au vCenter, pour savoir ce qui est à sauvegarder.

L'idée est par exemple, de mettre une variable "Backup_Day" sur chaque VM, pour savoir quelle jours de la semaine elle sera sauvegardée, ou alors "Backup_SLA" pour savoir si on la sauvegarde tous les jours ou 2x par jour, etc...

Pour les utiliser, il faut :

  1. Créer un "custom attribute" dans le vCenter, en allant dans Administration > Custom Attribute, et là, créer un nouvel attribut au nom de son choix, et qui doit être au niveau "Virtual Machine"
  2. Se rendre sous NetBackup, faire rafraîchir la liste des VM pour récupérer les informations relatives à ces attributs
  3. Définir une requête dans une police VMware, qui utilisera l'attribut créé, qui sera présenté entre crochets : [MonAttribut]

A noter : l'ensemble des fichiers récupérant les infos des custom attributes se trouvent dans /usr/openv/netbackup/online_util/fi_cntl, et ont pour nom <nom du vcenter>_ca.xml. Ça peut toujours servir (voir si il a été rafraîchit, si les attributs créés y figurent bien, etc.)
Il est possible de les supprimer (renommer c'est bien aussi, et ça laisse une chance en cas de souci ;-) ) pour forcer le rafraîchissement.

Certaines sauvegardes VMware se terminent en code 156...

Problème du jour, identifié avec pas mal de chance, et qui peut vous poser des soucis également, alors je partage l'info.

Le problème était le suivant : sur une infra NetBackup classique, NetBackup en 7.5.0.6, sauvegarde sur bande, j'avais des sauvegardes VMware configurées quelques mois plus tôt et qui se déroulaient très bien. Mais depuis quelques temps, certaines VMs n'étaient plus sauvegardées, toute tombaient en code 156.

Pour rappel, le code 156 est une erreur de snapshot, indispensable à toute sauvegarde de VM. J'ai commencé, comme toujours dans ce cas, à valider la possibilité le faire des snapshots coté VMware, tout était ok.

D'ailleurs, je me suis aperçu que même les demandes de snapshots par NetBackup échouaient avant même de provoquer la prise d'image coté vCenter.

Dans les logs NetBackup bpfis sur le media serveur, des erreurs basiques et pas trop parlantes, comme dans le job de sauvegarde lui même :
10 févr. 2014 21:00:00 - Info nbjm (pid=2577) starting backup job (jobid=100723) for client <Client>, policy VMware_Prod, schedule Incr
10 févr. 2014 21:00:00 - Info nbjm (pid=2577) requesting STANDARD_RESOURCE resources from RB for backup job (jobid=100723, request id:{EC849602-928D-11E3-84A2-0E6ECE4CEAEC})
10 févr. 2014 21:00:00 - requesting resource LB_Montpeliier_EML
10 févr. 2014 21:00:00 - requesting resource backup.NBU_CLIENT.MAXJOBS.<Client>
10 févr. 2014 21:00:00 - requesting resource backup.NBU_POLICY.MAXJOBS.VMware_Prod
10 févr. 2014 21:00:14 - awaiting resource <STU Group>. Waiting for resources.
Reason: Drives are in use, Media server: <Media Server>,
Robot Type(Number): TLD(0), Media ID: N/A, Drive Name: N/A,
Volume Pool: VMware_Day, Storage Unit: <Storage Unit>, Drive Scan Host: N/A,
Disk Pool: N/A, Disk Volume: N/A
10 févr. 2014 21:03:58 - granted resource backup.NBU_CLIENT.MAXJOBS.<Client>
10 févr. 2014 21:03:58 - granted resource backup.NBU_POLICY.MAXJOBS.VMware_Prod
10 févr. 2014 21:03:58 - granted resource 008109
10 févr. 2014 21:03:58 - granted resource HP.ULTRIUM4-SCSI.002
10 févr. 2014 21:03:58 - granted resource <Storage Unit>
10 févr. 2014 21:03:58 - estimated 0 kbytes needed
10 févr. 2014 21:03:58 - begin Parent Job
10 févr. 2014 21:03:58 - begin VMware: Start Notify Script
10 févr. 2014 21:03:58 - Info RUNCMD (pid=21091) started
10 févr. 2014 21:03:58 - Info RUNCMD (pid=21091) exiting with status: 0
Operation Status: 0
10 févr. 2014 21:03:58 - begin VMware: Step By Condition
Operation Status: 0
10 févr. 2014 21:03:58 - end VMware: Step By Condition; elapsed time 0:00:00
10 févr. 2014 21:03:58 - begin VMware: Read File List
Operation Status: 0
10 févr. 2014 21:03:58 - end VMware: Read File List; elapsed time 0:00:00
10 févr. 2014 21:03:58 - begin VMware: Create Snapshot
10 févr. 2014 21:03:58 - started process bpbrm (pid=3048)
10 févr. 2014 21:04:02 - end writing
Operation Status: 156
10 févr. 2014 21:04:02 - end VMware: Create Snapshot; elapsed time 0:00:04
10 févr. 2014 21:04:02 - begin VMware: Stop On Error
Operation Status: 0
10 févr. 2014 21:04:02 - end VMware: Stop On Error; elapsed time 0:00:00
10 févr. 2014 21:04:02 - begin VMware: Delete Snapshot
10 févr. 2014 21:04:02 - started process bpbrm (pid=3136)
10 févr. 2014 21:04:03 - end writing
Operation Status: 1542
10 févr. 2014 21:04:03 - end VMware: Delete Snapshot; elapsed time 0:00:01
Operation Status: 156
10 févr. 2014 21:04:14 - Info bpbrm (pid=3048) <Client> is the host to backup data from
10 févr. 2014 21:04:14 - Info bpbrm (pid=3048) reading file list from client
10 févr. 2014 21:04:14 - Info bpbrm (pid=3048) start bpfis on client
10 févr. 2014 21:04:14 - Info bpbrm (pid=3048) Starting create snapshot processing
10 févr. 2014 21:04:15 - Info bpfis (pid=4068) Backup started
10 févr. 2014 21:04:15 - snapshot backup of client <Client> using method VMware_v2
10 févr. 2014 21:04:17 - Critical bpbrm (pid=3048) from client <Client>: FTL - VMware snapshot failed: Unrecognized error
10 févr. 2014 21:04:17 - Critical bpbrm (pid=3048) from client <Client>: FTL - snapshot processing failed, status 156
10 févr. 2014 21:04:17 - Critical bpbrm (pid=3048) from client <Client>: FTL - snapshot creation failed, status 156
10 févr. 2014 21:04:17 - Warning bpbrm (pid=3048) from client <Client>: WRN - ALL_LOCAL_DRIVES is not frozen
10 févr. 2014 21:04:17 - Info bpfis (pid=4068) done. status: 156
10 févr. 2014 21:04:17 - end VMware: Start Notify Script; elapsed time 0:00:19
10 févr. 2014 21:04:17 - Info bpfis (pid=0) done. status: 156: snapshot error encountered
10 févr. 2014 21:04:18 - Info bpbrm (pid=3136) Starting delete snapshot processing
10 févr. 2014 21:04:18 - Info bpfis (pid=0) Snapshot will not be deleted
10 févr. 2014 21:04:19 - Info bpfis (pid=3624) Backup started
10 févr. 2014 21:04:19 - Critical bpbrm (pid=3136) from client SLPPRAPP01: cannot open C:\Program Files\Veritas\NetBackup\online_util\fi_cntl\bpfis.fim.<Client>_1392062638.1.0
10 févr. 2014 21:04:19 - Info bpfis (pid=3624) done. status: 1542
10 févr. 2014 21:04:19 - end Parent Job; elapsed time 0:00:21
10 févr. 2014 21:04:19 - Info bpfis (pid=0) done. status: 1542: An existing snapshot is no longer valid and cannot be mounted for subsequent operations
snapshot error encountered (156)
J'ai cherché pas mal sans trouver trop de piste, puis en analysant coté vCenter les VMs impactées, je me suis rendu compte que 80% d'entre elles avaient des caractères accentués dans le display name. Ca se réchauffait.
J'ai cherché davantage pour trouver un point commun à toutes, et ça s'est avéré fructueux : toutes ces VMs avaient été créées avec un display name contenant des accents, ce qui a provoqué la création des vmdk dans des répertoires à nom accentués. Les machines sans accents dans le display name avaient juste été renommées par la suite, mais leur arborescence était restée intacte, provoquant également l'erreur.

Le plus simple pour solutionner cela, est de cloner les VMs à problème vers des VMs 'propres', mais cela nécessite une interruption de service.

Alors à l'avenir : pas de backup-host en français, ni de noms de VMs avec des accents (par contre, les caractères internationaux comme &# et autres fonctionnent bien)

mardi 17 décembre 2013

NetBackup 7.5.0.7, le patch surprise


La veille de la sortie officielle de NetBackup 7.6, Symantec nous sert sur un plateau un patch pour la version 7.5, la 7.5.0.7.

Comme d'habitude, on a le droit à (quelques) prises en compte de nouvelles versions d'application (VDDK 5.1), mais surtout des correctifs.



Attention cependant, la release note prévient que la mise à jour n'est pas recommandé pour les personnes qui comptent migrer en 7.6 dans la première partie de l'année 2014, donc ne vous jetez pas trop vite dans une mise à jour.

Vous trouverez la relase note ici : Lien
Les téléchargements ici : Lien

mardi 2 juillet 2013

NetBackup remonte régulièrement,sur tous les clients, des codes 48 : client hostname could not be found

J'ai, il y a peu, migré un serveur de sauvegarde NetBackup Linux via une copie du /usr/openv (c'est pas la méthode la plus jolie ni la plus recommandée, mais j'ai plein de bonnes raisons pour avoir utilisé ce procédé, que je ne donnerai pas ici).

Bref, j'ai installé NetBackup, vidé mon /usr/openv local, puis copié le /usr/openv du serveur d'origine (qui comportait le même nom évidemment). J'ai redémarrée NetBackup, et tout fonctionnait... Presque...

Les tests de sauvegardes local au master étaient concluants, mais quand je me suis rendu dans l'interface NetBackup, dans la partie Host Properties > Clients, chacun des clients me retournait un code 48 (client hostname could not be found).

Pour y remédier, j'ai purgé le host cache NetBackup (qui existe depuis la 7.0) via la commande bpclntcmd -clear_host_cache puis tenté de contacter chacun des clients via la commande bptestbpcd -host <client>. Tous répondaient et étaient opérationnels.

Mais voilà, pendant la nuit, les clients qui étaient pourtant disponibles, sont devenus injoignables avec un code 48 (encore). Un revidage du cache a réglé le souci, mais là encore c'était temporaire.

Des sauvegardes étant en cours, je n'ai pas pu arrêter NetBackup. J'ai donc supprimé à chaud les entrées présentes dans le répertoire /usr/openv/var/host_cache (c'est encore plus radical que le bpclntcmd -clear_host_cache). Ca a permis d'accéder au clients, mais contre toute attente, les codes 48 sont réapparus plus tard dans la nuit.

Mon salut est venu de la même opération, mais NetBackup arrêté, a croire qu'il existe une version du cache en RAM qui est régulièrement flushé sur disque. Le fait est qu'en vidant ce répertoire à froid, tout est rentré dans l'ordre... ouf.

Sauvegarde VMware via SAN en code 6 sous NetBackup

Je rencontre à nouveau le cas aujourd'hui, et je me rappelle avoir passé énormément de temps sur ce problème de fou (ou considéré comme tel) lors de ma première expérience. Donc je me suis dit qu'il était intéressant que je le rapporte ici.

Problème
Le souci est le suivant : vous configurez la sauvegarde VMware de manière classique, via l'agent dédié NetBackup.
Lors de votre test en sauvegarde réseau (nbd), tout se passe très bien, mais dès que vous activez le mode SAN (san), votre job de sauvegarde se plante en code 6 (mais avec le message "ERR - Error opening the snapshot disks using given transport mode: Status 23" dans la log ou alors bascule sur le mode LAN (si jamais vous avez autorisé les 2 modes).

Ce problème est répertorié dans cette Technote Symantec. Il ne se produit que si l'OS windows 2008 de votre Backup Host est en français (je sais c'est rare mais certaines société utilisent ce langage - C'est MAL, je le rappelle). Il est possible que ça arrive pour d'autres versions de Windows, je n'ai pas eu l'occasion de tester.

La raison est simple, L'API va vouloir utiliser un montage sur C:\Windows\TEMP\vmware-Système\, et avec l'accent, ça passe (très) mal. En anglais, cet accent n'existe pas et votre montage de snapshot va se dérouler sans le moindre problème.

Solution
Il existe un contournement :

  • Editer (ou créer) le fichier C:\Program Files\Common Files\VERITAS\VxMS\Shared\VDDK\bin\vixDiskLib.ini, puis y ajouter la ligne suivante : tmpDirectory = "<temp path>", ou <temp_path> est le chemin où seront montés les snapshots de VM (sans y mettre des accents évidemment).
  • Editer si besoin l'utilisateur renseigné dans les crédentials pour accéder au vCenter, pour que ce dernier n'utilise pas de caractères accentués.
Attention : en migrant de version NetBackup, le  fichier vixDiskLib.ini sera supprimé/écrasé, il faudra donc le recréer.

mardi 25 juin 2013

Il est né le divin patch : NetBackup 7.5.0.6

On l'attendait comme le messie, on n'y croyait plus, on ne l'espérait plus, et finalement, il est là, le patch NetBackup qui va nous permettre de sauvegarder Windows 2012, le 7.5.0.6

Ce qu'il apporte :

On notera dans ce patch, les améliorations/fonctionnalités suivantes :

  • Support Windows 8 et 2012
    • Il y a des limitations importantes :
      • Client seulement
      • Pas de BMR (client et/ou boot server)
      • Pas de dédup à la source
      • Remote VSS non supporté (nouveauté Win2012)
      • Sauvegarde des NTFS dédupliqués via réhydratation
      • Pas utilisable pour VMware Backup Host
      • Restauration granulaire fichiers de VMs Hyper-V impossible si :
        • Les fichiers sont sur ReFS
        • Les VMs sont composées de vhdx
      • Pas de console d'admin NetBackup (Java et console lourde)
    • Attention : un package particulier est nécessaire
  • Support des nouvelles versions de bases de données
    • SAP HANA
    • DB2 10.1
    • SQL Server 2012 (pas marqué dans la release note mais dans la compatibility list)
    • Exchange 2013
      • Sans GRT ni Backup Host
    • Exchange 2010 R2 sur Win 2008R2 et Win2012
    • SharePoint 2013 
      • Sans GRT
  • Support Hyper-V 2012
  • Sauvegarde Exchange : les droits changent, et on peut se passer des droits admin (Exchange 2010 et 2013)
  • Amélioration du schedule des jobs de réplication AIR pour limiter l'impact sur les sauvegardes en cours
  •  Nouvelle méthode de recherche par date dans l'interface BAR

Compatibilité

Comme pour les patches précédents, ce patch peut être installé sur un client alors que le media et le master ne sont pas encore à ce niveau (pratique pour Win2012), car le 4ème digit n'entre pas en ligne de compte dans la règle du master supérieur ou égal au média lui même supérieur ou égal au client.
Pour plus de détail, voir page 15 de la release note.

Téléchargement

Vous trouverez tous les packages ici : Lien


mardi 14 mai 2013

Erreur de sauvegarde NetBackup avec client StorNext

StorNext est un produit Quantum qui permet de mettre à disposition un file-system d'archivage. Les données placées sur ce FS sont mises sur bandes si elles ne sont pas accédées sur le long terme.

Les serveurs qui doivent utiliser ce FS doivent avoir un client installé, et qui va permettre de visualiser ces disques comme des disques classiques Windows (sans pour autant apparaître dans le gestionnaire de disques de Windows)

Quand NetBackup va tenter de sauvegarder le serveur, il se peut que le job tombe en erreur 50, et si on creuse dans les logs du job, on trouvera aussi une erreur 69 (et cela même en excluant les disques StorNext via l'exclude-list)

Dans les logs du bpbkar, on trouve alors :

2:57:09.972 PM: [7308.2292] <2> ov_log::V_GlobalLog: INF - ERROR: Disc \\?\Volume{30b5576f-554f-4ac1-a102-4b837327cfcf}\ is greater than defined threshold of 63 TB
2:57:09.988 PM: [7308.2292] <2> ov_log::V_GlobalLog: INF - EXIT VssSnapshotVolume::CheckForUnsupportedDiscs() return=[0x8004230c VSS_E_VOLUME_NOT_SUPPORTED]! 
2:57:10.004 PM: [7308.2292] <2> ov_log::V_GlobalLog: INF - EXIT VssSnapshotVolume::Initialize() return=[0x8004230c VSS_E_VOLUME_NOT_SUPPORTED]!

On constate que NetBackup ne veut pas sauvegarder un volume supérieur à 63To. Ce qui est étonnant, c'est que l'exclusion du disque n'y change rien : dans les logs ci dessous, je ne demandais qu'une sauvegarde du System_State:\, et non une sauvegarde de disques. Pourtant, les disques StorNext causaient l'échec de la sauvegarde car cette vérification de taille maximum est faite en préambule de toute sauvegarde par le client NetBackup.

On  a alors 2 solutions :
  • une "moche" : démonter les disques StorNext avant la sauvegarde (via un bpstart_notify par exemple), puis les remonter en fin de sauvegarde
  • une "jolie" : Aller modifier la clé de registre (ou la créer) HKLM\SOFTWARE\Veritas\NetBackup\BEDS\Engine\Misc\BescLargeDiscBlock en y mettant une valeur supérieure à la taille de disque max présente (en octets !). Puis relancer les services.
Voilà, le tour est joué.

lundi 13 mai 2013

EMC met à jour son OS DataDomain en 5.3

Bonjour tout le monde...

Aujourd'hui, je vais parler DataDomain, ce qui va changer un peu... quoique, puisque je vais quand même faire un focus sur NetBackup.

EMC s'apprète à sortir dans les mois qui arrivent, son DDOS 5.3 (il est aujourd'hui en RA), et qui va nous apporter :

  • Une amélioration globale des performances
  • DD Boost pour GreenPlum DR et NetVault Backup 9.0
  • DD Boost sur Fiber Channel (NetBackup uniquement dans un premier temps)
  • A.I.R. sur NetBackup
  • Accelerator pour NetBackup
  • Les synthetics full optimisées pour NetBackup (Étrange, il me semble que c'était depuis la 5.2)
  • Multiplexage pour les sauvegardes RMAN
  • Emulation LTO4 et i2000 en VTL
  • Amélioration IBM i System Recovery


Voilà qui est intéressant donc !

Sources :

mercredi 20 février 2013

NetBackup 7.5.0.5, c'est maintenant !

Symantec vient d'annoncer la mise en ligne du nouveau patch NetBackup, dans sa version 7.5.0.5.

Ce qu'elle apporte : 

Au programme : 
  • Support de vSphere 5.1 (c'était compliqué avant)
    • Support des OS Win 8 et 2012 dans la VM via sauvegarde vmdk
  • Backup hosts Red-Hat x64 (6.3 et 5.5) pour la sauvegarde VMWare
  • Support BMR pour :
    • RHEL 5.8 et 6.3
    • Linux 5.7 et 6.3
  • Support de DB2 10.1
  • 400 nouveaux Fix depuis la 7.5.0.4 (soit plus de 1100 depuis la 7.5)
  • Alertes groupées sous OpsCenter
  • Fin de support pour 
    • Solaris 9
    • AIX 5.3
    • Linux RedHat et SUSE Itanium
Vous trouverez la release note ici

A priori pour Windows 2012, il faudra patienter encore, et attendre NetBackup 7.6

Compatibilité 

Comme pour la précédente release, votre media server doit être de version supérieure au client, et la même règle s'applique au master par rapport au media server, avec une version majeure (le 1er chiffre) d'écart maximum entre chaque.
A noter qu'il est possible d'avoir un client plus récent qu'un media server, sur le 4ème chiffre de la version uniquement (et si le media est en 7.5.0.1 au moins).

Plus de détails dans la release note (lien au dessus)

Téléchargement

Tout est ici

mercredi 6 février 2013

Scripts de pré/post traitement sous NetBackup

Il est parfois intéressant de pouvoir lancer un script avant sa sauvegarde, ou après, voire les 2 à la fois. Cas pratique par excellence, la réalisation d'un dump d'une base de données avant la sauvegarde, afin de s'assurer que cette dernière est bien valide (pas de dump en cours, et bien récent).

NetBackup permet évidemment ce genre d'opération, en voici un aperçu simplifié...

Les scripts

En fonction de l'OS utilisé, il doivent porter le nom suivant :
  • Sous Unix :
    • bpstart_notify[.<nom de la police>[.<schedule>]]
    • bpend_notify[.<nom de la police>[.<schedule>]]
  • Sous Windows
    • bpstart_notify[.<nom de la police>[.<schedule>]].bat
    • bpend_notify[.<nom de la police>[.<schedule>]].bat
Ils se placent sur le client, dans le répertoire bin dans le répertoire d'installation du client.

Ils seront appelés au début et à la fin de la sauvegarde. Celui qui rempli le plus de contraintes satisfaites sera prioritaire sur les autres. Par exemple, le bpstart_notify.MaPolice sera prioritaire sur le bpstart_notify quand on lancera la police MaPolice.

Les paramètres

Ils sont au nombre de 6, et sont accédés classiquement pour chaque OS : $X pour le Xème paramètre sous Unix/Linux, et %X pour le Xème paramètre sous Windows.

Voici les paramètres :
  • 1 : Nom du client
  • 2 : Nom de la police
  • 3 : Nom du Schedule
  • 4 : Type du Schedule
  • 5 : Status (0 dans le bpstart_notify)
  • 6 : Fichier de resultat
Les paramètres

Lors de l'exécution de ces scripts, des variables d'environnement sont aussi disponibles :
  • BACKUPID
  • UNIXBACKUPTIME
  • BACKUPTIME 
Code Retour

NetBackup ne lancera la sauvegarde que si le script précédent se termine, et n'a pas remonté un code retour différent de 0.

Attention : le code retour n'est pas classiquement utilisé (exit $CR dans le script), mais il doit être déposé dans le fichier de résultat (Sixième paramètre passé au script). Il est donc important de bien terminer son script par la commande echo <code_retour> > %6 (ou  echo <code_retour> > $6)

Si jamais le script ne se termine pas bien, et l'a bien renseigné dans le fichier résultat, le job de sauvegarde tombera avec un status code 73.

Timeout

Si jamais le script dure, NetBackup n'attendra pas la fin de son exécution pour interrompre le job de sauvegarde. Dans ce cas, le job se termine en code 74.
Si c'est le bpend_notify qui échoue, le jobs finira avec un code retour 75.

Ce timeout est par défaut de 300s, mais peut être modifié dans les "master proterties" avec la variable bpstart timeout ou bpend timeout.

Multi-flux

Combiner les scripts de pré ou post traitement avec les sauvegardes à plusieurs flux apporte souvent quelques prises de têtes, car il est compliqué de synchroniser les traitements. Symantec propose une idée intéressante et qui permettra de dépanner. Vous la trouverez ici : TECH6675



jeudi 13 décembre 2012

Supprimer des jobs en code 50 : Waiting for retry

Il arrive que sous NetBackup, des jobs bizarres se retrouvent dans l'activity monitor. Bizarres, car ils n'ont que très peu d'infos, pas de police par exemple ou encore pas de schedule. Ils n'ont qu'un code retour égal à 50, et un état en "Waiting for retry".
En général, ces jobs apparaissent quand on arrête NetBackup alors que des jobs étaient en cours de démarrage.

Ce n'est pas un problème en soi, car on se dit qu'on va les supprimer, et on en parlera plus. Mais c'est là que le bât blesse : il est impossible de les arrêter ou de les supprimer, ils font de la résistance (sous NetBackup inférieur à la version 7.5).

Il existe une solution simple, mais pas forcément pratique :

  • Arrêter NetBackup sur le master
  • Ensuite, 2 méthodes :
    • Se rendre dans /usr/openv/netbackup/db/jobs et supprimer le fichier bpjobd.act.db
    • lancer la commande /usr/openv/netbackup/bin/bpjobd -r (non testé)
  • Redémarrer NetBackup
Voilà, c'est magique, les jobs en question sont de l'histoire ancienne !

Sous NetBackup 7.5 et plus, ces jobs apparaissent encore, mais ils sont (enfin) supprimables classiquement par l'interface d'administration.

dimanche 7 octobre 2012

Gestion des exclude-lists depuis le serveur maître

C'est toujours une question délicate, comment gérer ses exclude lists (et include par extension) ?

Parce qu'elles sont gérées différemment en fonction de l'OS par NetBackup (base de registre pour Windows, fichiers plats pour Linux/Unix), c'est rarement simple de s'y retrouver.
D'ailleurs, Symantec n'a pas réussi à harmoniser la gestion par l'interface graphique : on peut les modifier pour Windows (dans la partie client properties, puis "windows client"), mais pour les autres OS, on n'a pas cette possibilité.

Il est pourtant possible de tout gérer depuis le master server, mais en ligne de commandes uniquement. Par contre, pas de miracle, les commandes à passer ne sont pas les mêmes...

Pour Windows

Il est possible de lancer une commande permettant de récupérer l'exclude list du client :
bpgetconfig -M <client Windows> EXCLUDE

Pour la modifier, on met la sortie obtenue par cette commande dans un fichier, puis on le modifie. Ensuite, on met à jour le client par la commande
bpsetconfig -h <client Windows> <fichier d'exclude>

Pour Unix/Linux

Pour lister l'exclude list et la stocker dans un fichier, c'est cette commande qu'il faut utiliser :
bpgetconfig -e <fichier> <client>

Pour l'include list, c'est
bpgetconfig -i <fichier> <client>

On peut modifier ces fichiers et les repousser vers le client via la commande :
bpsetconfig -e <fichier> <client> 
ou
bpsetconfig -i <fichier> <client>

Pour chacune de ces commandes, il est possible de préciser la police ou le schedule sur lesquels s'applique... Je vous renvoie vers la documentation NetBackup pour plus de précisions.

lundi 1 octobre 2012

Utiliser un partage CIFS comme dépot pour NetBackup

Problème rencontré ce jour, en clientèle et pour lequel j'ai eu pas mal de soucis à identifier son origine.

Petit rappel du contexte : intégration d'une appliance dédupliquante (ici une Quantum DXi), mais pour des raisons d'économies, ni OST ni VTL, mais un simple partage CIFS (car mon serveur NBU est sous Windows).
Comme Windows est bien fait et qu'il ne garde pas les montages réseau à la déconnexion du profil, impossible de passer par ce procédé, qui permet pourtant d'utiliser des credentials particuliers.

Dans mon archi du jour, la DXi présente un partage CIFS dans un réseau privé avec le serveur de sauvegarde, alors question sécurité, j'étais un peu tranquille. Ma solution :

  • Utiliser un partage sans restriction d'utilisateur (parce que c'est un réseau privé hein !)
  • Utilise le format UNC (vous savez le \\IP\nom_du_parrage\) dans la storage unit.

Tout se configure bien, Netbackup détecte bien l'espace présent sur le partage, tout roule quoi.

Je fais un test de sauvegarde et là... le bec dans l'eau : mon job tombe en code d'erreur 800 :
GENERAL ERROR: NBU status: 800, EMM status: Disk volume is down
Je fais un tour dans les logs, et dans l'interface graphique NBU j'ai le message suivant dans la page Disk Errors : 
Volume <MonDisk>:Internal_16 monitored by server is down S{cl-2060017} 

Pas vraiment de quoi m'aider en quelques sorte.

En cherchant sur le net, j'ai finalement trouvé ce HOWTO Symantec qui m'a bien aidé et qui m'a surtout appris une chose : NetBackup ne supporte pas les partages sans credentials sinon il les affiche comme DOWN.

Du coup, j'ai mis la DXi dans le domaine (via sa patte de management), et j'ai pu définir un utilisateur particulier pour accéder au partage.

Coté NetBackup, j'ai changé le compte lançant les services NetBackup pour utiliser ce fameux utilisateur.

J'ai vérifié que le serveur, quand je me connectais par ce compte, pouvait bien accéder au partage de la DXi, puis j'ai redéfini la STU NetBackup. J'ai relancé la sauvegarde qui est finalement passée.

En espérant que cela puisse servir à d'autres.

jeudi 27 septembre 2012

Full synthetic backup


On connait tous les problèmes de fenêtres de sauvegarde qui explosent. Souvent, c'est le week-end que ça coince, quand on fait nos sauvegardes Full habituelles, et que le réseau a du mal à faire passer tout le flux nécessaire dans les temps.

Il existe un moyen d'améliorer ça sans le moindre investissement : les sauvegardes full synthétiques.

Quezako ?

Le principe est simple : on prend une full, les incrémentales qui ont suivi, et on génère une sauvegarde full à partir de tout ça.

Ce qui donne à peu près ça :


Avantages :

  • Ne transite plus que le réseau, que des sauvegardes incrémentales, bien plus rapides et moins consommatrices de bandes passantes
  • La réalisation de la sauvegarde full est beaucoup plus rapide car n'est plus contrainte par la bande réseau limitée

Inconvénients :

  • Il faut faire une incrémentale juste avant la full Synthétique si on veut garder un niveau de service identique (sinon on ne fait réellement pas de sauvegarde du client le jour de la full)
  • Il faut gérer la 1ère full qui doit être classique, ce qui demande un peu d'administration



Et en plus ça s'optimise !

Si vous utilisez sur votre serveur un mécanisme de déduplication (appliance type DXi ou DataDomain, ou un espace dédupliquant interne au serveur), il est possible de mettre la déduplication à contribution.
En effet, votre espace dédupliquant à déjà tous les blocs de données (puisqu'il héberge la full et les incrémentales), il lui est donc tout à fait facile de générer la nouvelle full, puisque cela ne lui demande que de refaire un nouveau jeu de pointeurs vers des blocs déjà existants.

Contrairement à la version "non optimisée" où la création de la nouvelle full demande de relire les images de sauvegarde déjà faite et de créer la nouvelle (ce qui prend du temps en fonction du volume à traiter, et de la vitesse des équipements), ici la création des pointeurs prends seulement quelques minutes.

C'est fiable docteur ? 

C'est le gros problème de la full synthétique : on a du mal à lui faire confiance. Pourtant, depuis que je l'utilise, aucun souci n'a été remonté, et il n'y a pas de raison pour douter de cette technologie.

On a entendu : "il vaut mieux faire une full tous les mois quand même", mais pourquoi ? Si on doute de la techno dans le temps, pourquoi lui faire confiance pour les sauvegardes hebdomadaires ?

De plus, des vérifications sont mises en oeuvre dans les outils de sauvegarde (voir plus loin)

Sous NetBackup...

Comme c'est mon logiciel de prédilection, je fais un petit focus sur quelques petits points :

Mise en oeuvre : il suffit de cocher la case "Synthétic backup" dans le schedule (qui doit être de type full ou cumulative incremental)

Les limitations :

  • NetBackup ne supporte la synthétique que sur les sauvegardes fichier (polices "standard" et "MS-Windows")
  • Il ne faut pas multiplexer les sauvegardes pour pouvoir faire de la full (l'option à cocher sera grisée sinon)

Sécurisation : NetBackup vérifie que les incrémentales sont bien toutes là lorsqu'il fait la synthétique. Si jamais une des images incrémentales a été expirée avant de faire la synthétique, on aura le droit à un beau code d'erreur 671 signalant une impossibilité de regénérer la full.

mercredi 26 septembre 2012

NetBackup 7.5.0.4 est de sortie

Le 24 septembre, Symantec a sorti sa dernière mise à jour NetBackup, la 7.5.0.4.

Au programme, pas de nouvelle fonctionnalités, mais une grosse séries de corrections de bugs (315 en plus que la 7.5.0.3, 700 en tout !).

On notera tout de même quelques nouveautés :

  • Nbostproxy multiples sur les clients avec déduplication
  • Support des plugins OST tiers sur les appliances

Pour rappel, ces patches peuvent être appliqués sur les clients sans l'appliquer sur les media-servers ou les masters. Il faut cependant que le media-server soit au moins en version 7.5.0.1 (pas de restriction sur le master). Pour plus de précisions, voir la release note.

A noter le changement de méthode de Symantec, qui sort en parallèle la mise à jour sur les appliances N52x0 (Release Update 2.5.1).

Rechercher dans ce blog