HBS 3 und Versionierung - Noch ein kleiner Überblick

[PROLOG]

Backups waren schon immer wichtig, noch wichtiger werden sie zuletzt durch die gehäuften Ransomware Attacken.
Den für Jedermann verbindlichen Backupplan gibt es nicht, jedoch kann ein versioniertes Backup oftmals ein wichtiger Bestandteil der Backupstrategie sein. Von entscheidender Bedeutung ist hierbei, wie weit die Versionierung zurück reicht.
Hier habe ich HBS3 für die Erstellung von Backups kurz vorgestellt, ohne auf die Versionierung einzugehen. Dies möchte ich im Folgenden kurz nachholen und beschreiben, wie sich eine Versionierung darstellt und welche Möglichkeiten der Versionierung bestehen.

[DER BACKUP JOB - EINSTELLEN DER VERSIONIERUNG]
Grundsätzlich ist eine Versionierung nur mit Backup-Jobs, nicht aber mit Sync-Jobs möglich. Dadurch bedingt landen wir schon bei einer drastischen Einschränkung, denn Backup-Jobs können in HBS3 ausschließlich auf einen anderen QNAP, externe Datenträger oder einen Cloudspeicher sichern.

Nachdem bei der Erstellung des Jobs die Ordnerpaare gewählt wurden, wird zunächst der Zeitplan festgelegt. Hier finden wir dann auch das Menü für die Versionierung, wo diese zunächst aktiviert werden muss. Anschließend stehen zwei grundlegende Methoden zur Verfügung: Die einfache Versionierung und die intelligente Versionierung.
In jedem Fall ist von entscheidender Bedeutung, wie der Zeitplan festgelegt ist, denn dies wirkt sich später auf die Versionen (bzw. Datenstände) aus, die uns im Backup zur Verfügung stehen.

Nachdem ein Job erstellt wurde kann die Versionierung nicht mehr ein- oder ausgeschaltet werden.

[EINFACHE VERSIONIERUNG]
Bei der einfachen Versionierung besteht die Möglichkeit die Anzahl der zu behaltenden Versionen oder der zu behaltenden Tage anzugeben. Die jeweligen Maxima sind angegeben.

job_creation1.PNG

Die Anzahl aufzubewahrender Versionen ist leicht zu verstehen:
Egal wie häufig das Backup gemäß Zeitplan ausgeführt wird, es wird einfach die angegebene Anzahl an Versionen aufbewahrt, wird diese überschritten, wird das älteste Backup gelöscht.

Beispiel 1 - Zeitplan = täglich; aufzubewahrende Versionen = 365:

Hierbei würde die Versionierung etwa ein Jahr zurückreichen, alle erstellten täglichen Versionen sind verfügbar.

Beispiel 2 - Zeitplan = stündlich; aufzubewahrende Versionen = 336:

Hierbei würde die Versionierung zwei Wochen zurückreichen (24h*7 Tage*2 Wochen = 336), auch hier bleiben alle erstellten stündlichen Versionen für zwei Wochen verfügbar.

Bei der Anzahl aufzubewahrender Tage verhält es sich ähnlich, hierbei werden alle Versionen verworfen, die älter sind als die angegebene Anzahl an Tagen.

Beispiel 1 - Zeitplan = täglich; aufzubewahrende Tage = 365:

Hierbei würde die Versionierung etwa ein Jahr zurückreichen, alle erstellten Versionen (insgesamt 365 tägliche Versionen) sind verfügbar.

Beispiel 2 - Zeitplan = stündlich; aufzubewahrende Tage = 14:

Hierbei würde die Versionierung zwei Wochen zurückreichen, auch hier bleiben alle in den letzten 14 Tagen erstellen Versionen verfügbar, also in Summe 24*14= 336 stündliche Versionen.

[INTELLIGENTE VERSIONIERUNG]
Bei der intelligenten Versionierung wird angegeben, wie viele stündliche, tägliche, wöchentliche und monatliche Versionen aufgehoben werden sollen. Auch hier sind die jeweligen Maxima angegeben.

job_creation2.PNG

Die Krux bei der intelligenten Versionierung ist, dass bestimmte Versionen zu bestimmten Zeitpunkten in eine andere Version „konvertiert“ werden, z.B. werden stündliche Versionen zu täglichen Versionen und so weiter.

Beispiel 1 - Zeitplan = täglich; Stunden = 1, Tage = 7, Wochen = 4, Monate = 12:

