Xact.gmbh

Was ist Sache?
Der Wegfall der Reverse(d) Incremental Backup to Disk Method (RevI) mit der v13 von Veeam Backup & Replication (VBR) ist, zumindest seit der hochoffizielle Ankündigung von Anton Gostev im R&D Forum ⧉, ein Aufreger erster Güte! Dabei mutet der Umstand, dass die Aufregung gerade jetzt (erst) hochkocht, doch etwas unverständlich an, denn dass RevI nicht mehr verfügbar sein wird, war doch schon seit längerem bekannt.
Die von den Kritikern der kommenden Obsoletheit hier gerne vorgebrachten Argumente beziehen sich meist auf den täglichen Export eines Full Backups, speziell mittels der VBR Funktion Backup to Tape.

Im Folgenden soll die tatsächliche Auswirkung und dabei noch ein paar weitere technische Hintergründe rund um die Bandsicherung mit Veeam besprochen werden.

C'est quoi le problème, chérie?
Die Bezeichnung Backup to Tape hat, so man die konkrete Umsetzung von Veeam hier nicht wirklich kennt, zugegebenermassen doch ordentlich Potential für Missverständnisse! Denn eigentlich erfolgt hier ein Backup (File) Copy to Tape, bei dem auch die Informationen* über die Inhalte der Backupdatei, also zB. die Angabe welche Virtual Machines (VMs) darin enthalten sind, im sogenannten Backup Catalog gespeichert werden.

BTW: bei File to Tape erstellt VBR im Gegensatz zu Backup to Tape Jobs lediglich den Tape Catalog, der die Angaben enthält, welche/s File/s von welcher Source wann auf welches Band geschrieben worden sind.
*Nur bei Backup to Tape Jobs wird zusätzlich auch der Backup Catalog erstellt, der den Tape Catalog ergänzende Meta-Daten (ua. welche Backup Files welcher VM darin enthalten sind) umfasst.

Nun gibt es zwar Ausnahmen von diesem "Stageing (to Disk first)" Prinzip Veeams bei der Nutzung von Bandspeicher sowohl für Backup als auch Restore (zB. direkter VM Restore in die Hypervisor-Umgebung ⧉ bei Backup to Tape Jobs oder Unstructured Data Backup to Tape ⧉). Der direkte Zugriff auf ein Bandmedium steht bei beim Backup von VMs und physischen Maschinen aber nicht zur Verfügung, weswegen es eben zunächst der Erstellung eines Backups auf Disk bedarf, bevor eben dieses auf Band kopiert werden kann.

Da bei einem am VBR erstellten Backup to Tape Job mit der Auswahl des Sources (wahlweise Backup to Disk Job oder Auswahl des gesamten Repositories) dann grundsätzlich das aktuellste, zuvor noch nicht auf Band geschriebene letzte Backup to Disk File (bzw. genauer gesagt die aktuellste Backup Kette) von VBR selektiert wird (Ausnahme: selecting Backup Chains to Archive ⧉) , war es zumindest früher absolut nachvollziehbar, dass RevI to Disk das Mittel der Wahl dargestellt hat, um darauf aufbauend nachgelagert regelmässige tägliche Full Backups to Tape durchführen zu können.

Mit Betonung auf "früher"! Denn seit erinnerlich VBR v8 gibt es nun schon das Feature Virtual (Synthetic) Full Backup to Tape ⧉!
Obzwar auf den ersten Blick nur monatliche oder wöchentliche virtual (synthetic) Full Backups vorgesehen zu sein scheinen, kann hier über die Auswahl ALLER Wochentage beim Weekly Full Backup die Erzeugung eines täglichen Full Backups auf Band ermöglicht werden (siehe den grün eingefassten Bereich im nachfolgenden Bild).

Auf den Punkt gebracht.
Für die meisten User, die sich an dem vermeintlichen Verlust des täglichen Full Backups to Tape mit Wegfall von RevI stossen, sollte die Lösung ihres (vermeintlichen) Dilemmas ganz simpel sein:
schlicht die Methode des/der betroffenen VBR Backup to Disk Jobs von RevI auf FFwdI umstellen ( hier gibts mehr Infos zum Backup Method Switching ⧉).

Der Wechsel der Backup Method ist nicht nur problemlos möglich, es entstehen dabei faktisch auch keine Einschränkungen (allenfalls abgesehen vllt. von der nicht wirklich empirisch belegbaren "Mär" angeblich schnellerer Restores bei Verwendung von RevI), die I/O Belastung des Backupstorages bleibt unverändert (hoch!) und die daily-Tape Story sollte damit ja auch vom Tisch sein.

Also alles super?
Leider nicht ganz, denn Forever Incremental (FFwdI) wurde in der bisherigen Besprechung, ausser in dem Zusammenhang, dass es bei virtual synthetic Full Backup to Tape dafür keine Möglichkeit gibt, ganz bewusst noch nicht weiter erwähnt. Veeam hätte dafür ja eigentlich GFS Backup to Tape (genauer: mit dem GFS Media Pool ⧉) mit der Möglichkeit eines täglich synthetisch erzeugten GFS to Tape vorgesehen.

Verfasst am 20250130 von C. Pfleger