Zwei Active Backup for Business Systeme sichern ein VMWare Server = Gefährlich?

[INP]

Hallo,

ich hoffe das diese Frage nicht schon mal gestellt wurde, aber ich habe mich jetzt mehr als 1 Stunde hier im Forum gesucht und nichts Passendes gefunden.

Seit einiger Zeit wird durch ABfB (lokal über LAN) ein VMWare Server mit 3 VM's als Differenzial Backup gesichert. Das funktioniert auch sehr gut. Da Server und Synology aber räumlich nicht gut getrennt sind, habe ich nun über Fiber/DSL einen Tunnel und auf einer 2. Synology ein ABfB eingerichtet. Nach dem ersten Vollbackup (26 Std.) geht auch dieses einwandfrei. Das lokale System sichert von Mo.- Fr., das Remote System immer am Sa. Nun habe ich mich in VMWare ein bisschen eingelesen, und das ABfB das Differenzbackup einer VM so schnell schafft, liegt wohl daran das VMWare eine Datei führt, in den die Bereiche der VM verzeichnet sind, die geändert wurden.

Jetzt meine Bedenken. Da alle Systeme ein Differenzbackup machen, wird die VM Datei der Differenzen (soweit ich das verstehe "CBT") nach jedem Backup zurückgesetzt. Jedoch das wäre aber eine Katastrophe, denn dann wäre beide Backup (lokal/remote) nicht vollständig! Sehe ich das richtig? Und wird die Datei auch zurückgesetzt, wenn man ein Vollbackup macht?

Gruß

Jens

 

[plang.pl]

Willkommen im Forum.
Speziell dazu kann ich leider nix sagen. Ich denke aber, dass es sinnvoller wäre, wenn du die AB4B Daten der DS via Hyper Backup auf die sekundäre DS sicherst.
https://kb.synology.com/de-de/DSM/t...siness_with_DSM_backup_packages#x_anchor_id10

 

[maxblank]

In meinen Augen brauchst du da keine Bedenken haben. Es wird quasi alles in der VM eingefroren, ein Snapshot erstellt und dieser wird gesichert. Mache ich mit Veeam in der Firma auch gleichzeitig zu verschiedenen Zielen. Wenn die VM nicht bereit ist, schlägt maximal der Versuch des Backups zu diesem Zeitpunkt fehl.

 

[INP]

Hi maxblank,

das mit dem Snapshot ist ein Teil der Backupstrategie und klar. Nur geht es darum, dass VMWare eine Datei pflegt, in dem verzeichnet ist, welche Blöcke in einem Image verändert wurden seit dem letzten Backup. Nur so kann ABfB sehr schnell ein inkrementelles Backup erstellen. Vollbackup = 26 Std., inkrementelles Backup ca. 12 min. Wird die Datei nach dem Backup zurückgesetzt, wird vom anderen Backupprozess ggf. nicht alle geänderten Blöcke gesichert.

Hast Du mal versucht so ein Backup von einer VM mal zurück zusichern? Ich überlege noch, ob ich wirklich mal, das knapp 1 TB Backup, in eine anderer Test-VNWare System zurück sichern sollte.

P.S.: Im Anfangspost habe ich Differenzial-Backup geschrieben, ich meinte aber ein Inkrementelles-Backup

 

[maxblank]

Ich habe auf diesem Wege genügend Backups wiederherstellen müssen. Zu unserer Retention-Policy gehört auch ein monatlicher Test.
Der Snapshot wird nach dem erfolgreichen Erstellen des Backups wieder mit der VM gemerged und dann gelöscht.
Ich bin mir nicht sicher, ob du den Prozess und CBT in Gänze verinnerlicht hast. Das meine ich absolut nicht böse.

Edit: Anderer Ansatz - lasse doch das Backupverzeichnis auf der einen DS durch Snapshots auf der ersten DS sichern und dann überträgst du mit Snapshot Replication diese auf das zweite NAS. So greift nur eine Backupfunktion in die laufende VM und trotzdem hast du 2 Sicherungen.

 

[nas-central.de]

Du machst mit VMWare ein Backup auf Guest Level und mit ABfB ein Backup auf Host Level. Verschiedene Anwendungen auf der gleichen Maschine, die auf Changed Block Tracking setzen ist nicht ideal, in deinem Fall sollte es aber ohne Probleme gehen.

Wichtiger zu verstehen ist, ob Deine Backup Strategie, die ja auf Snapshots basiert, crashkonsistente oder anwendungskonistente Backups schreibt. Erstere berücksichtigen ausstehende IO Operationen nicht und sind vergleichbar mit Stromstecker aus der Wand ziehen. Hast du in deinen VMs Anwendungen laufen wie z.B. prorietäre Arztsoftware, Anwaltssoftware, WaWi, Fibu oder irgendwas das pending IOs erzeugt und steht für die Anwendung kein VSS Writer zur Verfügung, dann kann dein Snapshot auf Anwendungsebene korrupt sein. Da die Korruption innerhalb der VM ist, kannst du das mit einem Restore der VM nicht feststellen. Wir empfehlen im Zweifel zusätzliche Backups auf Anwendungsebene zu erstellen.