VMware ESXi ghettoVCB Backup

Introduzione

In questo articolo vedremo come effettuare il backup online (hot backup) di VM residenti su un server VMware ESXi 4.10 tramite il ghettoVCB script.
In anticipo mi comunico che non ho potuto andare ad esplicare e sindacare ogni dettaglio perchè di utilizzi e configurazioni c’è ne sono ma ho cercato di ricreare alcune situazioni/configurazioni tipo che potrebbero essere utili.

Sommario

• Cosa è il ghettoVCB
• Informazioni preliminari
• Alcune caratteristiche
• Requisiti di funzionamento
• Parametri ghettoVCB
• Utilizzo del ghettoVCB.sh
• Esempi di backup di VM
• Backup con compressione su storage NFS non persistente
• Schedulazione del backup come cronjob
• Meccanismo di lock del file ghettoVCB.sh

Cosa è il ghettoVCB

Il ghettoVCB è un bash script che effettua il backup di VM residenti su un server ESX8(i)3.5/1.x+ utilizzando un metodo simile al VMware VCB tool.

Step effettuati per il backup:

• Creazione degli snapshot delle VM in esecuzione
• Esecuzione backup delle VMDK master
• Eliminazione Snapshot a backup ultimato

Informazioni preliminari

• Possibilità di effettuare backup su storage locale, SAN ed NFS (nella condizione in cui
  lo store NFS non sia di tipo persistente si ha la posibilità tramite lo script di effettuare una connessione automatica alla risorsa, effettuare il backup e poi effettuare la disconnessione)
• Schedulazione programmata dello script con cron (essendo il ghettoVCB non interattivo)
• Possibilità di fornire in input allo script un file di testo con le VM di cui fare il backup (e altre tipologie di situazioni)
• Possibilità di specificare una directory contenente i file di configurazione per il controllo delle politiche di backup
• Nella configurazione attuale lo script prevede la quantità di 3 backup per ogni VM prima di procedere con la sovrascrittura di quelli più vecchi, comportamento questo che si può modificare a seconda delle proprie necessità

Avvertenze: tutto il carico di lavoro è applicato al nodo ESX(i)

Alcune caratteristiche

• Supporto per backup multipli di dischi VMDK per ogni VM
• Viene effettuato il backup solo di VMDK validi
• Backup online
• Possibilità di effettuare lo shutdown GuestOS, iniziare il backup e riffettuare il power On con opzione hardpower timeout
• Consentire gli spazi nella lista backup delle VM (non raccomandato)
• Compressione backup (sperimentale)
• Configurazione delle policy di backup
• Produzione di log
• Modalità di debug
• Supporto per un file di configurazione di tipo globale
• Implementazione di un meccaniscmo di locking per essere sicuri che solo un esecuzione dello script sia possibile sullo stesso host
• Logs dellle e-mail dei backup (sperimentale)

Requisiti di funzionamento

Cosa viene richiesto per il funzionamento (ve lo comunico ma mi sembra estremamente palese come cosa):

• Virtual Machine eseguite su un ESX(i) 3.5/4+ host
• Accesso alla console SSH dell’host

NOTA: Vi faccio presente (per completezza) che la Busybox non è uno strumento ufficiale…

Parametri ghettoVCB

Scarichiamo il ghettoVCB.tar.gz (ad esempio da qui) e facciamone l’upload sul nostro host ESXi 4.1 (nel nostro caso):

Estraiamo il file:

tar -zxvf ghettoVCB.tar.gz (*)

* alcuni comandi come tar non sono presenti nelle cartelle (es: /bin o /sbin) ma se invocati essi rispondono, questo perchè sono integrati all’interno di quello che l’unico file multibinario che è la Busybox.

verrà creata una directory denominata ghettoVCB all’interno della quale troveremo il nostro script ghettoVCB.sh insieme ad altri file, Prima di effettuare il backup ci sono alcuni parametri che possiamo personalizzare direttamente nel file ghettoVCB.sh (logicamente possiamo creare configurazioni non globali anche nel file ghettoVCB.conf).

