QuDedup: Backup Job neu verlinken - Ein Ritt ins Verderben

[PROLOG]

Immer wieder wenn es um Backup mit HBS3 geht und die Funktion „QuDedup“ im Raum steht, erwähne ich dessen für mich entscheidendsten Vorteil, nämlich die Möglichkeit Backup-Jobs neu zu verlinken. Interessanterweise lese ich ansonsten jedoch so ziemlich gar nichts davon, als ob es niemanden gibt, der diese Möglichkeit so sehr schätzt wie ich… also will ich doch mal ein paar Worte mehr darüber verlieren.

Eigentlich sollte dies ein kleines How-To aus der Praxis werden, die Umstände jedoch haben dafür gesorgt, dass dieser Artikel eher ein kleiner Bericht mit einer ernstzunehmenden Warnung wird.

Für mein internes Backup NAS (TS-251+) steht eine Kapazitätserweiterung an. Das Gerät ist mit einer 3TB und einer 2TB Disk ausgestattet, die 2TB Disk soll einer 4TB Disk weichen. Eingerichtet sind diese, fast selbstredend, als Single Disks. Beim Tausch würde ich zunächst also alle Daten verlieren.

Bei einem Backupsystem (es existieren ja mehrere Backups auch auf anderen Systemen) ist dies meist verkraftbar und man sichert die Daten nach dem Wechsel der Disk einfach neu. Ich habe bei diesem Backup allerdings die Versionierung aktiv und möchte diese nicht verlieren und von Null anfangen, also müssen alle Daten erhalten bleiben. Die Problematik die sich dabei oft auftut ist, dass HBS3 bei Backups Jobs mit Versionierung es nicht ohne Weiteres akzeptiert, wenn die Pfade am Backup-Ziel geändert werden. Meist bleibt dann nur einen neuen Job zu erstellen und von vorne anzufangen. Und genau hier kommt die genannte Funktion von QuDedup ins Spiel! Warum - das wird sich der ein oder andere clevere Fuchs nun zu Recht fragen - erläutere ich im Abschnitt zur Ausgangslage.

Eigentlich wollte ich für diesen HDD Wechsel einen Artikel über das Klonen und anschließende Erweitern von Disks in einem QNAP schreiben, doch leider ist das etwas zu heikel für ein produktives System, schließlich muss ich zunächst erst einiges ausprobieren. Wenn (falls) ich bei der Sache soweit bin, werde ich selbstredend berichten.

[QUDEDUP - BACKUP JOB NEU VERLINKEN]

Kurz zum Hintergrund dieser Funktion…

QuDedup sichert anders als normale Backup Jobs nicht in einfache Ordner und Dateien, sondern in einen Container.

Wird eins der involvierten Systeme neu aufgesetzt, besteht ohne QuDedup die Gefahr, dass man die bestehenden Backups nicht fortführen kann und eben von Null beginnen muss, was zunächst Zeit erfordert, damit alle Daten übertragen werden, vor allem aber bei Backups mit Versionierung zu Problemen führt, da die Jobs nicht korrekt fortgeführt werden können. *

Mit QuDedup wurde daher die Funktion des Verlinkens eingeführt, mit der man HBS3 am Quell-System ganz einfach mit einem bestehenden QuDedup Container verbinden kann, sodass das bestehende Backup auch systemübergreifend so fortgeführt wird, als wäre nichts gewesen.

* In der Vergangenheit habe ich schon öfter das Quell- oder Zielsystem gewechselt und bin stets in Probleme mit der Versionierung gelaufen, wenn ich diese mit normalen Backup-Jobs fortführen wollte. Das ist mittlerweile schon einige Zeit her, daher kann es selbstredend sein, dass man hierbei mittlerweile keine Probleme mehr bekommt. Ich gehe hier einfach auf Nummer sicher und verwende die dafür vorgesehene Funktion.

[DIE AUSGANGSLAGE]

Ich will also eine 2TB Disk durch eine 4TB Disk ersetzen. Auf beide Disks laufen insgesamt 5 Backup Jobs, einer davon zwar ohne QuDedup, aber auch ohne Versionierung.

