Backup Copy Job – kann mehr als einfach nur kopieren!

Der Veeam „Backup Copy Job“ kann mehr als der Name vermuten lässt. Die primäre Aufgabe des Backup Copy Job ist es, bestehende Backup-Daten auf ein anderes Disk-System zu kopieren, um einen Medienbruch bzw. auch die Auslagerung von Datensicherungen zu realisieren (siehe 3-2-1 Regel).

Ablauf

Der Backup Copy Job läuft permanent im Hintergrund und folgt dabei folgender Logik:

Konfigurationsschritte

Der erste Schritt in der Konfiguration definiert das Zeitfenster und den Zeitpunkt, an dem der Backup Copy Job prüft, ob neue Backup-Daten vorhanden sind (siehe Abbildung 1):

Abbildung 1: Jobdefinition

Abbildung 1 zeigt ein Intervall von einem Tag; der Zeitpunkt der Prüfung auf neue Backup-Daten ist auf 01:00 Uhr gesetzt. Sollten seit dem letzten Tag um 01:00 Uhr neue Backup-Daten im Repository vorhanden sein, dann beginnt der Backup Copy Job sofort Daten zu übertragen. Fall nein wartet er. Dieses Verhalten vereinfacht das Scheduling deutlich, da es kein Problem ist, wenn der zugrunde liegende Backup Job aus irgendeinem Grund einmal länger brauchen sollte.

In den meisten Fällen ist dieses Verhalten sinnvoll, aber es gibt eine Situation, in der der Backup Copy Job auf einen bestimmten Zeitpunkt warten soll, bis ein Backup Job neue Backup-Daten geschrieben hat:

Dadurch, dass man nicht sicher vorhersagen kann, wann der 18:00 Uhr-Backupvorgang abgeschlossen sein wird, könnte man den Zeitpunkt des Backup Copy Job auf „viel später“ setzen, beispielsweise auf 19:00 Uhr. Alternativ gibt es seit Version 8 die Möglichkeit, den Backup Copy Job anzuweisen, dass er warten soll, bis neue Backup-Daten geschrieben wurden:

BackupCopyLookForward HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\

Damit kann man den Zeitpunkt auf genau 18:00 Uhr setzen und der Backup Copy Job wartet, bis der 18:00 Backup Job fertig ist.

Im nächsten Schritt ist auszuwählen, was als Quelle für den Backup Copy Job dienen soll (siehe Abbildung 2):

Abbildung 2: Quelldaten

Dabei gibt es folgende Auswahl:

Abbildung 3: Secondary Target in der Backup Job Konfiguration

Ein Backup Copy Job kann mehrere Quellen haben. Sollte eine VM in mehreren Quellen vorhanden sein, überträgt er nur die aktuellste Version. Ein Backup Job kann auch mehrere Secondary Targets haben (siehe Abbildung 3).

Nach Auswahl der Quelle(n) ist ein Ziel zu definieren. Das Ziel ist ein Veeam Repository. Abbildung 4 zeigt die möglichen Einstellungen:

Abbildung 4: Ziel

