Migrationsstrategie

[JanF1]

Moin,
still habe ich schon einiges mit- und nachgelesen, troztdem habe ich hier ein Bündel an Überlegungen und Fragen zur Datensicherung vSphere-Cluster, die andere sich bei der Migration gewiß auch schon gestellt haben.

Klassisches Backup
Klassisch wurden über Nacht durch Agenten auf den einzelnen Servern Datei-Verzeichnisse oder auch ganze Server-Images gesichert. Datenbanken wurden je nach Typ zur Sicherung heruntergefahren oder erzeugten mit eigenen Mitteln zeitgesteuert Backups. Für jeden neuen Server mußte ein Backup-Konzept erstellt, ein Agent installiert und die zeitgesteuerte Sicherung konfiguriert werden.
Damit war die Welt überschaubar. Im Desasterfall konnte ein Image auf den Server zurückgespielt werden, notfalls mußte ein neuer Server her. Das ging natürlich nicht von jetzt auf gleich sondern dauerte Stunden, schlimmstenfalls Tage (falls theoretisch neue Hardware beschafft werden müßte).
Dateien und Datenbank-Backups wurden auf Tape gespeichert und eingelagert. Bei Bedarf ließen sich einzelne Objekte wiederherstellen.

Die neue, virtualisierte Welt - viele neue Möglichkeiten, viele Fragen:
Es heißt, daß die Agenten-basierten Sicherungen über das LAN doch viel zu lange dauern und bei jedem neuen Server der Agent verteilt werden müsse, dagegen mit den Mitteln z.B. des vStorage-API komplette Backups der VMs über das SAN quasi in Sekunden zu erzeugen seien.
Aber wie lösen die Produkte (veeam5 b&r, acronis vmProtect6, ...) das Problem, daß im Moment des Snapshots Zugriffe auf Dateien und Datenbanken noch nicht abgeschlossen sein könnten? Was weiß die Backup-Software schon vom Zustand des Gastsystems und was das Gastsystem von $irgendwelchen Datenbanken, Applicationen usw. auf ihm? Macht man auch hier Backups deshalb nur im nächtlichen Zeitfenster (sofern das überhaupt noch möglich ist)?
Der Einwand, daß bei der klassischen Lösung bei jedem neuen Server auch der Agent verteilt werden muß, ist natürlich richtig, aber wenn man nicht ständig neue Server aufsetzt, hält sich der Aufwand andererseits doch in Grenzen.
Ein weiterer Einwand ist, daß VMs nicht unbedingt 24h/7d betrieben werden und dann ggf. ausgerechnet immer im vorgesehenen Backup-Zeitfenster down sind. Das ist natürlich richtig.

Datendeduplizierung erscheint mir auch ein recht weites und kompliziertes Feld zu sein:
Während beim klassisch inkrementellen Backup zur Reduzierung der Datenmenge gegenüber dem Vollbackup nur die seit dem letzten [inkrementellen] Backup veränderten oder neuen Dateien gesichert werden (und ein Plan, welche Dateien aus vorhergehenden Backups ggf. auch noch benötigt werden), setzen die Dedup-Verfahren tiefer einfach auf Basis von Datenblöcken an. Dazu wird nach identischen Datenblöcken in Dateien gesucht. Jeder mehrfach enthaltene Datenblock muß nur einmal gespeichert werden, wenn an den übrigen Stellen seines Vorkommens nun einfach ein Verweis auf den einmal abgespeicherten Block gesetzt wird. Bei der Art der Mustererkennung, der Zerlegung und Blöcke, der Überprüfung der Gleichheit von Blöcken wird jeder Hersteller seine eigenen Techniken verwenden.
Ich nehme an, daß diese Erkennung sehr rechenaufwändig ist und entweder auf den VMs oder - falls vorhanden - auf dem physikalischen Backup-Server zu hoher CPU-Last führt. Damit wäre der Kostenvorteil von weniger Speicherbedarf und weniger Traffic auf dem Netzwerk (insb. LAN) nicht mehr so deutlich.
Wenn die Informationen über gleiche Blöcke von der Backup-Software in einer Datenbank und nicht im Backup selbst gehalten werden, dann - denke ich - ist diese Datenbank für die Wiederherstellung eines deduplizierten Backups doch essentiell wichtig und müßte daher unbedingt auch (ohne Dedup und unabhängig Desaster-tauglich gesichert werden).
Eine solche Datenbank würde im Laufe der Zeit vermutlich auch immer größer und als Information über den einzelnen, deduplizierten Datenblock kann der Datenblock selbst (eindeutig, aber großer Speicherbedarf) oder ein Hash wie MD5 oder SHA1 über den Datenblock (auch mit Zusatzinformationen wie Blockgröße, Dateiname nicht eindeutig) gespeichert sein. Falls es im zweiten Fall zu einer Hash-Kollision kommt, könnte mein ganzes Backup unbrauchbar werden.
Wie ist Dedup unter diesen Aspekten zu bewerten? Nutzt man Dedup, wenn es nicht anders geht, also wenn die Datenmenge zu groß ist?
Läßt man umgekehrt besser die Finger von Dedup,
- wenn dieses auf dem Cluster stattfinden würde und der Cluster schon ganz gut ausgelastet ist oder
- wenn Dedup sowieso erst auf dem phys. Backup-Server stattfände, Speicherplatz für das Backup aber kein Problem wäre?

