Re: Problema di configurazione Mksbackup

luno · ‎02-21-2014

Salve a tutti,

ho creato una VM utilizzando Esxi 5.5.0 e vorrei backupparla in un nas utilizzando MKsbackup.

La struttura utilizzata è la seguente:

Server fisco con ip 192.168.50.160, avviato da chiavetta di avvio dove risiede Esxi Hypervisor.

Nello storage del server è installata una VM con Windows 2008.

Nas con ip 192.168.50.161.

Computer con ip 192.168.50.170 dove è installato VSphere e Mksbackup (ghettovcb).

Vorrei copiare la vm nel nas

Il file di configurazione di Mksbackup.ini che ho utillizzato è il seguente:

[VMWARE]

program=ghettovcb

host=192.168.50.160

port=22

login=root

password=miapassword

local=C:\magik\vmware

global_conf=ghettoVCB.conf

vm_list=linux-vm windows-vm

#ftp_local=ftp://192.168.1.23/d/Backup/vmware

destination=<backup=mon-thu>

<copy=fri>/nfs/Backups${vm}-${nweekdayname}

Ho modificato la prima riga di ghettovcb nel seguente modo:

VM_BACKUP_VOLUME=192.168.50.161/vmfs/nfs/Backups/VServer01 (Destinazione del backup della vm.)

Quando lancio il backup dal computer dove è residente VSphere (e non dal server) mi viene restituito il seguente log:

2014-02-14 10:26:46 INF start version=1.0.4 cmd=['C:\\Magik\\MKSBackup\\mksbackup.exe', '-d', '-c', 'C:\\Magik\\mksbackup.ini', 'backup', 'VMWARE']

2014-02-14 10:26:46 ERR job not found: VMWARE

2014-02-21 10:02:28 INF start version=1.0.4 cmd=['C:\\Magik\\mksbackup.exe', '-d', '-c', 'C:\\Magik\\mksbackup.ini', 'backup', 'VMWARE']

2014-02-21 10:02:37 DEB this version of ghettovcb wait before to unmount the NFS share

2014-02-21 10:02:40 INF cmd_line=cd "/tmp/vmware" ; ./"ghettoVCB.sh" -d debug -c "/tmp/vmware" -f "/tmp/vmware/include_vm" -g "/tmp/vmware/ghettoVCB.conf" ; echo exit_code=$?

2014-02-21 10:02:40 INF No errors in section: VMWARE

2014-02-21 10:02:40 INF start command=backup job=VMWARE archiver=ghettovcb

2014-02-21 10:02:40 INF ghettoVCB.sh version is: 2012_12_17_0mksbackup nfs_wait=True

2014-02-21 10:02:41 INF start: cd "/tmp/vmware" ; ./"ghettoVCB.sh" -d debug -c "/tmp/vmware" -f "/tmp/vmware/include_vm" -g "/tmp/vmware/ghettoVCB.conf" ; echo exit_code=$?

2014-02-21 10:02:41 DEB Logging output to "/tmp/ghettoVCB-2014-02-21_09-57-51-234978.log" ...

2014-02-21 10:02:41 DEB You're not running ESX(i) 3.5, 4.x, 5.x!

2014-02-21 10:02:41 DEB exit_code=1

2014-02-21 10:02:41 DEB exit_code=0 command=df ; echo exit_code=$?

2014-02-21 10:02:41 DEB > Filesystem Bytes Used Available Use% Mounted on

2014-02-21 10:02:41 DEB > NFS 876477657088 212062208 876265594880 0% /vmfs/volumes/NAS

2014-02-21 10:02:41 DEB > VMFS-5 1195879956480 224539967488 971339988992 19% /vmfs/volumes/VServer01

2014-02-21 10:02:41 DEB > vfat 261853184 164659200 97193984 63% /vmfs/volumes/e19bbeed-01e82b89-0e9e-a5b2e1bb7a7e

2014-02-21 10:02:41 DEB > vfat 261853184 8192 261844992 0% /vmfs/volumes/b59971ee-20fbbefa-210e-712cd776fdc3

2014-02-21 10:02:41 DEB > vfat 299712512 200564736 99147776 67% /vmfs/volumes/52fa11f7-01734a2c-c22f-40f2e996aae2

2014-02-21 10:02:41 DEB >