Die kleine Krux dabei: auf der zu ersetzenden 2TB Disk ist bei aktueller Verteilung der Backups vorerst noch ausreichend Kapazität vorhanden, allerdings nicht bei der 3TB Disk, sodass ich die einzelnen Backups später neu auf die Disks verteilen muss. Wäre dies nicht der Fall, würde es vermutlich auch ohne QuDedup keine Probleme mit der späteren Fortführung der Backups geben, da die Pfade identisch bleiben würden.

In diesem Fall werde ich später somit ein Backup-Job von Disk 2 auf die neue Disk 1 verlagern und (wahrscheinlich) alle anderen Backups auf Disk 2 platzieren. Lediglich ein Backup wird an seinem Platz bleiben.

[DIE DURCHFÜHRUNG]

Hinweis: Aufgrund des Ergebnisses, welches sich nach der Durchführung ergeben hat, macht es wenig Sinn diesen Abschnitt zu lesen. Aber er war ja schon fertig geschrieben und eventuell hilft er die Zusammenhänge besser zu verstehen.

Vorbereitungen

Allem voran gilt es natürlich erstmal ein Backup vom Backup zu machen, zumindest die QuDedup Container muss ich sichern, das Backup meiner VMs hingegen lasse ich neu erstellen, dies ist ohne Versionierung und die meisten Daten müssen ohnehin bei jedem Backup neu übertragen werden.

Das Backup der Container erfolgt auf meinem Haupt-NAS, über SMB geht das recht fix, das muss ich aber erstmal aktivieren, denn bei Backupsystemen habe ich derartige Dienste nicht aktiv.

Der nächste Backup Durchlauf ist erst in 9 Stunden, mitten in der Nacht, dennoch deaktiviere ich alle Jobs, falls ich nicht rechtzeitig fertig werde.

HBS3 befindet sich auf der zu wechselnden Disk, die App verschiebe ich temporär auf die andere Disk. Eigentlich unnötig, denn hier muss nicht wirklich viel eingestellt werden. Die anderen Apps sind irrelevant.

Im nächsten Schritt möchte ich den Pool und die Disk eigentlich „sicher trennen“, damit alle Daten erhalten bleiben und ich die Disk später bei Bedarf nochmal in dem NAS nutzen kann.

Fehlanzeige… Man kann einen Pool der das Systemvolume enthält nicht sicher trennen. Dämliches OS, dann fliegt die Disk halt auf die harte Tour raus: Ganz einfach ohne Voranmeldung im NAS. Ärgert mich trotzdem! Die Disk scheint noch aus alten Zeiten zu stammen, sie ist fein säuberlich mit der Bay-Nr. beschriftet, in der sie damals in meinem Haupt NAS eingesetzt wurde.

Nachdem die Disk raus ist, entferne ich den Pool samt Volumes aus der Konfiguration. Dann erstelle ich den neuen Pool und sehe zum ersten Mal den neuen (?) Wizard für die Erstellung. Keine Ahnung wie lange es diesen schon gibt, hier ist QTS 5.1.2 in Verwendung.

Danach folgt die Erstellung der Volumes, ich nehme wie immer Thin. Auf ein statisches Volume habe ich hier verzichtet, falls ich doch mal Snapshot-Replika auf das NAS schreiben möchte.

Mal wieder lästig: Es dauert ewig die Standardfreigaben zu erstellen und so lange kann ich nicht mit der Erstellung des anderen Volumes fortfahren…

Ist das endlich geschafft, wird die Backup-Freigabe erstellt und schon können die gesicherten Container wieder zurückgespielt werden.

Halt, nein… zunächst verschiebe ich die noch vorhandenen Container auf dem NAS nach meinen Wünschen auf die neue Disk, schließlich soll die Verteilung und Nutzung der Kapazität sinnvoll sein. Ich habe mich dazu entschieden nur den großen Container meiner Medien auf die neue Disk zu verschieben, alle anderen kommen auf die alte Disk, das kann ich bei Bedarf auch später anpassen.

Fast 8 Stunden soll das Verschieben in der Filestation dauern.

Parallel verschiebe ich HBS3 wieder auf das Systemvolume, so wie ich es gerne habe, dann lasse ich das NAS erstmal in Ruhe und hoffe dass es nicht so lange dauert wie prophezeit wurde.