Gibt es Erfahrungswerte zur Effizient von Debup? Bringt Dedup etwas bei Datenbanken (z.B. Fibu auf Oracle, Exchange, Web-Content in mysql) oder dem Datenbereich eines Fileservers oder kommt es vor allem zum Tragen, wenn ich viele, sehr ähnliche Server (meint gleiches OS, gleiche Aktualisierungsstände) habe?

Ist der Ansatz sinnvoll: Vollständige Backups der VMs mit Spezialisten wie Veeam oder Acronis oder einer Erweiterung zum vorhandenen Backup zu machen, um im Desaster-Fall die Systeme zeitnah wieder zum Laufen zu bekommen und parallel klassisch agentenbasierte Backups von Fileservern und Datenbanken zur längerfristigen Archivierung?

Jan

[echt_weg]

Vom Grunde hast du was die Nachteile einer VM-basierten Sicherung angeht recht allerdings können die VMWare Tools vor dem Erstellen eines Snapshots einen VSS-Snapshot innerhalb der VM antriggern bzw beliebige Scripte ausführen um konsistente Daten zu sichern. Viele Backup-SW Hersteller bieten darüber hinaus auch weitehrin Agents an und die Sicherung läuft dann zwar Imagebasierten aber mit Katalogen die vom Agent generitert werden.

Beispiel Backup Exec 2012 bei der Sicheurng eines virtuellen Exchange-Servers:

Aufbau:
-Auf der VM läuft ein BE Agent
-Der Backupserver hat Zugriff auf die ESX-LUNs (die Sicherung ist daher 99% lanfree)

Der Backupserver erstellt bei der Sicherung einen Snapshot, triggert einen VSS-Snapshot an und spricht per LAN mit seinem installiertem Agent in der VM, danach wird imagebasiert per SAN die gesamte VM direkt auf Tape gesichert, danach ein Katalog über die Dateien der Volumes erstellt (für Single-File-Restore) und im Anschluss wird vom Agent ein Katalog der Exchange-Postfächer zum Zeitpunkt des VSS-Snapshots an den Backupserver übertragen der diese Informationen mit aufs Tape schreibt.

Ergebnis:
Ich habe eine Sicherung des Servers per SAN-Geschwindigkeit aus der ich entweder die ganze VM, oder einzelne Dateien oder auch einzelen Postfächer restoren kann (wobei der Backupserver beim Restore die gesamte Schiene durchlaufen muss...also Restore der VMDK, extrahieren der Datenbankfiles aus der VMDK, extrahieren der Mail aus der Datenbank)

Was Dedup angeht:
Ja es ist CPUlastig jedoch kostet CPU-Leistung meist weniger als HDD oder Tapespeicher