Final error: 0xe000848c - Unable to attach to a resource. Make sure that all selected resources exist and are online, and then try again.
Final error category: Resource Errors

Eine Suche bei Symantec ergab zuerst viele Hinweise auf diesen Fehler. Man müsse sicherstellen, dass der BackupExec Service Account für den Restore eine Mailbox hat, die auch aktiviert und benutzbar ist. Das war der Fehler. Weitere Hinweise gingen Richtung Permissions, der Service Account hatte aber die richtigen Berechtigungen. Das Backup ging auch ohne Probleme.

Irgendwann bin ich dann auf diesen Artikel gestossen:

http://www.symantec.com/business/support/index?page=content&id=TECH61406

Ein Problem mit IPv6. Der DSProxy Service (Port 6004) auf dem Exchange Server horcht nur auf IPv4 und NICHT auf IPv6. Der Exchange Server läuft aber auf einem Windows Server 2008. Dieser versucht per default zuerst eine Verbindung per IPv6 und dann erst per IPv4. Der Server selber hat keine IPv6 Adresse, auch keine LinkLocal. Aber in der hosts Datei (%WINDOWS%\system32\drivers\etc\hosts) ist ein Eintrag fuer die IPv6 Loopback Adresse ::1

Als Workaround kann dieser Eintrag auskommentiert werden. Dann den BackupExec Agent neustarten und es geht.

Übel, aber momentan wird noch kein IPv6 in der Umgebung verwendet. Mal sehen ob dies mit einem der nächsten Patches behoben wird.

Nach der Installation muss nur noch ein Konfigurationfile erstellt werden. Ein einfaches Konfigurationsfile sieht folgendermassen aus:

backup
vcip=VCHost
vcuser=vibe
vcpasswd=secret
sauser=vibe
sapasswd=supersecret
dsset=vmware_volume:172.30.129.100
verbose

Hier mache ich ein Backup, vcip ist die IP oder Hostname des Virtual Centers. Danach folgen der Virtual Center User und sein Passwort. sauser ist der Username der für den Login auf dem Netapp Filer verwendet werden. sapasswort sein Passwort. Mittels dsset sage ich VIBE, dass es von allen VMs, die mind. eine Disk auf dem vmware_volume (NetApp Volume) haben einen VMWare Snapshot macht, danach einen NetApp Snapshot des Volumes. Am Schluss werden die VMWare Snapshots wieder entfernt. Wenn wir dies in ein Textfile vibe-backup.cfg speichern können wir mit

vibe --config vibe-backup.cfg

den Backup Prozess starten. Falls das Volume noch gemirrored wird, können wir dies mit:

vibe --config vibe-backup.cfg --updatemir --miruser remoteuser --mirpasswd supersecret

machen. Dann wird nach dem Snapshot der Snapmirror vorgang auch noch mitgestartet.

Zuerst schalten wir NDMP mit ndmpd on ein. Danach können wir mit ndmpd status sehen, dass NDMP auch wirklich läuft:

Nun stellen wir noch ein, dass wir mittels Username und Passwort auf NDMP zugreifen wollen:

Wir müssen sicherstellen, dass NDMP Version 4 verwendet wird:

Falls dies noch nicht der Fall ist können wir dies explizit setzen:

Nun können wir den Filer als NDMP Host hinzufügen. Dazu gehen wir in der BackupExec Konsole auf Tools -> Device and Media Operations -> Add NDMP Server

Im neu erscheinenden Fenster geben wir den Hostname oder IP des NetApp Filers an und den Account mit dem BackupExec sich verbinden soll:

Das war’s auch schon. Nun können wir bei Backups oder Backup Selection Lists den NetApp Filer auswählen und Volumes, Qtrees oder einzelne Files sichern:

• Cold Backup
  Hier werden die VMs runtergefahren und dann ein Snapshot erstellt
• Warm Backup
  Die Snapshots werden in Koordination mit VMWare erstellt, damit die Daten konsistent sind.
• Hot backup
  Erstellen der Snapshots auf dem Storage Systeme ohne Koordination mit VMWare

“Cold backup” kommt für uns nicht in Frage. Die VMs runterzufahren und dann zu backup ist nicht praktikabel.

“Hot backup” ist relativ heikel. Es soll zwar Leute geben, die alle Stunde ein Storage Snapshot erstellen und dann argumentieren, dass die Möglichkeit besteht, das ein paar dieser Snapshots inkonsistent sind, aber bei 24 Snapshots im Tag mind. 1 “guter” Snapshot vorhanden sein müsste. Rein rechnerisch. Genau das müsste ist mir aber etwas zu wenig sicher. Falls die dritte Lösung zu komplex oder zu langsam wäre, könnte dies eventuell in Betracht gezogen werden. Sonst eher nicht. Müsste ist mir einfach zu wenig.