2014-02-21 10:02:41 DEB exit_code=0 command=ls -l /vmfs/volumes ; echo exit_code=$?

2014-02-21 10:02:41 DEB > total 1796

2014-02-21 10:02:41 DEB > drwxrwxrwx 1 99 users 4096 Feb 14 11:52 4293aff3-b9184070

2014-02-21 10:02:41 DEB > drwxr-xr-x 1 root root 8 Jan 1 1970 52fa11f7-01734a2c-c22f-40f2e996aae2

2014-02-21 10:02:41 DEB > drwxr-xr-t 1 root root 1680 Feb 13 10:32 52fa6025-6117a754-1cb1-40f2e996aae2

2014-02-21 10:02:41 DEB > lrwxr-xr-x 1 root root 17 Feb 21 09:57 NAS -> 4293aff3-b9184070

2014-02-21 10:02:41 DEB > lrwxr-xr-x 1 root root 35 Feb 21 09:57 VServer01 -> 52fa6025-6117a754-1cb1-40f2e996aae2

2014-02-21 10:02:41 DEB > drwxr-xr-x 1 root root 8 Jan 1 1970 b59971ee-20fbbefa-210e-712cd776fdc3

2014-02-21 10:02:41 DEB > drwxr-xr-x 1 root root 8 Jan 1 1970 e19bbeed-01e82b89-0e9e-a5b2e1bb7a7e

2014-02-21 10:02:41 DEB >

2014-02-21 10:02:41 INF end command=backup job=VMWARE archiver=ghettovcb

2014-02-21 10:02:41 INF name=VMWARE

2014-02-21 10:02:41 INF program=ghettovcb

2014-02-21 10:02:41 INF version=1.0.4

2014-02-21 10:02:41 INF status=ERR

2014-02-21 10:02:41 INF hostname=Pc01

2014-02-21 10:02:42 INF exit_code=1

2014-02-21 10:02:42 INF start=Fri Feb 21 10:02:40 2014

2014-02-21 10:02:42 INF end_ghettovcb=Fri Feb 21 10:02:41 2014

2014-02-21 10:02:42 INF end=Fri Feb 21 10:02:41 2014

2014-02-21 10:02:42 INF start_epoch=1392973360

2014-02-21 10:02:42 INF end_epoch=1392973361

2014-02-21 10:02:42 INF end_ghettovcb_epoch=1392973361

2014-02-21 10:02:42 INF type=backup

2014-02-21 10:02:42 INF ghettovcb_status=ERR

2014-02-21 10:02:50 INF mail sent to: miaemail@miodominio.it

2014-02-21 10:02:50 INF final exit code=1

Se vado a vedere nel nas nella cartella di destinazione (192.68.50.161/backups/Vserver01) non trovo il backup.

Evidentemente ho sbagliato a inserire qualche parametro. Cosa posso verificare?

Grazie a tutti

scanda · ‎03-14-2014

Non ho mai utilizzato MKSbackup, di solito utilizzo ghettoVCB direttamente sul server esx.

Collega la NAS via NFS al server esx in modo da usare un path locale invece che via nfs da ghettoVCB, installa ghettoVCB sull'esx, configura opportunatamente lo script ed esegui un backup.

Trovi tutto su ghettoVCB.sh - Free alternative for backing up VM's for ESX(i) 3.5, 4.x & 5.x

saluti

luno · ‎03-21-2014

Grazie per la risposta.

In nas è collegato via NFS al server esxi (lo vedo da VSphere --> configuration --> Storage)

Il mio dubbio è quello di sbagliare i percorsi di destinazione e sorgente.

Se, ad esempio, eseguo il backup da un pc Windows devo utilizzare percorsi nel file di configurazione di ghetto tipo:

sorgente=\\192.168.1.10\nome della macchina virtuale

destinazione=\\192.168.1.20\percorso destinazione

Se invece il backup lo lancio direttamente dall'host (esxi hypervisor) devo utilizzare percorsi tipo:

sorgente=vmf/volumes/nome della macchina virtuale da copiare

destinazione=nfs/backups (in questo caso la destinazione è un NAS)

Il mio ragionamento è giusto?

Grazie

scanda · ‎03-24-2014

Per i percorsi da utilizzare dal pc non ti so dire, non l'ho mai usato in questa modalità.

Per l'utilizzo da esxi ti devi sempre basare sui datastore locali, l'nfs l'hai già collegato via NFS quindi lo dovresti trovare sotto /vmfs/volumes.

