Esxi Backup GhettoVCB

Introduction

GhettoVCB est un script SH permettant la sauvegarde au chaud ou froid et la restauration de machines virtuelles sous ESX ou ESXi : http://communities.vmware.com/docs/DOC-8760 /

Principe

C’est très simple, avez-vous déjà essaye de copier une machine virtuelle d’un hôte vers un autre sans l’éteindre ? Essayez et vous verrez que cela vous pette une erreur. Pourquoi ? 
Car lorsqu’une VM est allumée, les vmdk ou fichier de disques virtuels sont lockés (verrouilles). Comment faire alors ? C’est simple, pour enlever ce lock sur le vmdk il faut et il 
suffit … de faire un snapshot de la VM. Ah bon ? Ben oui ! Un snapshot après tout c’est quoi ? Un fichier différentiel à partir d’un instant T dans lequel esxi va écrire les modifs 
jusqu’au delete ou merge de ce différentiel. Des lors que le snapshot est créé, le fichier du snapshot est locke et le lock du vmdk initial relâché. Scriptez ce principe et vous 
obtiendrez Ghettovcb.sh. 

Fonctionnalités

Support de backups multiples de VMDKs par VM.
Backup des VMDK valides uniquement.
Backup a chaud.
Possibilité d’éteindre la VM avant d’initier le backup puis de la redémarrer ensuite.
Vérification de la bonne suppression des snapshots issus des backups précédents avant chaque backup.
Les vms contenant déjà des snapshots ne sont pas backupees L .
Possibilité de choisir le type des fichiers de disques de backup des VMDK (split 2Go, …).
Support des disques (virtuels) IDE et SCSI.
Support des VMDk éparpillés sur plusieurs datastores.
Possibilité de compresser les backups (fonctionnalités en beta)
Possibilité de définir des stratégies de sauvegarde différentes selon les VMs.
Possibilité d’inclure/exclure certains vmdk pour une certaine VM.
Création de log de sortie.
Timeout pour l’arrêt des VMS (optionnel) et la création de snapshots.
Snapshots paramétrables (mémoire, etc…).
Debugging durant l’exécution du script.
Support RDM.
Support d’une liste d’exclusion de VMS.
Possibilité de backuper toutes les vms d’un hôte sans passer par une liste.
Mécanismes de locks pour éviter l’exécution simultanée du script plusieurs fois sur le même hote.
Arborescence de répertoires pour les backups (rsync) .
Email de log/resultat (expérimental).
Support Rsync (expérimental).

Installation

Télécharger la dernière version et la mettre sur l'ESXi avec scp ou WinSCP, puis, décompresser l'archive pour l'installer :

# tar -xzf lamw-ghettoVCB-518cef7.tar.gz
# rm lamw-ghettoVCB-518cef7.tar.gz
# mv lamw-ghettoVCB-518cef7 ghettoVCB
# cd ghettoVCB
# ls -hl
-rw-rw-r-- 1 root root   281 Nov 28  2011 README
-rwxrwxr-x 1 root root 15.6k Nov 28  2011 ghettoVCB-restore.sh
-rw-rw-r-- 1 root root   309 Nov 28  2011 ghettoVCB-restore_vm_restore_configuration_template
-rw-rw-r-- 1 root root   356 Nov 28  2011 ghettoVCB-vm_backup_configuration_template
-rw-rw-r-- 1 root root   631 Nov 28  2011 ghettoVCB.conf
-rwxrwxr-x 1 root root 48.2k Nov 28  2011 ghettoVCB.sh

Sauvegarde

La sauvegarde se fait en utilisant le script ghettoVCB.sh

• Configuration

La configuration se fait en modifiant le fichier ghettoVCB.conf

 * VM_BACKUP_VOLUME : Datastore et répertoire dans lequel les sauvegardes sont entreposées, si le répertoire n'existe pas, il sera crée.
 * DISK_BACKUP_FORMAT : Format de disque, peut être paramétré à zeroedthick, eagerzeroedthick, thin ou 2gbsparse.
 * VM_BACKUP_ROTATION_COUNT : Nombre de rotation de sauvegarde pour un machine virtuelle.
 * POWER_VM_DOWN_BEFORE_BACKUP : Indique si le script doit stopper la machine virtuelle avant d'en faire la sauvegarde. Si la VM est stoppe avant sauvegarde, elle ne sera pas 
