Wann löscht NetWorker ein Backup?

Vielleicht hat es jeder schon einmal gesehen: Man hat ein Backup gefunden, seine Aufbewahrungszeit (Retention Time) ist abgelaufen, aber das Backup ist noch da. Warum?
Meistens treten diese Fragen dann im Zusammenhang damit auf, dass der Backup Storage (z.B. eine Data Domain) sich langsam füllt und vielleicht sogar eine Erweiterung ansteht.
Jetzt gilt es herauszufinden, ob es ggf. noch alte Backups gibt, die eigentlich nicht mehr da sein sollten. Oder etwa doch?
An dieser Stelle muss ich dazu sagen, dass es hin und wieder tatsächlich Backups gibt, welche aus unerfindlichen Gründen nicht automatisch gelöscht werden, obwohl alle Fakten dagegensprechen. Hier kann z.B. ein Bug vorliegen oder ein Problem mit einer der NetWorker-Datenbanken (z.B. ausgelöst durch einen Crash des Servers, auf dem der NetWorker läuft).
Häufig ist es allerdings so, dass es einen Grund gibt, weshalb NetWorker ein Backup nicht löscht, obwohl man der Meinung ist, dass dieses Backup eigentlich nicht mehr da sein sollte.

Hierzu muss man erst einmal verstehen, wann NetWorker überhaupt darüber nachdenkt, Backups zu löschen.
NetWorker liefert das Programm nsrim (NetWorker Index Management) mit, welches der Auslöser für NetWorker ist, Backups zu löschen.
nsrim geht hin und überprüft, ob ein Backup gelöscht werden könnte. Falls er befindet, dass dies der Fall ist, markiert er das entsprechende Backup als „Eligable for Recycling“, sprich als „kann-gelöscht-werden“. Nachdem nsrim mit der Prüfung fertig ist, wird im Anschluss dann auch wirklich gelöscht.
Beim NetWorker 8 und älter hat NetWorker bei jedem Backup automatisch den nsrim gestartet und dabei die Clients, die in der Gruppe waren, geprüft. Dieses Verhalten konnte man durch das regelmäßige Anlegen der nsrim.priv Datei beeinflussen. Aber dann war es auch die Aufgabe des Administrators, dafür zu sorgen, dass der nsrim gestartet wird (z.B. 1x täglich mittels Crontab).
Mit dem NetWorker 9 hat sich dies jedoch geändert. Denn seitdem gibt es eine Expiration-Action, welche nichts anderes macht, als den nsrim zu starten und damit letzten Endes den Löschvorgang durchzuführen. Das aus NetWorker 8 bekannte Verhalten mit dem nsrim bei jedem Lauf einer Gruppe wurde abgeschafft.

An dieser Stelle noch ein wichtiger Hinweis zu NetWorker 8:
Nutzt man noch die Virtual Backup Appliance (VBA) / EMC Backup & Recovery Appliance (EBR), markiert der nsrim KEINE (!) VM Backups als löschbar, bzw. er ignoriert diese einfach komplett.
Für VBAs muss man selber dafür sorgen, dass NetWorker einen Cross sync mit der VBA durchführt.
Dafür kann man sich z.B. ein Script schreiben, welches man täglich ausführt.
Den Cross sync führt man mit diesem Kommando durch. Da man nur eine VBA angeben kann, muss man das Kommando also für jede VBA einzeln durchführen.

nsrim -X -S -h <EMC_Backup_and_Recovery_appliance_hostname>  -f

Mit dem NetWorker 9 wurde dies jedoch endlich ebenfalls automatisiert.

Damit sollte jetzt bekannt sein, wann der Löschvorgang überhaupt losgeht.
Um zu wissen, wann NetWorker ein Backup löscht, muss man sich einen Satz vor Augen halten:
NetWorker markiert ein Backup als löschbar, wenn seine Aufbewahrungszeit UND die Aufbewahrungszeit aller darauf aufbauenden Backups abgelaufen ist.

Doch was heißt das nun genau?

Dies möchte ich anhand von zwei Beispielen erklären.
Beispiel 1:
Am 01.04. läuft ein Full Backup, am 02.04. und 03.04. jeweils ein inkrementelles.
Alle Backups haben eine Aufbewahrungszeit von einer Woche.

