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:
- Zu einem bestimmten Zeitpunkt prüfen, ob es neue Backup-Daten gibt
- Falls nicht, auf neue Backup-Daten warten
- Daten kopieren
- Wenn nicht alle Daten innerhalb des definierten Zeitfensters übertragen werden konnten, dann weiter versuchen die Daten zu übertragen, bis alle Daten am Zielort liegen.
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:
- Backup Job läuft beispielsweise alle 6 Stunden (00:00, 06:00, 12:00, 18:00 Uhr)
- Backup Copy Job soll ab 18:00 Uhr Backup-Daten kopieren
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:
- From Infrastructure: Virtuelle Maschinen (Container); Veeam Backup Copy Job sucht automatisch, wo er das aktuellste Backup findet
- From Backups: Auswahl von VMs oder ganzen Backups
- From Jobs: Bei Auswahl eines Jobs wird im ursprünglichen Backup Job automatisch das „Secondary Target“ eingetragen (siehe Abbildung 3)
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:
- 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.
- Einsatz von Deduplizierungs-Appliances oder Windows Server 2016 ReFS Integration / Deduplizierung (begrenzte Skalierbarkeit mit Windows 2012)
- 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:
- „copy every“ (Abbildung 1: Jobdefinition) auf 30 Tage setzen
- „restore points to keep“ auf 12 setzen
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.