Schnell wird aber deutlich, dass dieser Kopiervorgang heute nicht mehr abgeschlossen wird. Die verbleibende Zeit des heutigen Tages dürfte aber reichen um die gesicherten Container zurück auf das NAS zu kopieren, die dafür erforderliche Kapazität ist bereits frei geworden.

Die Backups vom Backup sind nach knapp zwei Stunden am Bestimmungsort angelangt, sodass es mit dem Verlinken der Container losgehen kann.

Backup Jobs neu verlinken
Über das Menü zur Erstellung eines neuen Jobs wird die Option des Verlinkens gewählt.

200_relink1.PNG

Im nächsten Fenster wird das Zielsystem ausgewählt.

201_relink2.PNG

Nun kann man das Ziel durchsuchen und wählt den entsprechenden Container aus.

202_relink3.PNG

Es erfolgt eine Warnung die besagt, dass bestehende Jobs auf diesen Container keinen Zugriff mehr haben.

Dies ist von Interesse, wenn der Container z.B. von einem anderen System erstellt wurde. Die Warnung wird bestätigt, andernfalls kann mit „Nein“ noch abgebrochen werden.

203_relink_warn.PNG

Im darauffolgenden Fenster ist nun die einzig erforderliche Einstellung zu tätigen:

Dem Job muss ein Name gegeben werden. In meinem Fall verwende ich denselben wie bisher, der Name ist aber frei wählbar.

204_relink.PNG

Die Einstellungen des alten Jobs wurden komplett übernommen, sodass man einfach immer auf „Weiter“ klicken kann, bis die Erstellung abgeschlossen ist.

Bei Bedarf kann man natürlich alles anpassen.

205_relink.PNG

[UNERWARTETE RESULTATE]

Anschließend kann dann auch schon der nächste Durchlauf gestartet werden, doch zu meiner Verwunderung wird der erste Durchlauf nach dem Verlinken so behandelt, als wäre es tatsächlich der erste Durchlauf für diesen Container: Die kompletten Daten werden übertragen und laut Ressourcenmonitor auch auf das Ziel geschrieben, zumindest für die beiden Jobs, dessen Container ich sichern und zurückspielen musste. Bei dem Job, bei dem der Container nur NAS-intern verschoben wurde, tritt dieses Verhalten nicht auf. Merkwürdig.

Zumindest merkwürdig genug, um das anschließende Resultat mit ganz besonderem Augenmerk zu überprüfen. Ich mounte die Container auf dem Backupsystem also in der Filestation um sie durchsuchen zu können und… Weitere Rätsel tun sich mir auf, nachdem ich mir die Backupdaten nach diesem Durchlauf angeschaut habe, denn diese enthalten alle Versionen, die bis zu eben diesem Durchlauf existierten, nicht aber die Version, die soeben hätte neu erstellt werden müssen. Dies wirft nun auch die Frage auf, was bei diesem ersten „Pseudo-Durchlauf“ nach dem Verlinken denn genau passiert ist. Informationen die dieses Verhalten erklären könnten finde ich nicht.

Es wurden zwar keine Daten an der Quelle verändert, aber dennoch müsste ein Ordner für die neue Version existieren. Noch kurioser wird es, nachdem ich mir alle drei neu verlinkten Container mit dem QuDedup extract Tool anschaue, zuvor habe ich neue Dateien zu den Quelldaten hinzugefügt und den Job nochmals gestartet:

Bei dem Job, wo nach dem Verlinken augenscheinlich nicht alles komplett übertragen wurde, ist keine neue Version enthalten, ebenso wenig bei einem der beiden, der komplett übertragen wurde.

Bei einem der komplett übertragenen Jobs sind nur die letzten beiden Versionen nach dem Verlinken enthalten, nicht aber die bisherige Versionierung; in der Filestation wird mir jedoch genau das Gegenteil angezeigt.

Von den hinzugefügten oder geänderten Daten fehlt also jede Spur, kurz gesagt: Das Backup funktioniert nicht mehr, auch wenn HBS3 etwas anderes ausweist!

Eine Konsistenzprüfung wird ebenfalls fehlerfrei abgeschlossen. Hinzu kommt, dass für einen Job auch die Versionierung abhandengekommen ist.