Wie man sehen kann, wird das Full Backup nicht am 08.04. gelöscht, sondern erst am 10.04.
Und das erste inkrementelle Backup wird ebenfalls am 10.04. gelöscht.
Das Full Backup kann am 08.04. nicht gelöscht werden, weil das inkrementelle Backup vom 02.04. darauf aufbaut, dessen Aufbewahrungszeit allerdings noch nicht abgelaufen ist.
Ebenso können weder das Full Backup, noch das inkrementelle Backup vom 02.04. am 09.04. nicht gelöscht werden, weil das inkrementelle Backup vom 03.04. auf den beiden aufbaut und erst am 10.04. abläuft.
Am 10.04. jedoch ist es endlich soweit und alle drei Backups werden gelöscht.

Am 01.04. läuft ein Full Backup, am 02.04. ein inkrementelles und 03.04. differenzielles Backup.
Alle Backups haben eine Aufbewahrungszeit von einer Woche.

Hierfür muss einem der Unterschied zwischen inkrementell und differentiell klar sein. Ein inkrementelles Backup sichert immer die Änderungen zum letzten Backup, egal ob full, inkrementell oder differentiell. Ein differentielles Backup dagegen sichert immer nur die Änderungen zum letzten Full Backup. Der Vollständigkeit halber sollte ich erwähnen, dass es noch verschiedene Level von differentiellen Backups gibt. Ein Level 1 differentielles Backup sichert die Änderungen zum letzten Full, ein Level 2 differentiell zum letzten Level 1, ein Level 3 zum letzten Level 2, usw.
Am 08.04. kann in diesem Beispiel auf jeden Fall wieder nichts gelöscht werden. Am 09.04. kann jedoch das inkrementelle Backup gelöscht werden, da sich das differentielle Backup auf das Full Backup bezieht. Und am 10.04. können dann auch Full+Differentiell gelöscht werden.

Der nsrim macht im Prinzip nichts anderes, als diese ganzen Abhängigkeiten zueinander aufzulösen und dann die entsprechenden Backups als löschbar zu markieren.

Warum ist es so wichtig, dieses Verhalten zu kennen?
Wenn man z.B. 1x in der Woche ein Full Backup und an allen Tagen ein inkrementelles Backup durchführt, wieder mit einer Woche Retention, hat man effektiv gesehen eine Aufbewahrungszeit von fast zwei Wochen!
Die ganze Kette kann ja erst gelöscht werden, wenn auch das letzte inkrementelle Backup abgelaufen ist. Es ist häufig so, dass der nsrim auch erst am nächsten Tag startet und auch dann erst tatsächlich ein Backup löscht.
Aus vier Wochen Aufbewahrungszeit werden damit also effektiv fünf und aus 30 Tagen werden 37.
Führt man nur 1x im Monat ein Full und ansonsten nur inkrementelle oder differentielle Backups mit 30 Tagen Aufbewahrungszeit durch, hat man das Full gleich zwei Monate lang herumliegen.

Noch gravierenden ist es, wenn man z.B. einmal im Monat eine Sicherung durchführt, welche für ein Jahr aufbewahrt werden soll. Wenn man sich des Löschverhaltens nicht vollständig bewusst ist, könnte man der Versuchung erliegen, einfach das Backup am jeweiligen Stichtag mit einer höheren Retention laufen zu lassen. Hat man dann Pech und es läuft ein inkrementelles Backup, kann das Full Backup auch erst gelöscht werden, wenn dieses eine inkrementelle Backup ein Jahr später abgelaufen ist.

Ebenfalls muss man darauf achten, dass die Full Backups erfolgreich sind! Bricht ein Full Backup aus irgendeinem Grund ab, bezieht sich die inkrementelle Sicherung auf das letzte erfolgreiche Backup davor. Und die inkrementellen Sicherungen im Laufe der restlichen Woche bis zum nächsten Full Backup natürlich ebenfalls.

Ich werde noch einen weiteren Beitrag zu diesem Thema schreiben, welcher dann auch ans Eingemachte geht und zeigt, wie man diese Abhängigkeiten selber auflösen und sich den Status eines Backups anzeigen lassen kann.
Und dort werde ich auch noch auf einige Spezialfälle eingehen, bei denen NetWorker Backups nicht löscht, obwohl nsrim sie als löschbar markiert hat.