Ich habe mein ghettoVCB.conf File folgendermassen konfiguriert (ist eingentlich alles Standard):<\/p>\n
VM_BACKUP_VOLUME=\/vmfs\/volumes\/65d7a6db-6bc8d65a\/VmBackups\r\nDISK_BACKUP_FORMAT=thin\r\nVM_BACKUP_ROTATION_COUNT=1\r\nPOWER_VM_DOWN_BEFORE_BACKUP=0\r\nENABLE_HARD_POWER_OFF=0\r\nITER_TO_WAIT_SHUTDOWN=3\r\nPOWER_DOWN_TIMEOUT=5\r\nENABLE_COMPRESSION=0\r\nVM_SNAPSHOT_MEMORY=0\r\nVM_SNAPSHOT_QUIESCE=0\r\nSNAPSHOT_TIMEOUT=15<\/pre>\nVMs zum Backup<\/h2>\n
Habe ein File „vms_to_backup“ erstellt, welches eine Liste der Namen der VMs beinhaltet. Bei den Namen handelt es sich um die Namen, welche auch im vSphereClient angezeigt werden:<\/p>\n
TestVM32Bit<\/pre>\nBackup run<\/h2>\n
Nun kann die VM im laufenden Zustand gebackuped werden (Option -d dryrun f\u00fchrt einen Testlauf durch):<\/p>\n
.\/ghettoVCB.sh -f vms_to_backup -g .\/ghettoVCB.conf -d dryrun<\/pre>\nBackup automatisch durchf\u00fchren (Cron-Tab)<\/h1>\n
Um das Backup automatisch durchzuf\u00fchren, kann dies in der Cron-Tab von ESXi konfiguriert werden:<\/p>\n
In Crontab registrieren, Job soll jeden Donnerstag um 17:00 Uhr durchgef\u00fchrt werden<\/p>\n
echo \"0 17 * * 4 \/vmfs\/volumes\/4a6bb65f-eb654b7b-2525-d8d385ab5bd2\/ghettoVCB\/ghettoVCB.sh -f \/vmfs\/volumes\/4a6bb65f-eb654b7b-2525-d8d385ab5bd2\/ghettoVCB\/vms_to_backup -g \/vmfs\/volumes\/4a6bb65f-eb654b7b-2525-d8d385ab5bd2\/ghettoVCB\/ghettoVCB.conf > \/tmp\/ghettoVCB.log\" >> \/var\/spool\/cron\/crontabs\/root\r\n<\/pre>\nWenn man dies Ausf\u00fchrt, wird der crontab automatisch an die richtige Datei angeh\u00e4ngt.
\nNun muss crond neu gestartet werden:<\/p>\n
ESXi 4.1<\/h3>\n\/bin\/kill $(cat \/var\/run\/crond.pid)\r\n<\/pre>\n\/bin\/busybox crond<\/pre>\nDie Cron-Tab von ESXi wird bei jedem Start wieder neu geschrieben. Um die Zeile deswegen bei jedem Start auszuf\u00fchren, muss diese noch in die \/etc\/rc.local eingetragen werden. Meine rc.local sieht anschliessend so aus:<\/p>\n
vi \/etc\/rc.local\r\n<\/pre>\n #! \/bin\/ash\r\nexport PATH=\/sbin:\/bin\r\n\r\nlog() {\r\necho \"$1\"\r\nlogger init \"$1\"\r\n}\r\n\r\n#execute all service retgistered in \/etc\/rc.local.d\r\nif [ -d \/etc\/rc.local.d ]; then\r\nfor filename in `find \/etc\/rc.local.d\/ | sort`\r\ndo\r\nif [ -f $filename ] && [ -x $filename ]; then\r\nlog \"running $filename\"\r\n$filename\r\nfi\r\ndone\r\nfi\r\n\r\n\/bin\/kill $(cat \/var\/run\/crond.pid)\r\n\/bin\/echo \"0 17 * * 4 \/vmfs\/volumes\/4a6bb65f-eb654b7b-2525-d8d385ab5bd2\/ghettoVCB\/ghettoVCB.sh -f \/vmfs\/volumes\/4a6bb65f-eb654b7b-2525-d8d385ab5bd2\/ghettoVCB\/vms_to_backup -g \/vmfs\/volumes\/4a6bb65f-eb654b7b-2525-d8d385ab5bd2\/ghettoVCB\/ghettoVCB.conf > \/tmp\/ghettoVCB.log\" >> \/var\/spool\/cron\/crontabs\/root\r\ncrond<\/pre>\nESXi 5.5<\/h3>\nkill $(cat \/var\/run\/crond.pid)<\/pre>\ncrond\r\n<\/pre>\nDie Cron-Tab von ESXi wird bei jedem Start wieder neu geschrieben. Um die Zeile deswegen bei jedem Start auszuf\u00fchren, muss diese noch in die \/etc\/rc.local eingetragen werden. Meine rc.local sieht anschliessend so aus:<\/p>\n
vi \/etc\/rc.local.d\/local.sh\r\n<\/pre>\n#!\/bin\/sh\r\n\r\n# local configuration options\r\n\r\n# Note: modify at your own risk! If you do\/use anything in this\r\n# script that is not part of a stable API (relying on files to be in\r\n# specific places, specific tools, specific output, etc) there is a\r\n# possibility you will end up with a broken system after patching or\r\n# upgrading. Changes are not supported unless under direction of\r\n# VMware support.\r\n\/bin\/kill $(cat \/var\/run\/crond.pid)\r\necho \"0 17 * * 4 \/vmfs\/volumes\/54016b12-54a601dc-1d3c-d43d7e942aae\/ghettoVCB\/ghettoVCB.sh -f \/vmfs\/volumes\/54016b12-54a601dc-1d3c-d43d7e942aae\/ghettoVCB\/vms_to_backup -g \/vmfs\/volumes\/54016b12-54a601dc-1d3c-d43d7e942aae\/ghettoVCB\/ghettoVCB.conf > \/tmp\/ghettoVCB.log\" >> \/var\/spool\/cron\/crontabs\/root\r\ncrond\r\nexit 0<\/pre>\nNun nur noch autobackup durchf\u00fchren, das ganze in der ESXi Konfuguration zu speichern:<\/p>\n
\/sbin\/auto-backup.sh<\/pre>\nDas wars! Jetzt werden die VMs automatisch regelm\u00e4ssig gesichert.<\/p>\n
Restore durchf\u00fchren<\/h1>\n
Um einen Restore druchzuf\u00fchren, habe ich ein file vms_to_restore erstellt, wobei dieses pro Linie einen Restore-Parameter mit folgendem Format enthalten muss:<\/p>\n
\";;\"\r\n# DISK_FORMATS\r\n# 1 = zeroedthick\r\n# 2 = 2gbsparse\r\n# 3 = thin\r\n# 4 = eagerzeroedthick\r\n<\/pre>\nz.B.:<\/p>\n
\"\/vmfs\/volumes\/QnapTSDatastore\/VmBackups\/TestVM32Bit\/TestVM32Bit-2013-01-03_13-25-54;\/vmfs\/volumes\/ESXi Raid1\/TestVM;3\"\r\n<\/pre>\nAnschliessend kann das Restore folgendermassen gestartet werden (Option -d 2 = Dryrun):<\/p>\n
.\/ghettoVCB-restore.sh -c vms_to_restore -d 2\r\n<\/pre>\nDies stellt das von ghettoVCB erstellte Backup „TestVM32Bit-2013-01-03_13-25-54“ unter dem Pfad „\/vmfs\/volumes\/ESXi Raid1\/TestVM“ her bzw. kopiert diese dahin und registriert die VM neu beim ESXi-Host.<\/p>\n
Die Fileformate<\/h1>\nzeroedthick (default)<\/h2>\n
vmdk wird in voller Groesse angelegt – dieser Typ wird bei der Erstellung nicht mit Nullen ueberschrieben – das passiert erst spaeter im Betrieb<\/p>\n
eagerzeroedthick<\/h2>\n
vmdk wird in voller Groesse angelegt – dieser Typ wird bei der Erstellung mit Nullen ueberschrieben<\/p>\n
thick<\/h2>\n
vmdk wird in voller Groesse angelegt – und nie genullt<\/p>\n
thin<\/h2>\n
vmdk waechst nach Bedarf – dies ist ein Feature des VMFS dateisystems – und ist auf den meisten NFS-servern nicht moeglich<\/p>\n
2gbsparsed<\/h2>\n
vmdk wird in maximal 2 Gb grosse Stuecke aufgeteilt – die jeweils nach Bedarf wachsen – dieses Format ist it Workstation kompatibel<\/p>\n","protected":false},"excerpt":{"rendered":"
Um Backups von ESXi VMs im laufenden Zustand machen zu k\u00f6nnen, braucht es Verst\u00e4ndnis was VmWare unter einem Snapshot versteht Das Scipt ghettoVCB.sh => \u00a0ghettoVCB Exkurs VMWare-Snapshot Bei einem VMware Snapshot wird eine weitere Festplattendatei erstellt welche ab Zeitpunkt des Snapshots alle ge\u00e4nderten Bl\u00f6cke aufnimmt. Gleichzeitig wird der Exklusiv Zugriff auf die Basis Festplatte aufgehoben […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[8],"tags":[],"class_list":["post-328","post","type-post","status-publish","format-standard","hentry","category-vm-ware-esxi"],"modified_by":"ralph","_links":{"self":[{"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=\/wp\/v2\/posts\/328","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=328"}],"version-history":[{"count":9,"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=\/wp\/v2\/posts\/328\/revisions"}],"predecessor-version":[{"id":1278,"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=\/wp\/v2\/posts\/328\/revisions\/1278"}],"wp:attachment":[{"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=328"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=328"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dev-metal.ch\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=328"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}