Parametri ghettoVCB

VM_BACKUP_VOLUME=/path/DIRECTORY_BACKUP (*)

* Se avete un NFS server persistente (per attuarlo fate riferimento a questo articolo )

“path” indica il percorso sul nostro datastore di backup, “DIRECTORY_BACKUP” è la cartella dove verranno salvati i nostri backup, nel momento in cui la cartella non dovesse esistere essa verrà automaticamente creata.

DISK_BACKUP=value

definisce il formato disco del backup che vogliamo utilizzare, i possibili valori sono:
“thin” , “eagerzeroedthick“.”zeroedthick“, “2gbsparse“.

 VM_BACKUP_ROTATION_COUNT=N  (N numero intero)

come detto prima possiamo definire N numero di rotazione del backup e decidere quante
copie di backup differenti per le VM vogliamo tenere prima che le più vecchie inizino ad
essere sovrascritte.

Troviamo adesso le opzioni che ci interesserebbero nel caso volessiamo effettuare un
power off e hard_power_off:

POWER_VM_DOWN_BEFORE_BACKUP=boolean_value (boolean_value: 1=enable,0=disable)

il valore booleano serve a definire l’azione di power off prima del backup della VM palesemente in questo caso il backup non effettuerà lo snapshot perchè non necessario.

ENABLE_HARD_POWER_OFF=boolean_value (boolean_value: 1=enable,0=disable)

nel caso volessimo effettuare un hard power off (ovvero ciò che nella realtà sarebbe un power off brutale della macchina come staccare il cavo d’alimentazione). Tutto ciò è possibile senza i VMware tools installati.

Continuando in questa ipotesi possiamo definire ancora qualche altra opzione, come:

ITER_WAIT_SHUTDOWN=N  (N intero)

definisce un tempo di N secondi prima che venga effettuato l’ hard power off.

POWER_DOWN_TIMEOUT=N  (N intero)

definisce un tempo di N secondi per il quale lo script cercherà di effetuare il
power off della VM dopo il quale ignorerà l’azione di backup per quella particolare VM.

Valori di iterazioni analoghi si possono anche definire per le azioni di snapshoting
delle VM, ovvero:

SNAPSHOT_TIMEOUT=N  (N intero)

N secondi durante il quale lo script aspetterà di effettuare lo snapshot della VM altrimenti ignorerà quell’azione per quella determinata macchina virtuale. Il valore di default attuale è di 15 secondi.

Altra opzione interessante è l’abilitazione della compressione:

ENABLE_COMPRESSIONE=boolean_value   (boolean_value: 1=enable,0=disable)

Facciamo un attimo attenzione perchè potrebbero nascere delle problematiche nel processo di restore. Infatti vi sono delle limitazioni sulla compressione per il backup effettuato tramite la NON ufficiale Busybox.
Precisamente parliamo di un limite massimo di 4GB per la compressione su un host ESX 3.x
e di 8GB per un host ESXi 4.x, preciso che parliamo di questa versione dei backup, questo limite non si presenta nelle modalità classiche di backup.

Servizio interessante ma ancora in fase sperimentale (non funziona con tutti i server mail
poichè la connessione verso essi dallo script viene effettuata tramite il comando “nc”) e usufruibile solo su un host ESXi 4.1 è la notifica tramite mail, di seguito riporterò direttamente un esempio di configurazione senza spiegazione poichè autoesplicativo.

EMAIL_LOG=1
EMAIL_DEBUG=1
EMAIL_SERVER=smtp.example.com
EMAIL_SERVER_PORT=25
[email protected]
[email protected]

Altre variabili interessanti saranno da voi trovate all’interno del file di configurazione ghettoVCB.conf o direttamente nel file ghettoVCB.sh

Utilizzaro del ghettoVCB.sh

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

OPTIONS:

