Xact.gmbh

Was ist Sache?
Eigentlich war es ja schon länger bekannt, aber seitdem im Forum ⧉ Anton Gostev die mit der v13 einhergehenden Änderungen verkündet hat, gehen bei einem obsolet werdenden Feature die Wogen doch besonders hoch.

Reverse Incremental (RevI) Backup Mode ⧉ bei VMs
Ursprünglich tatsächlich der default Modus für Virtual Machines (VM) Backups hat sich dies mit der v8 auf Forward (FwdI)/Forever Forward Incremental (FFwdI) geändert - und das aus guten Gründen:

• der oft unterstellte, raschere Restore ist nur ganz selten und selbst da kaum spürbar gegeben
  Bevor Veeam zum Restore schreiten kann, wird intern eine Bitmap erzeugt, also quasi der "Bauplan" wie die VM zum ausgewählten Backupzeitpunkt ausgesehen hat - sprich: welche welche Diskblöcken aus welchen Backup-Datenblöcken für die Wiederherstellung benötigt werden würden.
  Diese Bitmap, die unter Nutzung der Backup-Metadaten (.VBM Dateien) erzeugt wird, enthät die Verweise auf die Backup-Datenblöcke in dem oder den unterschiedlichen Backupdateien (.VBK, .VBR, .VIB).
  
  Ein raschere Erzeugung der Bitmap ist daher nur bei der Wiederherstellung aus einem Full Backup gegeben, was bei der Reverse Incremental Backup Method das letzte, aktuellste Backup File, eben das einzige Full Backup File dieser Backup Kette wäre.
  Da es aber zum einen nicht immer um die Wiederherstellung aus dem letzten Backup geht und zum anderen seit der Umstellung des default Backupketten-Formats von einer Metadaten-Datei (.VBM) je Job auf jeweils eine eigene pro VM (siehe dazu hier ⧉ ) die Verarbeitung der Metadaten nun schneller erfolgt, ist der vermeintliche Geschwindigkeitsvorteil in der Praxis kaum relevant und zudem ab Fertigstellung der Bitmap schlicht nicht existent.
  Daher handelt es sich hier eher eine Placebo-Wirkung.
  
  
• langsamere Backup Copy Jobs
  Hier sind vor der eigentlichen Synchronisierung der Backup-Blockdaten von der Source-Backup-Chain (aka primäres Backup) in die Target- (aka sekundäres Backup = Backup Copy) Backup Copy Kette zunächst die betreffenden, zu synchronisierenden Daten zu evaluieren, was bei Reverse Incremental Backup Method bedeutet, dass hier jedesmal auf das Full Backup File zugegriffen werden muss.
  Der Zugriff ist in diesem Fall nun eben deutlich langsamer, als wenn hier vergleichsweise auf die Incremental Daten von Forward Incremental with periodic Full Backups ⧉ zugegriffen werden müsste. Aber selbst bei Verwendung von Forward Incremental with periodic Full Backups ⧉ mit regelmässig zu verarbeitenden Full Backups es im Gegensatz zu Reverse Incremental eben nicht zur ständigen Verarbeitung eines Full Backup Files.
  
  
• für ein tägliches Full Backup to Tape braucht es KEIN Reversed Incremental Backup to Disk
  Zugegebenermassen ist die von Veeam gewählte Bezeichnung Backup to Tape durchaus missverständlich, solange man sich nicht mit der tatsächlichen Funktionsweise auseinander gesetzt hat. Denn von einige Ausnahmen abgesehen (zB. direkter VM Restore in die Hypervisor-Umgebung ⧉ bei Backup to Tape Jobs oder Unstructured Data Backup to Tape ⧉ ) gilt das "Stageing (to Disk first)" Prinzip:
  es werden nur die zuvor auf Disk gesicherten Daten weiter auf Band kopiert.
  Siehe zu diesem Thema auch den entsprechenden Blog-Artikel

Auf den Punkt gebracht.
Wie Anton Gostev hier ⧉ einmal ausgeführt hat, war Reverse(d) Incremental Backup to Disk der zu Beginn der Produktentwicklung noch exklusiven Ausrichtung von VBR auf SMB Kunden geschuldet - unter anderem auch deshalb, als es in der Frühzeit von VBR noch nicht die Mechanismen von heute gab, um ausserhalb der regulären Backup Kette Full Backups für den Export bereit zu stellen.

