[PROLOG]
Bislang war ich von etwaigen Problemen mit HBS3 immer verschont geblieben, habe aber stets im Hinterkopf behalten, dass HBS3 nicht unbedingt als zuverlässig zu bewerten ist. Aus diesem Grund habe ich mein Backup auch so aufgebaut, dass ich nicht einzig und allein von HBS3 und seiner Funktion abhängig bin und dass ich bestehende Backup Jobs, insbesondere solche mit Versionierung, problemlos weiterverwenden kann, wenn HBS3 komplett neu eingerichtet werden muss. Genau das war in diesem Fall auch die einzige Lösung.
Im Nachfolgenden beschreibe ich die Problematik, wie ich aus der Nummer rausgekommen bin und warum es sich ausgezahlt hat im Voraus entsprechende Maßnahmen für solche Fälle zu ergreifen.
Quellsystem: QTS 4.5.3. HBS3 18.0.1104
Zielsystem intern: QTS 4.5.3. HBS3 18.0.1104
Zielsystem extern: QTS 5.0.0. HBS3 18.0.1104
[DAS PROBLEM]
Mit Gründen für Probleme ist bei QNAP ja manchmal so eine Sache, diese werde ich wohl auch für diesen Fall nie erfahren. Es ist der 12.01.2021 an dem ich zufällig feststelle, dass mein externes Backupsystem nicht nach Zeitplan heruntergefahren ist. Ich loggte mich in die GUI ein und sah, dass noch ein eingehender Sync-Job lief, zumindest angeblich. Praktisch war das kaum vorstellbar, da dieser Job bereits seit 16 Stunden hätte fertig sein müssen. Ein Blick in das Quellsystem klärt auf, dass hier kein Job mehr aktiv ist. Erschreckenderweise musste ich aber auch feststellen, dass für alle 4 Jobs auf das externe System ein letzter Durchlauf am 05.01.21 ausgewiesen wird, eigentlich sollten die Jobs täglich laufen. Natürlich habe ich dem Zielsystem die Schuld daran gegeben und es neu gestartet, anschließend wollte ich die Jobs durchlaufen lassen. Das System startete wie erwartet neu, doch konnte ich die Jobs am Quellsystem nicht starten, ich bekam direkt die Meldung, dass ein Fehler in HBS aufgetreten sei.
Missmutig schaute ich mir die Backup-Jobs an, die auf mein internes Backupsystem laufen. Hier waren 4 von 5 Jobs gestoppt, es wurde nichtmal ausgewiesen, wann der Job zuletzt lief. Lediglich ein Job wies aus, dass der letzte Durchlauf am 07.01.2021 stattfand. Bis auf diese eine Ausnahme war ich also bereits eine Woche lang ohne aktuelles Backup mit HBS unterwegs. Ich ärgerte mich erstmal schwarz darüber, vor allem da es keinerlei Meldungen darüber gab, dass hier eine Abweichung besteht. Der Gedanke, dass ich für solche Fälle ein weiteres Backup mittels Snapshot-Replica, also unabhängig von HBS, laufen habe, beruhigte mich allerdings, das war erwartungsgemäß auch aktuell.
Der Versuch einen dieser Internen Backup-Jobs zu starten brachte keine Fehlermeldung hervor, allerdings machte es auch nicht den Anschein, als würde der Job laufen, es tat sich einfach nichts. Am internen Backupsystem konnte ich aber sehen, dass der Job läuft und erfolgreich beendet wurde, die Tage zuvor ist hier aber nichts eingegangen. Damit war klar, dass nicht ein Zielsystem Probleme hat, sondern das Quellsystem.
[DIE LÖSUNG DES PROBLEMS]
Das Quellsystem wurde kürzlich erst nach Zeitplan neu gestartet sodass ich diese einfache Maßnahme als Lösung des Problems ausschließen konnte. Auch das De- und Reaktivieren von HBS3 brachte keinen Erfolg, ebensowenig das Bearbeiten der Jobs. Letzter Ausweg: HBS3 de- und reinstallieren.
Dabei denkt man zunächst an jede Menge Fleißarbeit, zumindest bei 9 Jobs an zwei unterschiedliche Ziele. Das ist jedoch gar nicht zwingend das große Problem, viel problematischer sind versionierte Backups, da diese oftmals nicht weitergeführt werden können, nachdem HBS3 neu eingerichtet wurde. Ich habe es jedenfalls noch nie sauber hinbekommen und musste dazu stets die bestehende Versionierung verwerfen und einen neuen Job mit neuer Versionierung anlegen, Crazyhorse hat das aber schonmal irgendwie hinbekommen.
Eine Versionierung haben bei mir nur die Jobs zum internen Backupsystem, welche ich einst extra für solche Fälle neu angelegt habe, und zwar mit QuDedup, was einem ermöglicht die Jobs auf einfache Weise fortzuführen, sei es nach Neuinstallation von HBS auf dem bestehenden System oder auf einem anderen/ neuen System. Hierzu brauchte ich mich lediglich der Funktion „Backupjob neu verlinken“ bedienen, die entsprechende Containerdatei am Zielsystem wählen und dem Job einen Namen geben, alle anderen Einstellungen wurden direkt übernommen und nach nichtmal einer Minute konnte der erste Job wieder durchstarten, was auch problemlos lief, sodass die ersten 4 Jobs schnell wieder angelegt und durchgeführt waren.
Etwas problematischer war der Backup-Job (ohne Versionierung und ohne QuDedup) meiner VMs, diesen musste ich komplett neu anlegen und auch komplett durchlaufen lassen, die bestehenden Daten hat HBS3 einfach nicht zugelassen, bzw. hat sie nach etwas Kopiererei am Zielsystem trotzdem komplett überschrieben, obwohl nicht überall Änderungen stattgefunden hatten.
Die Sync-Jobs mussten mit etwas Fließarbeit ebenfalls komplett neu angelegt werden, glücklicherweise gibt es hierbei aber keine Probleme mit vorhandenen Zieldateien wie bei einem Backup-Job. Das war also auch recht fix erledigt, zuvor hatte ich mir Screenshots von den bestehenden Jobs angefertigt um die Neueinrichtung zu vereinfachen.
[FAZIT]
Eine Woche lang blieb es unbemerkt, dass meine Backups an zwei Zielsysteme nicht funktionieren und demnach nicht auf aktuellem Stand sind. Ich bin heilfroh, dass ich noch ein drittes Backupsystem habe, bei dem Backups unabhängig von HBS3 abgelegt werden. Sicherlich wäre es im aktuellen Fall nicht dazu gekommen, dass ich davon wirklich Gebrauch hätte machen müssen, schließlich ist meinem Quellsystem ja nichts passiert, aber das hätte auch anders laufen können… man stelle sich vor, dass ich die Fehlfunktion nicht zufällig bemerkt hätte, nur weil ein Backupsystem zu einem unüblichen Zeitpunkt eingeschaltet war, denn mehr Hinweise gab es zunächst nicht, und wer prüft schon ständig seine HBS Jobs, wenn es keinen offensichtlichen Anlass gibt?
Auch bin ich heilfroh, dass ich vor einem Jahr auf QuDedup gewechselt habe, um die Versionierung auf anderen Systemen/ mit neu installiertem HBS weiter verwenden zu können, früher musste ich einen parallelen Datenbestand führen, um die Versionierung beibehalten zu können, das ist dank der Option „Backup Job neu verlinken“ mit QuDedup nun Geschichte und erleichtert die Wiederherstellung von bestehenden Jobs doch extrem.
Wie es zu der Fehlfunktion kam? Tja, keine Ahnung, darauf gibt es keinerlei Hinweise in den Logs. Keine Updates, keine Änderungen, allerdings hatte ich in an dem Tag kurzzeitig mein Backup-VPN lahmgelegt, über das die Sicherung an das externe NAS erfolgt. Dabei sind die Jobs einmalig und zu Recht mit einem Fehler (Timeout) beendet wurden, seither ist kein Job mehr durchgelaufen. Besonders fragwürdig ist, warum dann auch jene Jobs nicht mehr funktionierten, die gar nichts mit dem VPN bzw. dem externen Zielsystem zu tun haben. Auch ist nicht einleuchtend, warum einer der Jobs auf das interne Zielsystem zwei Tage länger funktionsfähig war als die anderen.
Am Ende des Tages wird eine Sache deutlich:
Man darf sich nicht nur auf ein einziges Backup bzw. Backupsystem verlassen, das ist klar, aber man darf sich auch nicht nur auf eine einzige Applikation verlassen, die das Backup durchführt!
Kurios und unverständlich was da mal wieder passiert ist, um das zu verstehen muss ich wohl meine Sinne mit Hilfsmitteln erweitern… cheers!
Kommentare 6
subitus
Ich überwache jedes Freigabelaufwerk / Ordner mittels Hashdateien und vergleiche Quell- und Zielsysteme regelmäßig (via Cron-Jobs getriggerte Skripte. Wenn (einstellbare) Aktualisierungsintervalle ausbleiben, wird via Telegram-Bot und E-Mail eine Warnung an mich selbst verschickt Ein weiteres Skript testet die Wirksamkeit der Überwachung.
tgsbn
"Es ist der 12.01.2021 ..."
Du meinst nicht zufällig hier und im weiteren 2022?
tiermutter Autor
Wahrscheinlich schon... Noch nicht umgewöhnt
Barungar
Ein gutes Backup ist nur ein überwachtes Backup. Aber viel wichtiger als das Backup ist das Restore.
Sehr oft habe ich es schon erlebt, das zwar fleissig Backups gemacht wurden, die sogar kontrolliert wurden.
Aber es wurde mal nie ein Restore probiert, der dann natürlich in der kritischen Lage nicht ging.
uweklatt
In dem Zusammenhang kann man dann auch zu filebasierten Backups raten, bei denen die Ordner und Dateistruktur erhalten bleibt. Dinge wie QuDedup mögen Platz sparen, Daten sind daraus im Notfall leider nicht so schnell und einfach zu rekonstruieren.
tiermutter Autor
Sehe ich auch so... Wenigstens ein Backup muss direkt lesbar und wiederherstellbar sein, ohne Schnickschnack der schiefgehen kann und ohne irgendwelche Abhängigkeiten.
Bei mir spart Dedup noch nichtmal wirklich Platz, wenn überhaupt nur marginal, aber dafür dauert so ein Job sehr lange
Meine Intention das für eins der Backups zu verwenden ist aber auch ausschließlich dass ich die Jobs damit neu verlinken kann.
Zur Überwachung von Backups gehört sicherlich mehr als "wenn etwas nicht klappt werde ich ja per Mail informiert". In diesem Fall wird HBS ja von QTS überwacht, aber wenn das nicht funktioniert... Da muss man dann wohl schon sowas anstellen wie im ersten Kommentar beschrieben