-a  Backup di tutte le VM presnr5ti sull'ost
-f  Lista delle VM di cui fare il backup (*)
-c  Configurazione della directory dove effettuare il backup delle VM
-g  Percorso del file di configurazone globale ghettoVCB
-l  File di output contenente le informazioni di logging
-d  Definice il livello di debug, possibili livelli [info|debuf|dryrun] (quello di default è "info")

Portiamo alcuni semplici esempi di utilizzo:

Effettuare il backup di tutte le VM presenti sul nostro host:

./ghettoVCB.sh -a

Effettuare il backup di tutte le VM presenti sull’host tranne quelle presenti in una lista di esclusione:

./ghettoVCB.sh -a -e lista_vm_escluse

Effettuare il backup di tutte le VM presenti in una lista:

./ghettoVCB.sh -f lista_backup_vm  (*)

* Il file deve contenere nomi delle VM separati da una newline, praticamente la forma sarà del tipo:

~ # cat lista_backup_vm
      CentOS 5.5 64bit
      Debian 5 64bit
      Fedora 13

Effettuare il backup di tutte le VM con file di log:

./ghettoVCB.sh -a -l /var/log/ghettoVCB.log

Esempi di backup

Backup di una VM (nello stato POWERED OFF) il cui nome è presente in un file da dare in input allo script ghettoVCB.sh, direttamente su un NFS storage rappresentanto da un server CentOS

# ./ghettoVCB.sh -f lista_backup_vm

2011-01-17 09:31:58 -- info: ============================== ghettoVCB LOG START ==============================

2011-01-17 09:31:58 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/esxistore/nfs/ESXI_BACKUPS
2011-01-17 09:31:58 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2011-01-17 09:31:58 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-01-17_09-31-58
2011-01-17 09:31:58 -- info: CONFIG - DISK_BACKUP_FORMAT = zeroedthick
2011-01-17 09:31:58 -- info: CONFIG - ADAPTER_FORMAT = buslogic
2011-01-17 09:31:58 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2011-01-17 09:31:58 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2011-01-17 09:31:58 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2011-01-17 09:31:58 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2011-01-17 09:31:58 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2011-01-17 09:31:58 -- info: CONFIG - LOG_LEVEL = info
2011-01-17 09:31:58 -- info: CONFIG - BACKUP_LOG_OUTPUT = stdout
2011-01-17 09:31:58 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2011-01-17 09:31:58 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2011-01-17 09:31:58 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2011-01-17 09:31:58 -- info: CONFIG - EMAIL_LOG = 1
2011-01-17 09:31:58 -- info: CONFIG - EMAIL_SERVER = smtp.provider.com
2011-01-17 09:31:58 -- info: CONFIG - EMAIL_SERVER_PORT = 25
2011-01-17 09:31:58 -- info: CONFIG - EMAIL_FROM = root@ghettoVCB
2011-01-17 09:31:58 -- info: CONFIG - EMAIL_TO = [email protected]
2011-01-17 09:31:58 -- info:

2011-01-17 09:31:59 -- info: Initiate backup for OpenSUSE 11.0
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/esxistore/OpenSUSE 11.0/OpenSUSE 11.0.vmdk'...
Clone: 92% done.
2011-01-17 09:42:56 -- info: Backup Duration: 10.95 Minutes
2011-01-17 09:42:56 -- info: Successfully completed backup for OpenSUSE 11.0!

2011-01-17 09:42:56 -- info: ###### Final status: All VMs backed up OK! ######

2011-01-17 09:42:56 -- info: ============================== ghettoVCB LOG END ================================

Rendendovi noto che ci sono all’interno del file ghettoCVB.sh alcune opzioni da poter configurare come:

– l’umount del datastore NFS al completamento dell’operazione di backup (1=yes, 0=no)

UNMOUNT_NFS=0

– Nome della cartella del backup delle VM residente sul volume NFS

NFS_VM_BACKUP_DIR=mybackups

Sul server che fa anche da NFS server avremo quindi una situazione del genere:

[root@nfs-srv nfs]# ls mybackups/
   OpenSUSE 11.0

Backup di una VM in produzione (nello stato POWERED ON, così da vedere la creazione dello snapshot e la sua rimozione) il cui nome è presente in un file da dare in input
allo script ghettoVCB.sh, direttamente su un NFS storage persistente rappresentanto da un server CentOS.

# ./ghettoVCB.sh -f lista_backup_vm

2011-01-17 09:53:03 -- info: ============================== ghettoVCB LOG START ==============================

2011-01-17 09:53:03 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/esxistore/nfs/ESXI_BACKUPS
2011-01-17 09:53:03 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2011-01-17 09:53:03 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-01-17_09-53-03
2011-01-17 09:53:03 -- info: CONFIG - DISK_BACKUP_FORMAT = zeroedthick
2011-01-17 09:53:03 -- info: CONFIG - ADAPTER_FORMAT = buslogic
2011-01-17 09:53:03 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2011-01-17 09:53:03 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2011-01-17 09:53:03 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2011-01-17 09:53:03 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2011-01-17 09:53:03 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2011-01-17 09:53:03 -- info: CONFIG - LOG_LEVEL = info
2011-01-17 09:53:03 -- info: CONFIG - BACKUP_LOG_OUTPUT = stdout
2011-01-17 09:53:03 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2011-01-17 09:53:03 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2011-01-17 09:53:03 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2011-01-17 09:53:03 -- info: CONFIG - EMAIL_LOG = 1
2011-01-17 09:53:03 -- info: CONFIG - EMAIL_SERVER = smtp.provider.com
2011-01-17 09:53:03 -- info: CONFIG - EMAIL_SERVER_PORT = 25
2011-01-17 09:53:03 -- info: CONFIG - EMAIL_FROM = root@ghettoVCB
2011-01-17 09:53:03 -- info: CONFIG - EMAIL_TO = [email protected]
2011-01-17 09:53:03 -- info:

2011-01-17 09:53:04 -- info: Initiate backup for Windows Server 2008 Enterprise
2011-01-17 09:53:04 -- info: Creating Snapshot "ghettoVCB-snapshot-2011-01-17" for Windows Server 2008 Enterprise
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/esxistore/Windows Server 2008 Enterprise/Windows Server 2008 Enterprise.vmdk'...
Clone: 91% done.
2011-01-17 10:33:23 -- info: Removing snapshot from Windows Server 2008 Enterprise ...
2011-01-17 10:33:23 -- info: Backup Duration: 40.32 Minutes
2011-01-17 10:33:23 -- info: Successfully completed backup for Windows Server 2008 Enterprise!

2011-01-17 10:33:23 -- info: ###### Final status: All VMs backed up OK! ######

2011-01-17 10:33:23 -- info: ============================== ghettoVCB LOG END ================================

Backup su NFS non persistente

Backup di una macchina virtuale powerd on con comprezzione gzip+tar , con mount di una risorsa nfs non persistente, creazione dello snapshot,alla conclusione umount della directory nfs, impostazione del backup rotation di 3 elementi e con opzione di debug:

opzioni interessanti usando ad esempio la configurazione globale:

• Abilitare la compressione di tipo gzip+tar (1=on, 0=off)

ENABLE_COMPRESSION=1

• Numero di baskup per la rotazione

VM_BACKUP_ROTATION_COUNT=5

• Abilitazione NFS non persistente

ENABLE_NON_PERSISTENT_NFS=1

• effettuare l’umount della risorsa NFS quando il backup è stato completato (1=yes, 0=no):

UNMOUNT_NFS=1

• IP Address dell’ NFS Server

NFS_SERVER=172.22.9.30

• Percorso della cartella esportata resiendente sul server NFS

NFS_MOUNT=/mnt/nfs

• Scelta del nome visualizzato per il datastore NFS (lo vedrete tamtie vSphere nell’apposita sezione di storage)

