Im diesem Beitrag der “Warum löscht NetWorker mein Backup nicht?”-Serie gehe ich darauf ein, wie man die Abhängigkeiten der Backups untereinander auflöst und somit herausfinden kann, ob ein Backup aus diesem Grund nicht gelöscht worden ist. Vom Prinzip her gibt es zwei Möglichkeiten, um an die Sache heranzugehen: Via NMC oder via Kommandozeile.
Die NMC bietet den Vorteil, dass sie visuell natürlich ansprechender ist, keine Kenntniss der Parameter auf der Kommandozeile benötigt und einem zu den gefundenen Backups auch direkt weitere Möglichkeiten bietet wie z.B. die Aufbewahrungszeit herunterzusetzen oder die Backups zu klonen.
In der NMC erreicht man die entsprechende Ansicht über den Reiter Media und dann auf “Save Sets”. Dort hat man eine Vielzahl an Einstellungsmöglichkeiten, um die Suchergebnisse einzugrenzen. Man kann hier z.B. auswählen, dass man nur die Backups aus einer bestimmten Policy angezeigt bekommt, einen Zeitraum wählen oder den Namen des Backups.
In meinem Beispiel habe ich hier nur den Namen des Clients gesetzt, den Namen eines Save sets sowie den Zeitraum, aus dem mir Backups angezeigt werden sollen.
Um die Suche zu starten, klickt man oben auf “Save Set List”. Anhand der gewählten Einstellungen bekommt man dort dann die gefundenen Backups angezeigt.
In meinem Fall interessiere ich mich für den markierten Zyklus. Das Full Backup ist vom 07.04.2019 und hat eine Aufbewahrungszeit bis zu, 07.05.2019 (sprich: gestern). Das Backup ist aber noch vorhanden, weil die inkrementellen Sicherungen der Folgetage darauf aufbauen, Erst, wenn die inkrementelle Sicherung vom 13.04. am 13.05. ausgelaufen ist, löscht NetWorker alle diese Backups.
Angenommen, das Full Backup vom 14.04. wäre fehlgeschlagen. Dann würden sich die folgenden inkrementellen Sicherungen nicht auf das Full vom 14.04. beziehen (welches vom NetWorker schnell gelöscht wird, da er auf Disk Devices keine fehlgeschlagenen Backups behält), sondern auf dem Full vom 07.04. Ergo wird dieses Full Backup inklusive aller darauf aufbauenden inkrementellen Sicherungen erst gelöscht, wenn auch die letzte inkrementelle Sicherung aus dem Folgezyklus abläuft. Daher ist es immens wichtig, dass die Full Backups erfolgreich laufen. Hat man Probleme mit einem Full Backup (z.B. weil es sehr groß ist und aus dem Backup Zeitfenster läuft) und bekommt dieses nicht erfolgreich hin, können sich hier eine ganze Menge an Daten aufstauen.
Das gleiche Beispiel stelle ich nun auch einmal mit der Kommandozeile dar.
Dafür nutze ich das Programm “mminfo”, welches der NetWorker Server mit sich bringt.
Wie man anhand der Parameter des Befehls sehen kann, benötigt man hierfür schon etwas mehr Wissen darüber, wie man die Paramter entsprechend gestalten soll. Ich kann nur empfehlen, sich mit dem mminfo auseinander zu setzen, da dieser sehr nützlich ist. Die NetWorker Dokumentation liefert dazu Informationen.
In meinem Fall habe ich lediglich einen Query (-q) auf den Namen des Save sets ( / ) gemacht, da ich in dieser Test-Umgebung nur einen Linux-Client habe und es das /-Saveset daher auch nur bei diesem einen Client gibt.
Und als Report (-r) lasse ich mir den Client, den Namen des Save sets, die Backup-Zeit, die Aufbewahrungszeit des gesamten Save sets sowie die Aufbewahrungszeit der einzelnen Klone, das Level und dann den Status des Save sets & der Klone ausgeben.
Da ich hier keine Klone durchführe, ist die Aufbewahrungszeit des gesamten Save sets und des jeweiligen Klons (in meinem Fall also das primäre Backup) identisch.
Wenn man aber Backups klont und dabei andere Aufbewahrungszeiten verwendet (z.B. 1 Jahr für den Klon), macht es aber durchaus einen Unterschied.
Die vielleicht wichtigste Spalte ist aber an dieser Stelle tatsächlich die Spalte ssflags. Denn diese teilt mir den Status des Backups (vF = valid & Finished) mit. Ich weiß also hier, dass das Backup sich in einem guten Zustand befindet und nicht als löschbar (E) oder incomplete (i) markiert worden ist. In der NMC wird das vF durch den Status browsable repräsentiert.
Letztendlich kommt aber hier die gleiche Liste an Backups heraus, die ich auch in der NMC bekommen habe.
Wo liegen nun die Unterschiede zwischen den beiden?
Wenn man die Daten z.B. in eine Excel Tabelle einfügen möchte, ist dies mit der NMC recht einfach. Die Daten dort kann man mittels STRG+C kopieren und direkt in Excel einfügen. Und um mal eben schnell etwas nachzuschauen, ist die NMC auch super.
Beim mminfo gibt es die Möglichkeit, ein Trennzeichen setzen (Parameter: -xC”<trennzeichen>”.
Also z.B.: -xC”;” um das Semikolon als Trennzeichen zu verwenden. Die Ausgabe des mminfos kann man in eine Datei umleiten und hätte bei einem Semikolon dann auch direkt eine Datei, die man mit Excel öffnen kann.
Der mminfo liefert die Daten schneller als die NMC, weil sie dort direkt ausgegeben werden und nicht erst noch durch Java durch müssen.
Der große Vorteil der Kommandozeile erschließt sich natürlich erst recht dann, wenn man diese direkt weiterverarbeiten möchte, wie etwa mit einem Script.
Mein Beispiel hier ist natürlich ein sehr einfaches Beispiel, da ich mich auf ein einzelnes Saveset beschränkt habe. In der Realität kann man dies natürlich nicht verwenden, da man ja nicht weiß, welches Saveset ggf. Probleme macht.
In der Realität zieht man meistens einen Dump der gesamten Backups (mminfo -a ohne Zeitliche Einschränkungen bei den Parametern -q oder -t). Diesen Dump könnte man dann als CSV-Datei (mittels -xC”;” und Umleitung der Ausgabe in eine Datei) erzeugen, mit Excel öffnen und dann dort entsprechende Filter setzen. Den Dump kann man natürlich auch mittels NMC erzeugen, aber gerade bei großen Umgebungen mit vielen Savesets kann es dazu führen, dass Millionen von Savesets zurückbekommt. Vielleicht bleibt sogar die NMC bei der großen Datenmenge hängen und wer schon einmal probiert hat, 30MB mittels Copy & Paste in Excel einzufügen, weiß vermutlich, dass dies eine gefühlte Ewigkeit dauert und man hoffen muss, dass Excel dabei nicht abstürzt.
Wenn man aber einen Verdacht hat, dass Backups nicht gelöscht werden, wird man letzten Endes nicht darum herum kommen, sich solch einen Dump zu erstellen und jedes einzelne Backup zu überprüfen.
Ich hatte z.B. einmal den Fall, dass MSSQL Transaction Log Backups mit 10 Jahren Aufbewahrungszeit auf Bänder geklont worden sind. Und die dafür zu Grunde liegenden Full Backups auf der Data Domain konnten daher nicht gelöscht werden. Da aber eigentlich die Full Backups und nicht die Transaction Logs hätten auf Tape geklont werden sollen, konnte ich dies damit beheben, dass ich die Full Backups (die ja noch da waren) auf Band geklont und die Transaction Log Backups aus der NetWorker Mediendatenbank gelöscht habe. Damit waren die ganzen Backups auf der Data Domain weg und wieder ordentlich Platz verfügbar.
Ein kleiner Haken an der falschen Stelle kann also sehr große Auswirkungen haben.
Seit 2006 bin ich im Data Protection Bereich tätig und habe über die Jahre Erfahrungen mit diversen Produkten sammeln können. Darunter NetBackup, Avamar und natürlich vor allem NetWorker. Mit NetWorker habe ich seit meiner Ausbildung zum Fachinformatiker – Fachrichtung Anwendungsentwicklung – zu tun und habe mich auch auf diesen spezialisiert – vor allem in Kombination mit der Data Domain als Backup Storage. Darüber hinaus programmiere ich gerne in der Sprache Perl, sei es nun beruflich oder privat.