Das zumindest denkt sich Veeam Backup & Replication, wenn es eng wird im Repository – zumindest zu eng für ein weiteres Vollbackup.
Bei der klassischen “Forward Incremental” Methode, bestehend aus einer (z.B. wöchentlichen) Vollsicherung und mehreren (täglichen) inkrementellen Sicherungen kann man in einem zu klein dimensionierten Backup Repository schon mal schnell an die Grenzen stossen.
Ich sehe es leider viel zu oft bei meinen Kunden, dass der Speicherplatz viel zu knapp bemessen wurde, so dass stellenweise weniger als drei Vollsicherungen gleichzeitig Platz finden. Daran, dass Veeam ja auch noch etwas rangieren muss, gerade wenn Synthetic Fulls erstellt werden, denken leider die wenigsten Entscheider.
Die Inkrements sind dabei natürlich alle abhängig von sämtlichen vorherigen Backups im aktuellen Zyklus, so dass der Verlust einer Sicherungsdatei alle darauf folgenden vollkommen unbrauchbar macht.
Aber zurück zum Titel dieses Posts: Steht am Wochenende mal wieder eine Vollsicherung an, obwohl nicht ausreichend Speicherplatz im Repository vorhanden ist, wird Veeam stattdessen eine weitere inkrementelle Sicherung starten, getreu dem Motto “Besser als gar keine Sicherung!” und “Einer geht noch!”.
So weit, so gut, aber dadurch wird das Problem weiter nach hinten geschoben und früher oder später ist das letzte Kilobyte geschrieben und der Backup Job läuft vor den berühmten Hammer.
Genau das ist mir heute zum wiederholten Male begegnet. Der Backup Job war für 30 Restore Points konfiguriert, vorhanden waren 160 – alle in ein- und demselben Backupzyklus, alle abhängig von ihren Vorgängern. Eine unangenehme Situation, wenn man dem Kunden erklären muss, dass er sich von seiner kompletten Datensicherung trennen muss, um eine aktuelle zu erstellen. Glücklich, wer dann die 3-2-1 Regel befolgt hat und über weitere Kopien verfügt.
Wo aber ist der Unterschied zur “Forever Forward Incremental” Methode, in der ja auch niemals eine aktuelle Vollsicherung erstellt und der ursprüngliche Zyklus bis in alle Ewigkeit weitergeführt wird?
Die Antwort liegt in der Konfiguration der Restore Point Anzahl versteckt. Während bei der klassischen Methode ganz optimistisch davon ausgegangen wird, dass schon irgendwann wieder Platz für ein weiteres Full sein wird, und ältere Sicherungsdateien aufgrund ihrer Retention automatisch gelöscht werden können, ist bei “Forever” ja von vorneherein klar, dass die Kette unendlich weitergeht.
Um also das Repository nicht platzen zu lassen und gleichzeit die geforderte Anzahl an Restore Points vorzuhalten, wendet Veeam nach der eigentlichen Sicherung die Methode der “Transformation” an. Dabei werden die Datenblöcke des ältesten inkrementellen Restore Points in das am Anfang der Kette stehenden “Full” injiziert und die danach nicht mehr benötigte inkrementelle Sicherung aus dem Repository gelöscht.
Dadurch hat man immer exakt die eingestellte Anzahl an Wiederherstellungspunkten, bei 30 Stück also eine Vollsicherung und 29 Inkremente.
Die gute Nachricht ist: Ich kann jederzeit aus meinem Forward Incremental Backup ein Forever Forward Incremental machen, indem ich in der Job Konfiguration (unter Storage -> Advanced) einfach die Haken für Synthetic Full und Active Full entferne und den Job ein weiteres Mal laufen lasse (siehe Screenshot).
Gesetzt den Fall, dass mein Repository noch ein bisschen Platz zum Rangieren hat, erzeugt das erst eine weitere inkrementelle Sicherungsdatei und transformiert anschliessend die ältesten Restore Points in eine “neue” Vollsicherung.
In den letzten 9 Stunden sind mittels dieser Vorgehensweise aus den oben genannten 160 Restore Points mittlerweilen 116 geworden – die 30 sind dann wohl irgendwann am Wochenende auch erreicht…