NFS_LOCAL_NAME=my_nfs_ds

• Nome della cartella di backup per le VM residenti sul volume NFS

NFS_VM_BACKUP_DIR=mybackups

Backup con compressione su storage NFS non persistente

./ghettoVCB.sh -f lista_backup_vm -d debug

2011-01-17 15:12:38 -- info: ============================== ghettoVCB LOG START ==============================

2011-01-17 15:12:38 -- debug: Succesfully acquired lock directory - /tmp/ghettoVCB.lock

2011-01-17 15:12:38 -- debug: HOST BUILD: VMware ESXi 4.1.0 build-320137
2011-01-17 15:12:38 -- debug: HOSTNAME: esxi.sviluppo.zucchetti.napoli.it

2011-01-17 15:12:38 -- info: CONFIG - VM_BACKUP_VOLUME =
2011-01-17 15:12:38 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 5
2011-01-17 15:12:38 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-01-17_15-12-38
2011-01-17 15:12:38 -- info: CONFIG - DISK_BACKUP_FORMAT = zeroedthick
2011-01-17 15:12:38 -- info: CONFIG - ADAPTER_FORMAT = buslogic
2011-01-17 15:12:38 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2011-01-17 15:12:38 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2011-01-17 15:12:38 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2011-01-17 15:12:38 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2011-01-17 15:12:38 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2011-01-17 15:12:38 -- info: CONFIG - LOG_LEVEL = debug
2011-01-17 15:12:38 -- info: CONFIG - BACKUP_LOG_OUTPUT = stdout
2011-01-17 15:12:38 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2011-01-17 15:12:38 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2011-01-17 15:12:38 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2011-01-17 15:12:38 -- info: CONFIG - EMAIL_LOG = 1
2011-01-17 15:12:38 -- info: CONFIG - EMAIL_SERVER = mail.cs.interbusiness.it
2011-01-17 15:12:38 -- info: CONFIG - EMAIL_SERVER_PORT = 25
2011-01-17 15:12:38 -- info: CONFIG - EMAIL_FROM = root@ghettoVCB
2011-01-17 15:12:38 -- info: CONFIG - EMAIL_TO = [email protected] 2011-01-17 15:12:38 -- info:

2011-01-17 15:12:39 -- info: Initiate backup for Ubuntu Server 10.4
2011-01-17 15:12:39 -- info: Creating Snapshot "ghettoVCB-snapshot-2011-01-17" for Ubuntu Server 10.4
2011-01-17 15:12:41 -- debug: Waiting for snapshot "ghettoVCB-snapshot-2011-01-17" to be created
2011-01-17 15:12:41 -- debug: Snapshot timeout set to: 900 seconds
2011-01-17 15:12:41 -- debug: /sbin/vmkfstools -i "/vmfs/volumes/esxistore/Ubuntu Server 10.4/Ubuntu Server 10.4.vmdk" -a "buslogic" -d "zeroedthick" "/vmfs/volumes/nfs_storage_backup/mybackups/Ubuntu Server 10.4/Ubuntu Server 10.4-2011-01-17_15-12-38/Ubuntu Server 10.4.vmdk"
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/esxistore/Ubuntu Server 10.4/Ubuntu Server 10.4.vmdk'...
Clone: 94% done.
2011-01-17 15:15:56 -- info: Removing snapshot from Ubuntu Server 10.4 ...
2011-01-17 15:15:56 -- info: Compressing VM backup "/vmfs/volumes/nfs_storage_backup/mybackups/Ubuntu Server 10.4/Ubuntu Server 10.4-2011-01-17_15-12-38.gz"...
2011-01-17 16:18:35 -- debug: Removing /vmfs/volumes/nfs_storage_backup/mybackups/Ubuntu Server 10.4/Ubuntu Server 10.4-2011-01-17_10-54-39
2011-01-17 16:18:38 -- info: Backup Duration: 65.98 Minutes
2011-01-17 16:18:38 -- info: Successfully completed backup for Ubuntu Server 10.4!