sauvegarde en utilisant la méthode des cliché instantané (snapshot)
 * ENABLE_HARD_POWER_OFF : Force un arrêt de la VM si l’option précédente est activée et que la VM n’as pas les tools (0=false/non 1=true/oui). 
 * ITER_TO_WAIT_SHUTDOWN : Indique le nombre de minutes d'attente avant l'arrêt brutale d'une machine virtuelle si ENABLE_HARD_POWER_OFF est activé.
 * POWER_DOWN_TIMEOUT : nombre de minutes a attendre avant extinction de la VM avant de l’ignorer et passer a la suivante. 
 * SNAPSHOT_TIMEOUT : nombre de minutes a attendre pendant le snapshot avant d’ignorer et passer a la VM suivante. 
 * ENABLE_COMPRESSION : Activation ou non de la compression. (Expérimental)
 * ADAPTER_FORMAT : Format du contrôleur de stockage des VMDK de sortie (lsilogic | buslogic). 
 * VM_SNAPSHOT_MEMORY et VM_SNAPSHOT_QUIESCE : Activer ou désactiver les options de mémoire et d’attente du snapshot. (Désactivé par défaut)
 * EMAIL_LOG : Activer l’envoi du log par e-mail (0=false/non 1=true/oui)
 * EMAIL_DEBUG : Si l-envoi du mail est OK, en conserver une copie sur l’hôte quand même (0=false/non 1=true/oui)
 * EMAIL_SERVER : Adresse du serveur mail.
 * EMAIL_SERVER_PORT : Port du serveur mail a utiliser.
 * EMAIL_TO : Adresse a laquelle part le mail.
 * EMAIL_FROM : Émetteur du mail.
 * RSYNC_LINK : Support d’un lien symbolique RSYNC. 

• Manuel

SYNTAXE : ./ghettoVCB.sh -f [VM_BACKUP_UP_LIST] -c [VM_CONFIG_DIR] -l [LOG_FILE] -d [DEBUG_LEVEL] -g [GLOBAL_CONF] -e [VM_EXCLUSION_LIST]

OPTIONS :
   -a     Sauvegarder toutes les machines virtuelles de l'hôte.
   -f     Liste des machines virtuelles à sauvegarder.
   -e     Liste des machines virtuelles à exclure de la sauvegarde.
   -c     Dossier contenant un fichier de configuration spécifique à la sauvegarde de machines virtuelles.
   -g     Chemin d'excès du fichier de configuration global de ghettoVCB.
   -l     Fichier journal.
   -d     Niveau de débogage [info|debug|dryrun] (Par défaut: info)

Sauvegarder les VM indiquées dans une liste
        ./ghettoVCB.sh -f vms_to_backup

Sauvegarder toutes les VM d'un hôte
        ./ghettoVCB.sh -a

Sauvegarder toutes les VM d'un hôte sauf celle listées.
        ./ghettoVCB.sh -a -e vm_exclusion_list

Sauvegarder les VM en utilisant la configuration stocké dans un répertoire spécifique
        ./ghettoVCB.sh -f vms_to_backup -c vm_backup_configs

Sauvegarder les VM en utilisant le fichier de configuration global
        ./ghettoVCB.sh -f vms_to_backup -g /global/ghettoVCB.conf

Spécification de l'emplacement des journaux (Ceux-ci sont par défaut dans /tmp/ghettoVCB.log)
        ./ghettoVCB.sh -f vms_to_backup -l /vmfs/volume/local-storage/ghettoVCB.log

Essai à blanc (Aucune sauvegarde ne sera faite)
        ./ghettoVCB.sh -f vms_to_backup -d dryrun

Les fichiers de listes de machines virtuelles à sauvegarder ou exclure est de la forme suivante :

VM01
VM02
VM03

• Utilisation

Les disques des machines virtuelles à sauvegarder ne doivent pas être déclarés comme indépendants, si c'est le cas, un test de sauvegarde à blanc (option -d dryrun) remontera 
l'erreur suivante :

Snapshots can not be taken for indepdenent disks!

Exemple d'utilisation :

# ./ghettoVCB.sh -f ./vm_backup_list -g ./ghettoVCB.conf -l ./testBackup.log
Insufficient arguments.
2012-08-23 14:50:28 -- info: ============================== ghettoVCB LOG START ==============================