Dieses Szenario klingt relativ verständlich, die Monate sind maßgeblich dafür, wie lange die Versionierung zurückreicht, das sind in diesem Fall etwa 12 Monate / 1 Jahr.
Im Gegensatz zur einfachen Versionierung (Beispiele 1) bleibt hier jedoch nicht jede Version bestehen. Wichtig ist es zunächst zu verstehen, wann eine Sicherung als tägliche, wöchentliche und monatliche Version gilt, bzw. welche Sicherung zu einer entsprechenden Version „konvertiert“ wird. Es ist ein Irrglaube, dass z.B. eine Sicherung nach 7 Tagen ab Jobbeginn zur wöchentlichen Version wird. Tatsächlich wird - unabhängig von der Job-Laufzeit - die älteste vorhandene tägliche Version zu Wochenbeginn zu einer wöchentlichen Version. Zum Monatsbeginn wird dann die älteste vorhandene wöchentliche Version zur Monatlichen. Um den Datenstand einer monatlichen Version zu bestimmen ist also entscheidend, wie viele wöchentliche, tägliche und stündliche Versionen aufbewahrt werden. Wenn demnach am 30.08.20xx eine wöchentliche Version zur Monatlichen wird, entspricht der Datenstand nicht dem 30.08. sondern dem Stand vier Wochen (vier aufzubewahrende wöchentliche Versionen) zuvor.
Bei jeder Erstellung einer neuen Version wird die älteste Version dieser Art gelöscht, sofern die angegebene Anzahl an aufzubewahrenden Versionen erreicht ist.

Einfach zusammengefasst kann man sagen, dass nach 13 Monaten die Versionen der letzten 7 Tage, von vor 2, 3, 4 und 5 Wochen sowie die Versionen vor 2 bis 13 Monaten verfügbar sind. Somit sind insgesamt immer etwa* 23 Sicherungssätze verfügbar.

Die stündliche Version findet hier „eigentlich“ keine Anwendung, da das Backup ja nur täglich erstellt wird; u.U. wird man dennoch eine stündliche Version finden, welche in diesem Beispiel als tägliche Version betrachtet werden muss.

* „etwa“ weil u.U. die aktuellste („latest“) Version nicht zu den täglichen, stündlichen , … Versionen gezählt wird sondern eine zusätzliche Version bildet. Ferner kann es dazu kommen, dass eine wöchentliche Version zur Monatlichen konvertiert wurde, aber noch keine neue wöchentliche Version erstellt wurde (siehe 01.04. in nachfolgender Tabelle).

Etwas mehr Aufschluss gibt folgende Tabelle, welche darstellt, zu welchem Zeitpunkt welche Version vorhanden ist, und wann Versionen konvertiert werden. Bei der Darstellung habe ich mich an einem Beispiel von QNAP orientiert.

Die "Berechnung", welche Datenstände (in der Tabelle "vorhandene Versionen von Datum") nach einem Jahr Laufzeit vorhanden sind, habe ich mir nicht angetan, eine automatisierte Berechnung habe ich bei bestem Willen nicht hinbekommen - das zeigt nochmal, dass es durchaus nachvollziehbar ist, dass die intelligente Versionierung im Detail schwer zu verstehen ist.

versiontable.png

Ich hoffe ich habe hier keinen Bock eingebaut Warum ich ausgerechnet Monat 3/2017 gewählt habe weiß ich gar nicht mehr, hatte aber einen bestimmten Grund...

Beispiel 2 - Zeitplan = stündlich; Stunden = 24, Tage = 1, Wochen = 1, Monate = 12:
Hier werden wie im Beispiel zuvor ebenfalls etwa 12 Monate rückwirkend Versionen beibehalten, die Zeitpunkte der vorhandenen Versionen unterscheiden sich jedoch.

Entsprechend ist (nach etwa einem Tag Laufzeit) für 24h rückwirkend jede stündliche Version verfügbar. Am Ende eines Tages wird die älteste stündliche Version zur täglichen Version konvertiert, welche bis zum Ende des nächsten Tages behalten wird, wo sie von der nun ältesten stündlichen Version wieder überschrieben wird. Dies führt sich entsprechend mit den Wochen und Monaten wie in Beispiel 1 fort, sodass nach einer Laufzeit von 12 Monaten insgesamt etwa 38 Sicherungssätze vorhanden sind.

[VERSIONIERTE DATEN IM BACKUP]

Schaut man sich die Daten eines versionierten Backups an (Details folgen im nächsten Abschnitt), stellt man fest, dass in jedem Ordner, die jeweils für die Versionen angelegt werden, immer wieder die selben Daten auftauchen, auch wenn diese nicht verändert wurden - braucht das nicht unheimlich viel Speicherplatz? Nein! Denn Daten, die sich nicht verändert haben, werden nicht doppelt und x-fach gespeichert, sondern einmalig. Die Dateien die man in neueren Versionen sieht sind lediglich harte Verknüpfungen (Hardlinks) , die auf die einzig vorhandene Datei verweisen, aber wie normale Dateien behandelt werden. Zusätzliche Kapazität wird also nur für veränderte Dateien benötigt. Der Inhalt eines Versionsordners ist somit stets ein Abbild der Originaldateien zum Zeitpunkt der Backuperstellung. Eine Ansicht ausschließlich von Daten, die sich zur Vorversion (oder einer anderen) geändert haben ist nicht möglich.