Einzig der Job, der nicht angetastet wurde, funktioniert weiterhin wie erwartet.

[HBS3, QUDEDUP UND QNAP - FAZIT]

Das ist alles andere als erwartungsgemäß gelaufen. HBS3 zeigt sich erneut nicht nur als unzuverlässiges Tool, sondern auch als gefährliches Tool! Denn erneut weist mir HBS3 fehlerfrei abgeschlossene Backup-Jobs aus, obwohl tatsächlich gar keine Daten mehr gesichert werden. Davon hatte ich zuletzt hier berichtet. Ein fatales Ergebnis, wenn man bedenkt, welche Konsequenzen das haben kann!

Der Hauptübeltäter scheint in beiden Fällen jedoch QuDedup sein, also die Funktion, die ich ausschließlich wegen der Möglichkeit des neu Verlinkens nutze, um bestehende Versionierungen in bestimmten Situationen beibehalten zu können. Die Tatsache, dass QuDedup extrem fehleranfällig und langsam ist, und man ob des Containerformats nicht ohne weiteres an die Backupdaten kommt, macht diese Funktion nicht nur relativ unnütz, sondern auch gefährlich. Die Deduplikation lasse ich dabei mal außer Acht, denn diese hat nur in wenigen Fällen eine spürbare Auswirkung. Oft genug wurde und wird im Forum davon abgeraten, diese Funktion zu verwenden. Dies ist nun ein erneuter Beweis dafür, dass diese Aussagen absolut tragbar sind.

QNAP stellt seine Unzuverlässigkeit erneut auf tragische Weise unter Beweis und bewegt sich mittlerweile auf sehr, sehr dünnem Eis. Für mein versioniertes Backup brauche ich nun einen neuen Plan, ob ich QNAP dafür nochmal in Betracht ziehe, ist momentan unklar. Da ich auf der vorhandenen Hardware (TS-251+) aber weder OMV noch TrueNAS ordentlich betreiben kann, werde ich wohl bei QTS bleiben, die Versionierung überlasse ich aber zumindest nicht HBS3. Möglicherweise werde ich auch gänzlich auf das Gerät verzichten und die Versionierung auf einem anderen Gerät umsetzen.

[EPILOG]

Das Projekt war ein absoluter Fail, bei dem ich nun zumindest teilweise meine Versionierung auf immer und ewig verloren habe. Für manche Jobs ist diese zwar erhalten geblieben, doch traue ich dieser nun nicht mehr über den Weg. Gut, dass ich noch eine weitere Versionierung mittels Snapshot Replika habe, auch wenn die nicht ansatzweise so weit zurück reicht.

Manchmal ist der erste Eindruck wohl doch der einzig richtige, denn sowas hatte ich schon einst erahnt, als die Funktion des Verlinkens angekündigt wurde:

Zitat von Tiermutter

Soll also heißen dass ich zukünftig auf eine Software, in dem Fall von QNAP, angewiesen bin, um meine Backups in jedem Fall, also auch ohne QNAP NAS verwenden zu können?

Finde ich sehr gruselig (so wie ich die Anwendung von QuDedup längst schon gruselig finde).

Damals wurde mir seitens QNAP übrigens zugesagt, dass das neu Verlinken „demnächst“ auch ohne QuDedup möglich sei, dazu hatte ich ein Feature Request eingereicht, zu dem ich recht schnell die Rückmeldung erhielt, dass dies bereits in Arbeit sei. Geschenkt!

Früher hätte ich den Sachverhalt dem Support gemeldet, aber ich weiß mittlerweile nur zu gut, wie dies zumeist ausgeht und ich bin es leid, ohne Aussicht auf Erfolg zu versuchen die Sachen anderer zu verbessern und meine Zeit dafür zu opfern immer als Versuchskaninchen herhalten zu müssen.

Sämtliche Jobs mit QuDedup sind nun gestoppt und werden gelöscht, sobald ich einen neuen Plan habe. Über 12 Monate Versionierung einfach ausradiert, hoffentlich komme ich nicht in die Situation, dass ich davon etwas wiederherstellen müsste. Für mich würde ich nun gerne die letzten aufregenden und ebenso traurigen 12 Stunden ausradieren… ich weiß auch wie das geht… cheers!