2012-08-23 14:50:28 -- info: CONFIG - USING GLOBAL GHETTOVCB CONFIGURATION FILE = ./ghettoVCB.conf
2012-08-23 14:50:28 -- info: CONFIG - VERSION = 2011_11_19_1
2012-08-23 14:50:28 -- info: CONFIG - GHETTOVCB_PID = 9436587
2012-08-23 14:50:28 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/5e909b68-89b5a355
2012-08-23 14:50:28 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2012-08-23 14:50:28 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2012-08-23_14-50-27
2012-08-23 14:50:28 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2012-08-23 14:50:28 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 1
2012-08-23 14:50:28 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2012-08-23 14:50:28 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2012-08-23 14:50:28 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2012-08-23 14:50:28 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2012-08-23 14:50:28 -- info: CONFIG - LOG_LEVEL = info
2012-08-23 14:50:28 -- info: CONFIG - BACKUP_LOG_OUTPUT = ./testBackup.log
2012-08-23 14:50:28 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2012-08-23 14:50:28 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2012-08-23 14:50:28 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2012-08-23 14:50:28 -- info: CONFIG - EMAIL_LOG = 0
2012-08-23 14:50:28 -- info:
Datastore not found.

Datastore not found.

Datastore not found.

2012-08-23 14:50:31 -- info: Powering off initiated for CentOS6.0-MEP-base_ssh_snmp, backup will not begin until VM is off...
2012-08-23 14:50:32 -- info: VM is powerdOff
2012-08-23 14:50:32 -- info: Initiate backup for CentOS6.0-MEP-base_ssh_snmp
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/datastore2/CentOS6Test/CentOS6Test.vmdk'...
Clone: 94% done.
2012-08-23 14:52:50 -- info: Backup Duration: 2.30 Minutes
2012-08-23 14:52:50 -- info: Successfully completed backup for CentOS6.0-MEP-base_ssh_snmp!

Datastore not found.

Datastore not found.

Datastore not found.

2012-08-23 14:52:52 -- info: ###### Final status: All VMs backed up OK! ######

2012-08-23 14:52:53 -- info: ============================== ghettoVCB LOG END ================================

Il est bien entendu possible de rediriger vers /dev/null les messages, ceci est fortement conseillé si GhettoVCB est utilisé via une crontab.

# ./ghettoVCB.sh -f ./vm_backup_list -g ./ghettoVCB.conf -l ./testBackup.log > /dev/null

Une fois la sauvegarde terminée, celle-ci est stocké dans un répertoire du type $VM_BACKUP_VOLUME/$NOM_VM/$NOM_VM-$(date +%Y-%m-%d_%H-%M-%S)/
Ce qui, pour la VM d'exemple ci-dessus donne quelque chose du type :

# ls -hl /vmfs/volumes/ESXBackup/CentOS6.0-MEP-base_ssh_snmp/CentOS6.0-MEP-base_ssh_snmp-2012-08-23_14-50-27/
-rw------- 1 root root 8.0G Aug 23 14:52 CentOS6Test-flat.vmdk
-rw------- 1 root root  516 Aug 23 14:52 CentOS6Test.vmdk
-rwxr-xr-x 1 root root 2.8k Aug 23 14:50 CentOS6Test.vmx
-rw-r--r-- 1 root root   30 Aug 23 14:52 STATUS.ok

Restauration

La restauration d'une sauvegarde se fait en utilisant le script ghettoVCB-restore.sh