Beim “Warm backup” werden die VMs zuerst in einen spezielle “Backup Mode” gesetzt und dann wird der Storage Snapshot erstellt. Mit VMWare ist dieser Vorgang zumindest in der Theorie relativ simpel. Als erstes wird ein VMWare Snapshot erstellt. Dadurch wird sichergestellt, dass auf der VMDK der virtuellen Maschine keine I/O Operationen mehr durchgeführt werden. Diese werden in eine neue Datei geschrieben (wegen dem VMWare Snapshot). Danach kann ein Snapshot auf dem NetApp Storage erstellt werden. Dieser ist konsistent. Am Schluss wir der VMWare Snapshot wieder gelöscht und alle I/O Operationen werden wieder auf die originale VMDK Datei geschrieben. Von NetApp gibts auch ein Script dafür (PDF, Seite 39). Leider löscht dieses alle bestehenden VMWare Snapshots, da es vmware-cmd verwendet. Da wir VMWare Snapshots auch für Testserver benutzten, um die Entwickler zu unterstützen ist dies ein Problem. Ich habe ein kleines Script geschrieben, dass das Perl API von VMWare benutzt und dadurch nur den spezifischen Snapshot löscht. Das Script verbindet sich mit Virtual Center und erstellt nur von den VMs einen Snapshot, die auf einem spezifischen Datastore liegen. Nun ist der ganze Backup Vorgang sehr einfach:

1. VMWare Snapshot mit Script erstellen (stellt sicher, dass keine I/O Operationen auf der VMDK sind)
2. NetApp Snapshot
3. VMWare Snapshot mit Script löschen

Somit können wir konsistente Backups im laufenden Betrieb erstellen. Bei 14 virtuellen Maschinen auf einem ESX Host (Dell PowerEdge 2950 mit 16GB RAM) geht der ganze Vorgang rund 27 Sekunden. Dadurch dass wir NetApp Snapshots fürs eigentliche Backup verwenden, werden nur Deltas gespeichert. Für Desaster Recovery werden diese Snapshots mit Bordmitteln an den zweiten Standort in Zürich und nach Köln gespiegelt.

Das Script (Script für VMWare Snapshots) hat folgende Parameter:

• -datacenter Der Name des Datacenter, in dem die ESX Hosts sind. Muss angegeben werden.
• -datastore Name des Datastore, der gesichert wird. Muss angegeben werden.
• -action {create|delete} Sollen Snapshots erstellt (create) oder gelöscht (delete) werden? Muss angegeben werden..
• -verbose {0|1} Standard ist 0, bei 1 werden noch weitere Infos ausgegeben.
• -snapshotname Standard ist ITOP_NetApp_Snapshot. Dieser Name wird für den Snapshot verwendet. Alle Snapshots mit diesem Namen werden bei der Action delete gelöscht.

• Weiterhin jeden virtuellen Server mit Backup Exec Agent sichern
• Mit VMWare Consolidated Backup (VCB) die Server auf Tape sichern
• Die Server direkt auf dem Storage System mit Snapshots zu sichern

Den Backup Exec Agent weiterverwenden ist gelinde gesagt suboptimal. Der ESX Host wird stark belastet, der Backup Vorgang ist langsam, das Backup Fenster ist kaum einzuhalten.

VMWare bietet mit VCB die Möglichkeit die VM Daten zu sichern, ohne das der ESX Host belastet wird. Dazu muss auf einem weiteren Windows Server VCB installiert werden. Dieser Server muss (Shared) Zugriff auf die Daten haben, die auf dem SAN liegen. Danach wird auf dem ESX Host ein VMWare Snapshot der Virtuellen Maschine gemacht. Der VCB Host kann dann ein konsistentes Backup ziehen. Danach wird der VMWare Snapshot wieder commited. Hier wird zwar der ESX Host nicht belastet, aber die Backup dauern weiterhin lange (da auf Tape) und das commiten des VMWare Snapshots kann bei belasteten Servern einiges an Zeit in Anspruch nehmen.

Da die virtualisierten Server nun vollständig auf dem NetApp Storage liegen, bietet sich die dritte Möglichkeit an. NetApp hat ein Feature (Snapshots) bei dem ein incremental Backup eines Volumes gemacht werden kann. Dieser Vorgang dauert nur Sekunden (normalerweise 2-5sec) und hat keinerlei Performance Impact auf den ESX Host. Auch hier müssen wir entsprechende VMWare Snapshots erstellen, bevor wir mit NetApp Snapshots ein konsistentes Backup ziehen können (Ziemlich verwirrend, da beide Hersteller den Begriff Snapshot verwenden). Auch hier müssen wir den VMWare Snapshot am Schluss wieder löschen und die Änderungen commiten, aber da der Backup Vorgang nur Sekunden gedauert hat, ist der Umfang hier relativ gering.

Für uns war somit die Wahl klar. Wir implementieren die Backups mit Snapshots auf dem NetApp Storage.

In einem weiteren Artikel werde ich die Schritte und Scripts für die Snapshots erläutern.