2011-01-17 16:18:38 -- info: ###### Final status: All VMs backed up OK! ######

2011-01-17 16:18:38 -- debug: Succesfully removed lock directory - /tmp/ghettoVCB.lock

2011-01-17 16:18:38 -- info: ============================== ghettoVCB LOG END ================================

Troverete adesso sulla vostro storage NFS nell’appropriata cartella un file denominato nel formato che precedentemente ho illustrato, ma questa volta il formato sarà .gz.
Potrei andare avanti con gli esempi di backup con opzioni differenti vedi:

• Con file di log
• Modalità dryrun
• eslusione dal backup di determinate VM
• backup di tutte le VM presenti sull’host ESXI

a non avrebbe molto senso e lascio a voi la prova delle svariate tipologie di backup e configurazioni che potrebbero interessarvi per il contesto in cui operate.

Schedulazione del backup come cronjob

Per chi non lo sapesse la busybox soffre di una limitazione per la quale i lavori svolti dal demone cron non sono persistenti, ovvero al reboot della macchina host questi verrano persi quidi vedremo come settare il crontab e poi effettuare le dovute modifiche per asscurarci la persistenza di queste azioni anche dopo il riavvio dell’host.

Nel caso di un nodo ESXi bisogna aggiungere il nostro comando per il backup schedulato alla fine del file /var/spool/cron/crontabs/root:

~# vi /var/spool/cron/crontabs/root (*)

* il file l’ho trovai settato a 444 quindi necessita un: chmod 644 /var/spool/cron/crontabs/root

ed inseriamo (ad esempio) questa riga:

30 2 * * * /ghettoVCB/ghettoVCB.sh -f /ghettoVCB/lista_backup_vm > /var/log/ghettoVCB-backup-$(date +%d-%m-%y).log

killiamo il demone cron per e riavviamolo per rendere le modifiche effettive:

~ # kill $(pidof crond)
~ # crond

Ora dobbiamo rendere queste modifiche sempre operative anche al reboot del nostro host:
Killiamo il demone crond

~ # kill $(pidof crond)

Editiamo il file /etc/rc.local in modo da rendere sempre disponibili le istruzionid i backup in cron:

~ # vi /etc/rc.local

inseriamo alla fine del file le seguenti righe:

/bin/kill $(pidof crond)
/bin/echo "30 2 * * * /ghettoVCB/ghettoVCB.sh -f /ghettoVCB/lista_backup_vm > /var/log/ghettoVCB-backup-$(date +%d-%m-%y).log" >> /var/spool/cron/crontabs/root
crond

salviamo, chiudiamo il file ed eseguiamo un autobackup in modo da poter far sopravviere el modifiche al reboot:

/bin/autobackup.sh

riavviamo il nostro host e controlliamo che le modifiche siano presenti all’interno del file di cron visto prima.

Meccanismo di lock del file ghettoVCB.sh

Come ho anticipato nelle caratteristiche del ghettoVCB esiste il meccanismo di lock per evitare di eseguire lo stesso processo di backup parallelamente ad uno già in esecuzione sull’ host,
vediamo cosa viene restituito quando tentiamo di mandare in esecuzione lo script ghettoVCB.sh quando già ne è in esecuzione un sua istanza:

~ # ghettoVCB.sh -a

mkdir: cannot create directory '/tmp/ghettoVCB.lock': File exists
2011-01-17 10:32:54 -- info: Failed to acquire lock, another instance of script may be running, giving up on /tmp/ghettoVCB.lock

Con questo ultimo paragrafo abbiamo terminato il nostro giro all’interno del mondo ghettoVCB, sicuramente non abbiamo visto tutte le casistiche immaginabili ma penso sia stato sicuramente un input per la vostra curiosità.

Un saluto

Giovanni Uccio

P.S: In un prossimo articolo forse parlerò di come effettuare il ripristino dei backup delle VM sempre utilizzando uno script del genere….