[ANMERKUNGEN]

Als wenn insbesondere die intelligente Versionierung im Detail nicht schon schwer genug zu durchblicken ist, so gibt es noch ein paar Kleinigkeiten, die man berücksichtigen sollte.

Da wäre z.B. die Tatsache, dass die Versions-Bezeichnung der Ordner im Backup abhängig davon ist, ob ein Job mit QuDedup ausgeführt wird, oder nicht.

Mit QuDedup ist die Syntax Zeitzone_Datum_Uhrzeit, wobei Datum und Uhrzeit dem Erstelldatum der Version entpricht und keine Aussage über den Zeitpunkt des Datenstands trifft.

dedup.PNG (Bezeichnung mit QuDedup)

Ohne QuDedup lautet die Syntax DatumUhrzeit.Versionsindikator. Datum und Uhrzeit entsprechen hier hingegen dem Zeitpunkt des Datenstands dieser Version.

Der Versionsindikator gibt an, ob es sich um eine stündliche, tägliche, … Version handelt.

Außerdem gibt es ohne Verwendung von QuDedup den Order „latest“, welcher stets die aktuellste Sicherung wiederspiegelt.

non_dedup.PNG (Bezeichnung ohne QuDedup)

Ist das Zielsystem abgeschaltet wenn eine Version konvertiert wird (z.B. um 00:00 Uhr), so wird die Konvertierung beim nächsten Einschalten nachgeholt (das passiert bei Snapshots offensichtlich nicht, wie ich in jüngster Vergangenheit im Forum erfahren habe). Jedoch scheint es erforderlich zu sein, dass das System wenigstens am Tag der Konvertierung eingeschaltet ist; so ganz habe ich das noch nicht geblickt, siehe dazu auch das nächste Beispiel.

Wenn, wie im nachfolgenden Beispiel, der Job mehrere Tage unterbrochen wurde, weichen die Versionen vom üblichen Schema ab. In diesem Fall war der Job vom 27.06. bis einschließlich 04.07. gestoppt (Zielsystem hat wegen defektem RAM nicht mehr funktioniert und war somit abgeschaltet). Die im Screenshot markierte wöchentliche Version ist demnach nicht vom 04.07. (Sonntag/ Ende der Woche) wie es üblich wäre, sondern vom 26.06., weil dies zum Zeitpunkt der Konvertierung (Sonntag, 11.07.) die älteste tägliche Version war.

Auch die monatliche Version aus Juni fehlt, da das System am 30.06. / 01.07 (Monatswechsel) nicht eingeschaltet war.

Ebenfalls nicht verfügbar ist die wöchentliche Version vom 19.06., welche am 04.07. hätte erstellt werden sollen.

Edit: Hierbei fällt übrigens auf, dass die Konvertierung am letzten Tag der Woche oder des Monats erfolgt, und nicht wie in der oben gezeigten Tabelle an den ersten Tagen einer Woche oder eines Monats.
Die Angaben in der Tabelle stammen direkt von QNAP; es wird somit nochmal etwas unübersichtlicher, eventuell ist der Unterschied auch durch die Verwendung von QuDedup begründet.

versionen.PNG (heutiges Datum: 30.07.2021)

Ich glaube insbesondere derartige Abweichungen sowie die in der Tabelle dargestellten Überschneidungen sorgen dafür, dass man verzeweifeln könnte, wenn man sich sein versioniertes Backup anschaut, was an manchen Stellen einfach willkürlich und planlos aussieht. Ich hoffe ich konnte zumindest etwas Licht ins Dunkle bringen, obwohl sicherlich noch nicht alle Fälle und Hintergründe beleuchtet sind... und wer weiß... vielleicht habe ich ja auch irgendetwas falsch interpretiert?!

Mir zeigt es aber durchaus: So eine Versionierung ist relativ komplex und es ist kaum verwunderlich, dass hier mal etwas schief laufen kann. Daher meine ständige Empfehlung:

Ein versioniertes Backup (oder auch grundsätzlich ein Backup mit QuDedup) sollte immer nur als Ergänzung zu einer schlichten Datensicherung im Sinne von "1 zu 1 Kopien" sein, niemals aber als alleinige Sicherung dastehen.

Mal wieder ein Freitag. Mal wieder gutes Timing. Mal wieder muss ich mich noch gedulden... mal wieder sage ich trotzdem:

Cheers!