Für die VMware Plattform werden Storage-Systeme von NetApp eingesetzt. Der Storage wird über NFS an den VMware Servern angebunden. Für diese Konstellation existiert bisher kein Standard Verfahren zur konsistenten Sicherung der virtuellen Maschinen (Ausnahme SnapManager von NetApp, dieser kann zurzeit aber noch kein Single File Recover und keinen SnapMirror / SnapVault).
Die Idee hinter dem hier beschriebenen Tool besteht darin, mit den VMware-Mitteln einen Snapshot der virtuellen Maschinen zu generieren und anschließend für den Storagebereich einen NetApp Snapshot zu erzeugen. Dieser konsistente Zustand kann anschließend weitergeleitet werden (Spiegelung SnapMirror, SnapVault, Bandsicherung). Nach dem Erzeugen des NetApp Snapshots wird der VMware Snapshot wieder aufgelöst. Hiernach wird für jede VM versucht deren Platten Partitinionierung zu ermitteln. Abhängig von der Konfiguration ist die Sicherung hiermit beendet, oder es folgt eine Spiegelung und/oder eine Band-Sicherung.
Folgende Einschränkungen sind zurzeit noch existent:
Auf dem Sicherungsserver (NetWorker Client) müssen folgende Softwarepakete installiert sein:
Der NetApp Filer muss folgende Voraussetzungen erfüllen:
Für die verschiedenen Methoden werden folgende NetApp Lizenzen benötigt
SNAP Restore: wird für das schnelle Wiederherstellen eines kompletten DataStore benötigt. Macht aber nur bei größeren Systemproblemen Sinn, da hierbei alle dort installiert VMs zurückgesetzt würden. SNAP Mirror Spiegeln des DatatStores auf einen Nearstore Filer; Diese Lizenz wird auf dem Storage Filer und dem Spiegel Filer Nearstore benötigt. SNAP Vault Primary Sichern des DataStores auf einen Nearstore Filer. Diese Lizenz wird nur auf dem DB-Storage Filer benötigt. SNAP Vault Secondary Diese Lizenz wird nur auf dem Nearstore Filer benötigt. FlexClone Diese Lizenz wird nicht unbedingt benötigt, ermöglicht aber ein schnelles Recover einzelner Dateien für Linux VMs.Wenn diese Lizenz vorhanden ist braucht das Image der wiederherzustellenden Maschine nicht kopiert zu werden.
Wenn der DataStore für Sicherungszwecke gespiegelt werden soll, muss die SnapVault Verbindung in der snapvault.conf Datei konfiguriert sein. Da das Tool den Namen der Snapshots und deren Verwendung selbst bestimmen möchte, wird hier ein Qtree SnapMirror Konfiguration verlangt. Die Konfiguration sollte auch keine automatische Synchronisation des Spiegels verwenden, da diese ja immer inkonsistent wäre.
Das Tool verwendet für die Kommunikation die NetApp eigene API Schnittstelle.
Wenn ein Recover einzelner Dateien, für LINUX Maschinen, ohne FlexClone durchgeführt werden muss, so wird auf dem "primary Storage" ein vorbereitetes Volume vorausgesetzt. Dieses Volume muss folgende Eigenschaften besitzen:
Für den Start der Sicherung werden einige NetWorker Ressourcen benötigt.
Für jeden VMware Datastore wird ein oder mehrere NetWorker Client Konfigurationen benötigt.
Die Idee ist, das ein Client für die ausschließliche Snapshot Sicherung definiert werden kann, und ein zweiter Client die Bandsicherung initiiert. Welche Sicherung gewünscht wird steuert der angegebene SaveSet.
Für jeden Client wird eine eigene Gruppe benötigt. Die eine Gruppe startet u.U. mehrmals am Tag, die andere lediglich einmal und sichert dann den DataStore auf Tape.
Da es sich nicht um "normale" NetWorker Sicherungen handelt benötigen wir immer den Level Full.
|
Parameter
|
Erklärung
|
| NA_FILER=nafiler7 | NetApp Filer auf dem der DataStore gehostet wird. (primary Storage) |
| NSR_SERVER=<server> | |
| NSR_POOL=I2KPDB_21DAYS | NetWorker Pool in dem die Sicherung gespeichert werden soll |
| INFR_STR_SRV=172.18.131.212 | Adresse oder Name des VMware Infrastructure Servers auf dem der Datastore angebunden ist |
| #VC_PORT | TCP Port Nr. wird nur benötigt wenn ein anderer Port für die API Kommunikation gewählt wurde |
| #VC_USER | Wird nur benötigt wenn nicht der Standard Benutzer verwendet wird |
| #VC_PWD | Wird nur benötigt wenn nicht der Standard Benutzer verwendet wird |
| NDMP_USER | Wird für den Recover kompletter VMs vom "secondary Storage" benötigt. Dieser Benutzer muss auf dem "secondary Filer" existieren. |
| NDMP_PASSWORD | Wird für den Recover kompletter VMs vom "secondary Storage" benötigt. Das Passwort muss das NDMP-Passwort des "secondary Filer" Benutzers sein. |
| PRE_CMD=172.18.131.233:root:"/home/uws/test.sh pre" |
Pre Cmd das vor dem erzeugen der Snapshots auf der virtuellen Maschine ausgeführt werden soll. Der erste Unterparameter ist "der Name oder die Adresse" der jeweiligen Machine. Der zweite Parameter ist der Benutzer mit dem eine SSH Verbindung an dem Rechner aufgebaut werden soll. Die SSH Verbindung muss ohne Eingabe eines Passworts möglich sein. Der dritte Parameter ist das auszuführende Kommando. ACHTUNG wenn Optionen übergeben werden an einschließende Hochkommas denken. |
| POST_CMD=172.18.131.233:root:"/home/uws/test.sh post" | Das Post Kommando, das nach dem Löschen des VMware Snapshots auf der virtuellen Maschine aufgerufen werden soll. |
| # NSR_DSA_SAVE= | zukünftige Alternative wenn die Daten nicht am Filer lokal gesichert werden können (noch nicht implementiert) |
| ONLY_SNAP_RETENTION_DAYS=6 | Aufbewahrungszeit der Snapshots auf dem
primär System; (Der Parameter darf leer sein) |
| SNAP_MIRROR_RETENTION_DAYS=7 | Aufbewahrungszeit des Snapshots auf dem
Mirror Volume; (Der Parameter darf leer sein) |
| SNAP_VAULT_RETENTION_DAYS= | Aufbewahrungszeit des Snapshots auf dem
Vault Volume; (Der Parameter darf leer sein) |
| NSR_NDMP_RETENTION_DAYS=21 | Aufbewahrungszeit der NDMP Sicherungen
auf den NetWorker Bändern; (Der Parameter darf leer sein) |
| RETENTION_DAYS=10 | Default Aufbewahrungszeit. Dieser Wert wird immer dann herangezogen wenn einer der oben angegebenen Retention Werte nicht gesetzt ist. |
| SKIP_VM_SNAPS= |
Liste von Maschinen für die kein VMware Snapshot generiert werden soll Die Definition der Liste empfiehlt sich mit Hilfe der WWW Konfigurationsseite durchzuführen (s.u.) |
| NO_PARTITION_INFO="uwetest, instJochen" |
Liste von Maschinen für die keine Pratitionsinformation erzeugt werden soll. Diese Ausnahme kann für Testmaschinen etc. sinnvoll sein. Die Definition der Liste empfiehlt sich mit Hilfe der WWW Konfigurationsseite durchzuführen (s.u.) ACHTUNG: Wenn keine Partitioninfo erzeugt wird, können keine einzel Dateien für die betreffende virtuelle Maschine wiederhergestellt werden! |
| SAVE_VM_WITH_NDMP= |
Liste virtueller Maschinen für die eine NDMP-Sicherung gewünscht ist. Dieser Parameter wirkt nur in Verbindung mit dem SaveSet NDMP. Wenn der Parameter nicht gesetzt ist wir der ganze Datastore gesichert. Die Definition der Liste empfiehlt sich mit Hilfe der WWW Konfigurationsseite durchzuführen (s.u.) |
| SAVEPROT_COUNT=100 |
Anzahl von zu haltenden Protokollen |
Für jeden BACKUP_TYPE muss eine eigene NetWorker Gruppe definiert werden!
Hierbei empfiehlt sich für den Typ ONLY_SNAP bzw. SNAP_MIRROR das Attribut Intervall zu ändern, wenn mehr als eine Sicherung pro Tag gewünscht wird! ACHTUNG in dem Fall muss auch das Attribut "force incrementell" auf "No" gesetzt werden!
Für jeden BACKUP_TYPE muss ein eigener Client definiert werden!
Hierbei definiert das Attribut "Save Set" den zu sichernden
VMware-Datastore und die Art der Sicherung.
save set: <VMware Datastore>:<BACKUP_TYPE>
BACKUP_TYPE: ONLY_SNAP | NDMP_BACKUP | SNAP_MIRROR | SNAP_VAULT | SNAP_MIRROR_NDMP | SNAP_VAULT_NDMP
ONLY_SNAP: Es wird ein VMware Snapshot der virtuellen Maschinen des Datastore initiiert, anschließend wird ein NetApp Snapshot des zugrundeliegenden Volumes generiert, hienach werden die VMware Snapshots wieder aufgelöst. Der NetApp Snapshot wird für "ONLY_SNAP_RETENTION_DAYS" aufgehoben.
NDMP_BACKUP: Alle Schritte des Typs ONLY_SNAP werden durchgeführt, anschließend wird entweder das komplette Volume oder einzelne virtuelle Maschinen mit Hilfe des NDMP Protokolls auf Band gesichert. Ob das Ganze Volume, oder einzelne Maschinen auf Band gesichert werden hängt von der Definition des Konfigurationsparameters "SAVE_VM_WITH_NDMP" ab. Ist dieser Parameter mit einer Liste von viertuellen Maschinen versehen, so werden nur diese Maschinen gesichert. Wenn der Parameter leer (nicht gesetzt) ist wird das ganze Volume gesichert. Die Retentionzeit der Bandsicherung wird über den Parameter "NSR_NDMP_RETENTION_DAYS" definiert.
SNAP_MIRROR: Alle Schritte des Typs ONLY_SNAP werden durchgeführt, anschließend wird für das Volume des Datastores ein "snapmirror update" initiiert und nach der erfolgreichen Spiegelung wird ein weiterer Snapshot auf dem Mirror-Volume generiert. Dieser Snapshot wird für "SNAP_MIRROR_RETENTION_DAYS" aufgehoben.
SNAP_MIRROR_NDMP: Alle Schritte des Typs SNAP_MIRROR werden durchgeführt, anschließend wird eine Bandsicherung vom Mirror-Volume gestartet. Hierbei hängt die Sicherung von den selben Parametern ab wie beim Typ NDMP_BACKUP.
SNAP_VAULT: Alle Schritte des Typs ONLY_SNAP werden durchgeführt, anschließend wird für das Volume des Datastores ein "snapvault update" initiiert und nach der erfolgreichen Spiegelung wird ein weiterer Snapshot auf dem Vault-Volume generiert. Dieser Snapshot wird für "SNAP_VAULT_RETENTION_DAYS" aufgehoben.
SNAP_VAULT_NDMP: Alle Schritte des Typs SNAP_VAULT werden durchgeführt, anschließend wird eine Bandsicherung vom Vault-Volume gestartet. Hierbei hängt die Sicherung von den selben Parametern ab wie beim Typ NDMP_BACKUP.
Mit Hilfe der WWW Seite http://<server>/VMware/work_on_config/<Datastore>/ können alle Konfigurationsparameter für den jeweiligen Datastore definiert werden.
Für die Parameter die den Button "EDIT" besitzen kann eine Liste von virtuelle Maschinen mit Hilfe eines Auswahlfensters erstellt werden. Durch dieses vorgehen können zum einen Tippefehler vernmieden und lange Listen besser verwaltet werden.
Zurzeit können folgende Recover Verfahren angewendet werden:
- Recovern einer kompletten VM auf Basis eines Snapshots des primary Storage
- Recovern einer kompletten VM auf Basis eines Snapshots des secondary Storage
- Recovern einer kompletten VM auf Basis einer NDMP Sicherung. Hierbei spielt es keine Rolle, ob die VM als eigene Sicherung, oder mit dem kompletten Datastore gesichert wurde.
- Recovern einzelner Dateien aus einer mit Snapshot gesicherten VM, egal ob der Snapshot nur noch auf dem secondary, oder auf dem primary Storage existiert.
Für den Start eines Recover Vorgangs kann entweder zunächst auf das WWW Frontend auf der "WWW-Server" zugegriffen werden. Um von hier aus eine Auswahl des zu Recovernden Sicherungsstabndes bequem per Maus zu tätigen, oder der Administrator kann direkt das unten beschriebene Kommando aufrufen und die zu Recovernde Maschine und den zu Recovernden Zeitpunkt interaktiv wählen.
Das VMware Recover Kommando ist ein voll interaktives Kommando, das aber auch mittels Optionen vollständig ohne Interaktion gestartet werden kann!
/opt/nsr/VMwareBackup/bin/recover_VM.py
USAGE: /opt/nsr/VMwareBackup/bin/recover_VM.py [-v] [-q] -d <DATA_STORE> -t <type> -m <machine> -s <snapshot> [-H <ESX Host> ([-y] | -a (Create | Keep | Always Create | Always Keep))]
-d <DATA_STORE> Datastore from the VM
-t <type> Type of Recovery (SNAPSHOT, SNAP_VAULT,
SNAP_MIRROR, MOUNT_FS, TAPE)
-m <machine> Name of the VM
-s <snapshot> Snapshot name of the Backup
-H <ESX Host> Recover the VM to a different ESX Host
-a <answer> If the machine ist moved VMware wants to know
if the UUID should be changed. Here you have the
possibilty to give a default answer for this
question
-y Set the Question to the default answer
at the moment "Keep"
-v verbose
-q quiet
Generierung des Kommandos mittels WWW GUI auf dem WWW-Server :Durch betätigen des Recover Links auf der VM/<vm-machine> Seite wird die Information für einen Recover dieses Snapshots zusammengetragen und auf dem NSRAPP Share abgelegt. Anschliessend erhält der Benutzer einen definerten Kommandoaufruf mit dem der eigentliche Recover Vorgang von der Sicherungsmaschine gestartet werden kann.
Beispiel:
# /opt/nsr/VMwareBackup/bin/recover_VM.py -m cttest -d dc2_in_nfs_ds2 -t SNAPSHOT -s dc2_in_nfs_ds2_VMware_SNAP_VAULT.090129_2300
Shutting down Virtual Machine "cttest"
Unregister Virtual Machine "cttest"
Snap Restore Files for Virtual Machine "cttest"
Register Virtual Machine "cttest"
Revert to VM-Snapshot for Virtual Machine "cttest"
Remove VM-Snapshot for Virtual Machine "cttest"
Power On Virtual Machine "cttest"I look for a VMware question for the Power Status
default answer <-1>NO QUESTION
Generierung des Kommandos mittels WWW GUI auf dem WWW-Server :Beispiel:
# /opt/nsr/VMwareBackup/bin/recover_VM.py -m cttest -d dc2_in_nfs_ds2 -t SNAP_VAULT -s dc2_in_nfs_ds2_VMware_SNAP_VAULT.090124_1830
Shutting down Virtual Machine "cttest"
Unregister Virtual Machine "cttest"
Move the actual VM to /vol/dc2_in_nfs_ds2/data/cttest_1.pre_recover
Starting NDMP_COPY from "nstore2" to "nafiler1":
estimated 10.165906 GBcopied 6.872334 GB
Register Virtual Machine "cttest"
Revert to VM-Snapshot for Virtual Machine "cttest"
Remove VM-Snapshot for Virtual Machine "cttest"
Power On Virtual Machine "cttest"I look for a VMware question for the Power Status
default answer <-1>NO QUESTION
If the Recover Job was successfull you should remove the old VM directory /vol/dc2_in_nfs_ds2/data/cttest_1.pre_recover
- Stoppen der wiederherzustellenden virtuellen Maschine (PowerOff)
- Derigistrieren der VM
- Zurücksetzen aller Dateien der virtuellen Maschine auf den Zeitpunkt des ausgewählten Snapshots.
Hierzu wird entweder die NetApp-Funktion "SnapRestore File" für jede Datei der virtuellen Maschin aufgerufen, oder es wird ein NDMPCOPY der virtuellen Maschine vom "secondary Storage" auf den "primary Storage" durchgeführt. Wenn die Maschine mittels NDMPCOPY wiederhergestellt wird, wird zunächst der aktuelle Stand der Maschine mit der Endung ":pre_recover" gerettet. Der Administrator muss dieses Verzeichnis nach einer erfolgreichen Recover Aktion per Hand Löschen!- Registrieren der VM
- Zurücksetzen der VM auf den VMware Snapshot
- Löschen aller VMware Snapshots
- Starten der virtuellen Maschine
Das recover_VM Kommando ermöglicht es die Partitionen einer virtuellen Maschine zu Mounten und anschließend beliebige Dateien aus den gemounteten Verzeichnissen herauszukopieren. Dieses Verfahren funktioniert sowohl mit Windows als auch mit LINUX Maschinen. In beiden Fällen werden die VMware VMDK Dateien der jeweiliegn virtuellen Maschine, mittels eines "loopback" Devices gemountet.
Allerdings gibt es zwischen Windows und LINUX einen gravierenden Unterschied bei der Möglichkeit des Mounts.
Für den Mount eines NTFS Filesystems genügt es das VMDK File direkt aus dem Snapshot Verzeichnis des VMware Datastores zu mounten, da hier ein "Readonly" mount möglich ist.
Für LINUX muss das zu mountende VMDK File "RW" gemountet werden. Daher wird entweder ein FlexClone Volume für den ausgewählten Snapshot des VMware Datastores generiert. Dieser wird anschließend an der Recover Maschine gemountet, oder es wird die virtuelle Maschine mittels NDMPCOPY in ein dafür vorgesehenes Recover-Volume (/vol/VMware_recover) kopiert und dieses Volume wird gemountet. Anschließend werden auch hier die Partitionen der virtuellen Maschien mit Hilfe des Loopback-Devices gemountet.
In allen Varianten erhält der Anwender nach dem erfolgreichen Mount der VMDK-Files die Information, unter welchem Verzeichnis die Partitionen der virtuellen Maschine gemountet wurden. Anschließend pausiert das Recover Programm und wartet darauf, das der Anwender nach einem erfolgreichen Wiederherstellen der Dateien das Programm durch die Eingabe der Zeichenkette "READY" beendet.
Beispiel für ein Windows VM Recover:
./recover_VM.py
0) InstJochen 86) nitball 1) VIMA_124830 87) nmailman 2) WNX-V01 88) nnitball 3) adamtest 89) nnsr1 4) admsrv01 90) nverleih 5) admvts01 91) oesdocs 6) admvts02 92) ontario 7) anthurie 93) patinform 8) anthurie_old 94) pcei0012 9) anton 95) pcei0013 ...... type in one of the above numbers: 34 0) 01/20/09 09:09:16 SNAP_VAULT dc2_in_nfs_ds2
1) 01/20/09 21:22:32 SNAP_VAULT dc2_in_nfs_ds2
2) 01/21/09 08:36:53 SNAP_VAULT dc2_in_nfs_ds2
3) 01/21/09 20:22:43 SNAP_VAULT dc2_in_nfs_ds2
4) 01/22/09 08:47:44 SNAP_VAULT dc2_in_nfs_ds2
5) 01/22/09 20:59:50 SNAP_VAULT dc2_in_nfs_ds2
6) 01/23/09 08:32:56 SNAP_VAULT dc2_in_nfs_ds2
7) 01/23/09 21:08:01 SNAP_VAULT dc2_in_nfs_ds2
8) 01/24/09 08:40:21 SNAP_VAULT dc2_in_nfs_ds2
9) 01/24/09 20:13:58 SNAP_VAULT dc2_in_nfs_ds2
10) 01/25/09 06:39:38 SNAPSHOT dc2_in_nfs_ds2
11) 01/25/09 18:40:25 SNAPSHOT dc2_in_nfs_ds2
12) 01/26/09 06:40:32 SNAPSHOT dc2_in_nfs_ds2
13) 01/26/09 18:41:21 SNAPSHOT dc2_in_nfs_ds2
14) 01/27/09 06:40:06 SNAPSHOT dc2_in_nfs_ds2
15) 01/27/09 18:41:59 SNAPSHOT dc2_in_nfs_ds2
16) 01/28/09 06:40:19 SNAPSHOT dc2_in_nfs_ds2
17) 01/28/09 18:43:00 SNAPSHOT dc2_in_nfs_ds2
18) 01/29/09 06:40:02 SNAPSHOT dc2_in_nfs_ds2
19) 01/29/09 23:16:14 SNAPSHOT dc2_in_nfs_ds2
type in one of the above numbers: 18
Which "type" of a VM recover do you want to start?1) Revert the entire machine
SnapRestore, or Ndmpcopy or Tape-Recover2) Recover single Files
Mount VMDK Files; You can browse the mounted Filesystem and
read and copy the needed file(s)type in one of the above numbers: 2
Mount Partition "D:" at "/vm_mnt/cttest/D:"
Mount Partition "C:" at "/vm_mnt/cttest/C:"You can now step into the mounted Partitions and copy out the needed
files.If you are ready please ENTER "READY":
In diesem Beispiel wurde ein Recover einzelner Dateien für die virtuelle Maschine "cttest" initiiert.
Beispiel für ein LINUX VM Recover:
# ./recover_VM.py -m fromage
0) 01/20/09 09:09:16 SNAP_VAULT dc2_in_nfs_ds2
1) 01/20/09 21:22:32 SNAP_VAULT dc2_in_nfs_ds2
2) 01/21/09 08:36:53 SNAP_VAULT dc2_in_nfs_ds2
3) 01/21/09 20:22:43 SNAP_VAULT dc2_in_nfs_ds2
4) 01/22/09 08:47:44 SNAP_VAULT dc2_in_nfs_ds2
5) 01/22/09 20:59:50 SNAP_VAULT dc2_in_nfs_ds2
6) 01/23/09 08:32:56 SNAP_VAULT dc2_in_nfs_ds2
7) 01/23/09 21:08:01 SNAP_VAULT dc2_in_nfs_ds2
8) 01/24/09 08:40:21 SNAP_VAULT dc2_in_nfs_ds2
9) 01/24/09 20:13:58 SNAP_VAULT dc2_in_nfs_ds2
10) 01/25/09 06:39:38 SNAPSHOT dc2_in_nfs_ds2
11) 01/25/09 18:40:25 SNAPSHOT dc2_in_nfs_ds2
12) 01/26/09 06:40:32 SNAPSHOT dc2_in_nfs_ds2
13) 01/26/09 18:41:21 SNAPSHOT dc2_in_nfs_ds2
14) 01/27/09 06:40:06 SNAPSHOT dc2_in_nfs_ds2
15) 01/27/09 18:41:59 SNAPSHOT dc2_in_nfs_ds2
16) 01/28/09 06:40:19 SNAPSHOT dc2_in_nfs_ds2
17) 01/28/09 18:43:00 SNAPSHOT dc2_in_nfs_ds2
18) 01/29/09 06:40:02 SNAPSHOT dc2_in_nfs_ds2
19) 01/29/09 23:16:14 SNAPSHOT dc2_in_nfs_ds2
type in one of the above numbers: 10Which "type" of a VM recover do you want to start?
1) Revert the entire machine
SnapRestore, or Ndmpcopy or Tape-Recover2) Recover single Files
Mount VMDK Files; You can browse the mounted Filesystem and
read and copy the needed file(s)type in one of the above numbers: 2
Generate FlexClone Volume
Mount Partition "/" at "/vm_mnt/fromage/"You can now step into the mounted Partitions and copy out the needed
files.If you are ready please ENTER "READY": READY
Remove the FlexClone Vol from Filer
In diesem Beispiel wurde eine FlexClone Volume für einen "primary Snapshot" erstellt und das Fielsystem auf Basis des Snapshots an der Recover Maschine gemountet.
# df -h
nafiler1:/vol/vm_fromage_recover/data 2.0T 1.5T 488G 76% /recover_vm/fromage
/recover_vm/fromage/fromage/fromage-flat.vmdk 15G 1.1G 14G 8% /vm_mnt/fromage
Beispiel für ein LINUX VM Recover auf Basis eines SnapVault Snapshots:
# ./recover_VM.py -m fromage
0) 01/20/09 09:09:16 SNAP_VAULT dc2_in_nfs_ds2
1) 01/20/09 21:22:32 SNAP_VAULT dc2_in_nfs_ds2
2) 01/21/09 08:36:53 SNAP_VAULT dc2_in_nfs_ds2
3) 01/21/09 20:22:43 SNAP_VAULT dc2_in_nfs_ds2
4) 01/22/09 08:47:44 SNAP_VAULT dc2_in_nfs_ds2
5) 01/22/09 20:59:50 SNAP_VAULT dc2_in_nfs_ds2
6) 01/23/09 08:32:56 SNAP_VAULT dc2_in_nfs_ds2
7) 01/23/09 21:08:01 SNAP_VAULT dc2_in_nfs_ds2
8) 01/24/09 08:40:21 SNAP_VAULT dc2_in_nfs_ds2
9) 01/24/09 20:13:58 SNAP_VAULT dc2_in_nfs_ds2
10) 01/25/09 06:39:38 SNAPSHOT dc2_in_nfs_ds2
11) 01/25/09 18:40:25 SNAPSHOT dc2_in_nfs_ds2
12) 01/26/09 06:40:32 SNAPSHOT dc2_in_nfs_ds2
13) 01/26/09 18:41:21 SNAPSHOT dc2_in_nfs_ds2
14) 01/27/09 06:40:06 SNAPSHOT dc2_in_nfs_ds2
15) 01/27/09 18:41:59 SNAPSHOT dc2_in_nfs_ds2
16) 01/28/09 06:40:19 SNAPSHOT dc2_in_nfs_ds2
17) 01/28/09 18:43:00 SNAPSHOT dc2_in_nfs_ds2
18) 01/29/09 06:40:02 SNAPSHOT dc2_in_nfs_ds2
19) 01/29/09 23:16:14 SNAPSHOT dc2_in_nfs_ds2
type in one of the above numbers: 5Which "type" of a VM recover do you want to start?
1) Revert the entire machine
SnapRestore, or Ndmpcopy or Tape-Recover2) Recover single Files
Mount VMDK Files; You can browse the mounted Filesystem and
read and copy the needed file(s)type in one of the above numbers: 2
Please be patient.
I copy the virtual machine from snapshot to a recover volumeestimated 15.576633 GB
copied 5.359570 GB
copied 10.582413 GB
copied 14.457199 GB
Mount Partition "/" at "/vm_mnt/fromage/"You can now step into the mounted Partitions and copy out the needed
files.If you are ready please ENTER "READY":
Hier wurde der Stand der virtuellen Maschine auf dem "secondary Storage" kopiert. Die kopierten Filesysteme werden dem Administartor an der Recover-Maschine zur Verfügung gestellt.
# df -h
nstore2:/vol/VMware_recover 20G 16G 5.0G 76% /recover_vm/fromage
/recover_vm/fromage/fromage/fromage-flat.vmdk 15G 1.1G 14G 8% /vm_mnt/fromage
Für eine leichte Kontrolle und einen Überblick der Sicherungen
zu erhalten, wurde ein eigener WWW-Server aufgesetzt, der die Überwachung
der VMwaresicherungen auf mehreren WWW-Seiten ermöglicht.
Der WWW-Server hat das Konfigurationsvolume der nstore1 gemountet.
Unter folgenden URLs findet man die Protokollierung, sowie Konfigurationsmöglichkeiten für die einzelnen Datastores.
http://<WWW-Server>/VMware/
Auf diesen WWW-Seiten erhält man als erstes einen Überblick über die zuletzt gelaufenen Sicherungen aller definierten Datastores. Hierbei werden für die 4 Sicherungsarten "Snapshot", "Snapmirror", "SnapVault" und "NDMP" jeweils die letzten Sicherungszeiten ausgegeben. Wenn die Sicherung erfolgreich war wird die Sicherungszeit grün hinterlegt bei einer fehlerhaften Sicherung ist die Darstellung rot hinterlegt. Der WWW-Link hinter dem Namen des Datstores führt zu einer weiteren WWW-Seite auf der alle noch verfügbaren Sicherungen des jeweiligen Datastores aufgelistet wird. Hier werden zusätzlich zum Sicherungsstart die Endzeiten der jeweiligen Sicherungsstufen angezeigt. Jede Zeitangabe verweist hierbei auf das zugehörige Protokoll.
Hinter den Datastores werden die bei der letzten Sicherung auf diesem Datastore gesicherten virtuellen Maschinen aufgelistet. Jede virtuelle Maschine ist mit einer weiteren WWW-Seite verlinkt, auf der alle noch zur Verfügung stehenden Sicherungen dieser VM sichtbar sind. Auf dieser Seite kann ein Recover der jeweiligen VM vorbereitet werden (zurzeit nur mit NetApp Snapshots des primären Filers implemetiert).
Für den Fall das ein Recover unvorhergesehen abgebrochen wird, wurde ein Kommando entwickelt, dass es ermöglicht übrig geliebene MountPoints, FlexClone Volumes etc. zu entfernen.
Das Kommando /opt/nsr/VMwareBackup/bin/chk_recover_zombies analysiert die Recover Umgebung und entfernt Ressourcen von abgebrochenen Recover-Kommandos .
# ./chk_recover_zombies -?
USAGE: ./chk_recover_zombies [-v] [-t] [-y] [-m <machine>] [-d <DATA_STORE>]
-d <DATA_STORE> Datastore from the VM
-m <machine> Name of the VM
-v verbose
-t TEST
-y Don't ask