Ein Backup Copy Job erstellt immer mindestens eine Forward Incremental Forever Backupkette, deren Länge durch „Restore points to keep“ definiert ist. Zusätzlich zur genannten Forward Incremental Forever Backupkette besteht die Möglichkeit, für längere Vorhaltedauer zusätzliche Vollsicherungen an bestimmten Tagen aufzuheben: „Keep the following restore points for archival purposes“. Das entspricht dem klassischen Grandfather-Father-Son (GFS- Prinzip, wie es von Bandsicherungen bekannt ist (Abbildung 5):

Abbildung 5: GFS

Hierbei ist zu beachten, dass die Restore Points als Full Backup gespeichert werden. Hinweis: Das Full Backup wird nicht an genau am konfigurierten Tag (beispielsweise erster Sonntag im Monat)  generiert! Es wird zunächst markiert und erst in dem Moment, in dem es aus der Retention fallen würde, wird das Full Backup erstellt.

Praktisch, vor allem wenn Daten über geringe Bandbreiten transportiert werden müssen: Der Backup Copy Job arbeitet „inkrementell forever“ und die Generierung der Full Backups erfolgt standardmäßig auf der Zielseite.

Platzverbrauch bei GFS

Im obigen Beispiel (Abbildung 5) würden sehr viele Vollsicherungen aufgehoben werden. Auch wenn ein Backup beispielsweise gleichzeitig Wochen- und Monatsbackup sein kann, wäre der Platzverbrauch enorm.

Um den Platzverbrauch zu reduzieren gibt es mehrere Möglichkeiten:

  1. Die wöchentlichen Restore Points lassen sich üblicherweise durch 30 „Restore points to keep“ ersetzen, da 30 inkrementelle Sicherungen meistens weniger Platz benötigen als vier Vollsicherungen.
  2. Einsatz von Deduplizierungs-Appliances oder Windows Server 2016 ReFS Integration / Deduplizierung (begrenzte Skalierbarkeit mit Windows 2012)
  3. Um die Monats-/Quartalsstände aufzuheben, einen zweiten Backup Copy Job nutzen, der alle 30 Tage läuft

Die dritte Variante ist nicht ganz naheliegend, daher eine Erklärung:

Daraus ergeben sich ein Full Backup und elf inkrementelle Stände: die Monatsbackups. Dabei ist es unerheblich, wie viele Restore Points der ursprüngliche Backup Job hat. Der Backup Copy Job ist kein „dummer“ Kopiervorgang, sondern er prüft blockweise, welche Daten sich im definierten Zeitraum geändert haben. Ein Beispiel für die Platzersparnis verglichen mit dem GFS Schema zeigt Abbildung 6:

Abbildung 6: Beispiel für monatliche inkrementelle Stände

Zu sehen ist hier ein Fileserver, dessen Vollsicherung knapp 10 TB belegt (Größe der .vbk Datei). Die Änderungsrate pro Monat liegt bei ca. 1 – 2TB (Größe der .vib Dateien). Die Platzersparnis ist hier also pro Monat 8 – 9TB, was bei zwölf Monaten Vorhaltezeit durchaus signifikant ist. (Hinweis: Jahresbackups würden wie in Abbildung 8 dargestellt mit GFS im täglichen Backup Copy Job konfiguriert werden, da das maximale Copy Intervall 100 Tage beträgt.)

Der Nachteil dieser Variante soll natürlich auch nicht verschwiegen werden: Sollte es Beschädigungen an der Backupkette geben (Bitfehler, unabsichtliches Löschen), können mehrere Monatssicherungen unbrauchbar werden. Daher kommt diese Variante hauptsächlich in Kombination mit Bandsicherungen zum Einsatz (siehe Abbildung 7):

Abbildung 7: Backup Copy Job und Tape

Für Deduplizierungs-Appliances oder Windows Deduplizierung gilt natürlich dasselbe: Sollte die Deduplizierungs-Datenbank beschädigt werden, sind ganze Backupketten in Gefahr.

Neu in Version 9 ist die Option „Read the entire restore point from source backup instead of synthesizing it from increments“ (siehe Abbildung 8). Diese Option ist das genaue Gegenteil des vorher beschriebenen „der Backup Copy Job ist immer inkrementell”. Sie ist für Systeme gedacht, die eine sehr schlechte Performance bei synthetischen I/O Operationen haben. Das gilt hauptsächlich für Deduplizierungs-Appliances ohne Veeam Integration und für kleine Disk-Systeme (2 – 8 Festplatten) in KMU-Umgebungen. Hier muss dann natürlich entsprechend Bandbreite vorhanden sein, da die Daten komplett neu zwischen primärem und sekundärem Backup übertragen werden.

Abbildung 8: Restore Point neu übertragen

Der vorletzte Schritt (Abbildung 9) bietet als optionale Möglichkeit den Veeam WAN-Beschleuniger.

Abbildung 9: WAN-Beschleuniger

Der letzte Konfigurationsschritt ist eine Möglichkeit, die Aktivität des Backup Copy Jobs auf bestimmte Uhrzeiten einzuschränken. Abbildung 10 zeigt, dass wochentags während der Arbeitszeiten keine Daten übertragen werden. Einschränkungen der Bandbreite sind in den globalen „Network Traffic“-Einstellungen möglich.

Abbildung 10: Schedule Einschränkungen

Erweiterte Einstellungen

Beim Backup Copy Ziel (Abbildung 4) gibt es einige interessante erweiterte Einstellungen. Die Wartungseinstellungen sind in Abbildung 11 dargestellt:

Abbildung 11: Wartung

Standardmäßig führt Veeam bei jedem Backup Copy Job einmal pro Monat am letzten Samstag eine Konsistenzprüfung durch. Diese dient dazu, eventuell durch das Storagesystem verursachte Fehler zu finden (Silent Data Corruption). Dabei liest Veeam alle Datenblöcke der Sicherung und prüft, ob die Checksummen noch korrekt sind. Bei vielen Backup Copy Jobs empfiehlt es sich die Konsistenzprüfungen auf mehrere Tage zu verteilen, da das vollständige Auslesen der Daten entsprechend I/O Last am Storagesystem erzeugt.

Optional besteht die Möglichkeit, das Full Backup regelmäßig zu defragmentieren, was langfristig zu (geringen) Performancesteigerungen und Platzersparnissen führen kann.

Zusammenfassung

Der Backup Copy Job ist wesentlich flexibler als der Name vermuten lässt. Er ist ein robustes Werkzeug, das die Einhaltung der 3-2-1 Regel vereinfacht.

Lesen Sie auch

Exit mobile version