Wie also sonst ein Full Backup bei FwdI/FFwdI erzeugen?
Variante 1 ist ein Klassiker - das adhoc Backup mit VeeamZIP ⧉ ein Full Backup auf dem jetzt aktuellen Stand erzeugen. Dieser Job ist zwar per se nicht mit Scheduler planbar, kann aber zumindest per PowerShell ⧉ in Verbindung mit einem Trigger zB. via Post Job Script ⧉ oder externem Scheduler automatisiert werden.
Als Ziel kann dabei wahlweise ein Repository oder aber ein lokaler bzw. shared Folder angegeben werden.
Weiters ist wählbar, ob eine Retention ("Ausaltern" des VeeamZIP .VBK Files), Verschlüsselung (AES 256) und falls ja wenn welcher Compression Level gewünscht wird.

Zu beachten ist dabei, dass KEIN Application Aware Backup ⧉ erzeugt wird!
Zumindest besteht (default, optional deaktivierbar) aber die Möglichkeit, für File System Konsistenz mit der Guest Quiescence Funktion zu sorgen. Dafür müssen in der betroffenen VM/s die VMware Tools bzw. Hyper-V Integration Services installiert sein.

Die vielen Anwendern überraschenderweise unbekannte Variante 2 ist die Exporting Backups Funktion ⧉.
Hiermit kann, im Gegensatz zu VeeamZIP, ein historisches Full Backup File auf der Basis des ausgewälten Restorepunkts bereitgestellt werden. Sollte es sich bei diesem ausgewählten Restorepunkt um ein inkrementelles Backup (bei FwdI/FFwdI: .VIB, bei RevI: .VRB) handeln, erzeugt VBR hier ein synthetisches Full Backup. Im Gegensatz zum normalen FwdI Backup Job bedarf es dabei KEINEN Zugriff auf den Hypervisor Production Datastore!

So wie bei der ersten Variante mit VeeamZIP ist auch bei Exporting Backups kein Scheduler vorhanden. Es kann zur Automatisierung hier aber ebenso wieder auf Powershell ⧉ zurückgegriffen werden.

Bäumchen wechsle Dich?
Könnte allenfalls der Wechsel der Backup Method ein Problem darstellen? Keineswegs, diese Situation ist ja aus unterschiedlichen Gründen notwendig und naheliegend - daher ist der Wechsel von einem Backup Mode zu einem anderen auch unterstützt. Details dazu gibt es hier ⧉.

Zumindest für (VM) Backup to Disk samt Restore sollte der Wegfall von RevI also kein echtes Problem darstellen.
Für tägliche Full Backups to Tape siehe diesen Blog-Artikel

Wie kann man nur! Ach, das gabs schon mal?!
Veeam Anwender von früher können sich vllt. noch erinnern - eine ähnliche Zäsur gab es schon einmal - als mit VBR v11 der "Transform previous backup chains into rollbacks" Modus zunächst für neu angelegte Jobs und dann mit der v12 komplett weggefallen ist (siehe VBR v10 User Guide Archiv). Dieser Modus war faktisch ein Hybrid aus RevI und FwdI: so war es möglich, zunächst eine Forward Incremental Kette zu erzeugen, die dann zu bestimmten Zeitpunkten auf eine RevI Kette umgebaut wurde. Anschliessend wurde bis zum nächsten Ende des FwdI Zyklus weiter mit eben dieser Methode gearbeitet.

Die "bestechende" Idee dahinter: die meiste Zeit weniger I/O Last auf dem Backup Repository zu erzeugen. Diese löbliche Ansatz wurde nur leider dadurch völlig konterkariert, als hier dann das ehemalige, zu Beginn der FwdI Kette befindliche Full Backup solange weiter nach vorne als als temporäres Full Backup konvertiert wurde, bis es eben zuletzt als aktuellstes Full Backup zu Beginn der Kette angelangt war. Die ehemals .VIB Backupstände wurden im Zuge dieses en block durchlaufenden Prozesses dann zu .VRB Incrementals konvertiert.

Im Ergebnis enorme I/O Lasten, daher ein wenig beliebtes und eher problematisches Feature, das deswegen und wegen der geringeren Verbreitung schliesslich auch fallen gelassen wurde.

Verfasst am 20250129 von C. Pfleger