Ce script ne fait que restaurer les fichiers de la VM dans un nom de dossier contenant la date de la sauvegarde, si vous restaurez une VM dans un état antérieur (celle-ci n'a pas été supprimé) il sera nécessaire de faire un renommage pour que la VM utilise les fichiers restauré. Si vous restaurer une VM supprimé corp et biens, celle-ci sera automatiquement recrée et visible sous vSphere.

Si lors du démarrage via vSphere d'une VM restaurée de A à Z vous recevez un message vous indiquand que l'UUID provient d'une VM copié ou déplacé, indiquez que vous avez copié ladite VM.

• Configuration

La configuration de la restauration se fait créant un fichier de configuration pour la/les machine(s) virtuelle(s) à restaurer, ce fichier est ensuite donnée à la commande de 
restauration.

Le syntaxe du fichier de configuration est la suivante :

"<DIRECTORY or .TGZ>;<DATASTORE_TO_RESTORE_TO>;<DISK_FORMAT_TO_RESTORE>"

Avec :
 * DIRECTORY or .TGZ : Le répertoire contenant la sauvegarde.
 * DATASTORE_TO_RESTORE_TO : Le Datastore contenant la VM à restaurer.
 * DISK_FORMAT_TO_RESTORE : Nombre indiquant le format de disque-dur de la VM à restaurer. (1 : zeroedthick, 2 : 2gbsparse, 3 : thin, 4 : eagerzeroedthick)
Ajouter une ligne par VM à restaurer, en indiquand plusieurs lignes, il est possible de restaurer plusieurs VM.

Par exemple, pour restaurer la VM précédemment sauvegarder, indiquer la ligne suivante :

"/vmfs/volumes/ESXBackup/CentOS6.0-MEP-base_ssh_snmp/CentOS6.0-MEP-base_ssh_snmp-2012-08-24_08-38-21;/vmfs/volumes/datastore2;3"

• Manuel

SYNTAXE: ./ghettoVCB-restore.sh -c [VM_BACKUP_UP_LIST] -l [LOG_FILE] -d [DRYRUN_DEBUG_INFO]

OPTIONS:
   -c     Liste des machines virtuelles à sauvegarder.
   -l     Fichier journal.
   -d     Essai à blanc/Information de débogage [1|2]

Afficher les messages de sortie à l'écran (pas de fichier journal spécifié)
        ./ghettoVCB-restore.sh -c vms_to_restore

Mettre les messages de sortie dans /tmp/ghettoVCB-restore.log
        ./ghettoVCB-restore.sh -c vms_to_restore -l /tmp/ghettoVCB-restore.log

Essai à blanc/Information de débogage (Pas de restauration)
        ./ghettoVCB-restore.sh -c vms_to_restore -d 1
        ./ghettoVCB-restore.sh -c vms_to_restore -d 2

* Utilisation
<pre>
Exemple d'utilisation :

# ./ghettoVCB-restore.sh -c vm_restore_list
################## Restoring VM: CentOS6.0-MEP-base_ssh_snmp  #####################
Start time: Fri Aug 24 09:10:22 UTC 2012
Restoring VM from: "/vmfs/volumes/ESXBackup/CentOS6.0-MEP-base_ssh_snmp/CentOS6.0-MEP-base_ssh_snmp-2012-08-24_08-38-21"
Restoring VM to Datastore: "/vmfs/volumes/datastore2" using Disk Format: "thin"
Creating VM directory: "/vmfs/volumes/datastore2/CentOS6.0-MEP-base_ssh_snmp-2012-08-24_08-38-21" ...
Copying "CentOS6Test.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "CentOS6Test.vmx" file ...
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/ESXBackup/CentOS6.0-MEP-base_ssh_snmp/CentOS6.0-MEP-base_ssh_snmp-2012-08-24_08-38-21/CentOS6Test.vmdk'...
Clone: 100% done.
Registering CentOS6.0-MEP-base_ssh_snmp ...
608
End time: Fri Aug 24 09:22:39 UTC 2012
################## Completed restore for CentOS6.0-MEP-base_ssh_snmp! #####################


Start time: Fri Aug 24 09:10:22 UTC 2012
End   time: Fri Aug 24 09:22:39 UTC 2012
Duration  : 12.28 Minutes

Crontab

Pour la mise en place dans la crontab, voir : https://wiki.blaxeen.com/index.php/Esxi#Crontab

Statistiques

Le backup est la restauration ont un effet bien sur sur le cpu, reseau et I/O de l'esxi plus ou moins important suivant

Test de sauvegarde :
- VM éteinte : 8 Gio en 2 minutes 30
- VM allumé (sauvegarde par cliché instantané) : 8 Gio en 2 minutes 42 (Ping vers esxi-ins à 0,8 ~ 0,9 ms pendant la sauvegarde, 0,11 ms après)

Test de restauration (Disque-dur supprimée de la VM et recrée vierge via vSphere) :
- Restauration via GhettoVCB : 8 Gio en 12 minutes 28.
- Demande un renommage/déplacement de fichier ou dossier.
- Machine fonctionnelle, disque restaurée convenablement.

Test de restauration d'une VM (VM totalement supprimée via vSphere) :
- Restauration via GhettoVCB : 8 Gio en 12 minutes 28.
- VM recrée sous vSphere automatiquement.
- Machine fonctionnelle, disque restaurée convenablement.
- Remarque de vSphere au démarrage de la VM indiquant que son UUID provient d'une VM copiée, clonée ou déplacée.