Le VM le specifichi via nome e non via path sul datastore, puoi anche passare allo script un file con i nomi delle VM di cui effettuar eil backup.

La documentazione di ghettovcb riporta molti esempi di utilizzo :

ghettoVCB.sh - Free alternative for backing up VM's for ESX(i) 3.5, 4.x & 5.x

saluti

luno · ‎03-24-2014

Sono riuscito a fare funzionare ghetto grazie alla guida segnalata.

Anche se sembra tutto ok mi vengono segnalati dei messaggi.

Allego il log per chiarimento dove ho segnato in grassetto e corsivo i messaggi di errore.

===================================================================================

Logging output to "/tmp/ghettoVCB-2014-03-24_11-36-11-2736890.log" ...

Insufficient arguments.

2014-03-24 11:36:12 -- info: ============================== ghettoVCB LOG START

2014-03-24 11:36:12 -- info: CONFIG - VERSION = 2012_12_17_0mksbackup

2014-03-24 11:36:12 -- info: CONFIG - GHETTOVCB_PID = 2736890

2014-03-24 11:36:12 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/4293aff3-b9184070/Backups

2014-03-24 11:36:12 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3

2014-03-24 11:36:12 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2014-03-24_11-36-11

2014-03-24 11:36:12 -- info: CONFIG - DISK_BACKUP_FORMAT = thin

2014-03-24 11:36:12 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0

2014-03-24 11:36:12 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0

2014-03-24 11:36:12 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3

2014-03-24 11:36:12 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5

2014-03-24 11:36:12 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15

2014-03-24 11:36:12 -- info: CONFIG - LOG_LEVEL = info

2014-03-24 11:36:12 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2014-03-24_11-36-11-2736890.log

2014-03-24 11:36:12 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0

2014-03-24 11:36:12 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0

2014-03-24 11:36:12 -- info: CONFIG - ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP = 1

2014-03-24 11:36:12 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all

2014-03-24 11:36:12 -- info: CONFIG - VM_SHUTDOWN_ORDER =

2014-03-24 11:36:12 -- info: CONFIG - VM_STARTUP_ORDER =

2014-03-24 11:36:12 -- info: CONFIG - EMAIL_LOG = 0

2014-03-24 11:36:12 -- info:

Datastore not found.

2014-03-24 11:36:17 -- info: Initiate backup for VServer01 Windows Server

2014-03-24 11:36:17 -- info: Creating Snapshot "ghettoVCB-snapshot-2014-03-24" for VServer01 Windows Server

Destination disk format: VMFS thin-provisioned

Cloning disk '/vmfs/volumes/Storage/VServer01 Windows Server/VServer01 Windows Server.vmdk'...

Clone: 99% done.

2014-03-24 12:19:56 -- info: Removing snapshot from VServer01 Windows Server 2008 R2 ...

2014-03-24 12:19:56 -- info: Backup Duration: 43.65 Minutes

2014-03-24 12:19:56 -- info: Successfully completed backup for VServer01 Windows Server 2008 R2!

===================================================================================

Grazie

scanda · ‎03-24-2014

Verifica l'opzione VM_BACKUP_VOLUME, il percorso che hai inserito probabilmente non è corretto.

Dovrebbe essere qualcosa tipo /vmfs/volumes/datastoreXXX

luno · ‎03-26-2014

Si ho modificato la path del datastore da /vmfs/volumes/4293aff3-xxxxxx/Backups a /vmfs/volumes/NAS/Backups e adesso non viene più visualizzato l'errore.

Ma non capisco due cose:

1) come mai il backup veniva eseguito comunque.

2) che differenza c'è tra i due percorsi?

grazie ancora.

scanda · ‎03-26-2014

Sicuro che il backup veniva eseguito comunque? nella NAS esterna trovavi la VM copiata?

I tempi di esecuzione di ghettovcb possono essere molto lunghi se le VM sono grandi.

Riguardo alla nomenclatura dei path dei datastore non so dirti della differenza, probabilmente è una mappatura interna dell'esx.

saluti

luno · ‎03-27-2014

Si nel NAS esterno la macchina virtuale è stata copiata correttamente, anche perché il backup è durato molto.

Comunque effettuerò un'ulteriore verifica.

Al momento grazie per il supporto.