Dein Backup meldet Erfolg: woher weisst du, dass das stimmt?
Kurz gesagt
Eine Erfolgsmeldung sagt, dass ein Job gelaufen ist, nicht dass die Daten brauchbar sind. Backups hören leise auf, und die Meldung bleibt grün oder kommt gar nicht mehr. Zwei Prüfungen lösen das meiste davon: Der Job meldet sich selbst, wenn er fertig ist, und du behältst das Alter des letzten gültigen Backups im Blick.
Fast jedes Unternehmen hat Backups. Weniger haben eine Kopie, die sie morgen früh wieder zum Laufen bringen würde. Die Lücke liegt selten an der Backup-Software: Sie liegt daran, dass ein Backup, das aufhört zu funktionieren, das leise tut — und leise sieht aus wie in Ordnung.
Was beweist eine Erfolgsmeldung nicht?
Eine Erfolgsmeldung beweist, dass ein Job gelaufen ist, und sonst nichts. Sie beweist nicht, dass die Dateien vollständig sind, dass am Ziel Platz war, dass der Schlüssel zur Verschlüsselung verfügbar ist oder dass irgendjemand daraus wiederherstellen könnte.
Unter IT-Fachleuten sind die Geschichten fast austauschbar, und weh tun die Zeiträume: ein Monat ohne gültiges Backup, weil die Warnungen an das Postfach einer Person gingen, die das Unternehmen verlassen hatte; ein Satz Backups, der sich als seit rund vier Monaten beschädigt herausstellte, entdeckt beim Wiederherstellen; Bänder, die leer waren, weil der Job nie wirklich auf Ausführung gestellt worden war.
Keines dieser Systeme hat um Hilfe geschrien. Jedes sah normal aus, bis jemand die Daten brauchte.
Welche zwei Prüfungen fangen das meiste ab?
Diese zwei: Der Job meldet sich selbst, wenn er fertig ist, und du behältst das Alter des letzten gültigen Backups im Blick.
Erstens: Lass den Job sprechen. Lass ihn am Ende deines Backup-Skripts eine URL aufrufen. Trifft der Aufruf nicht innerhalb des erwarteten Zeitfensters ein, bekommst du eine Warnung. Diese eine Änderung dreht das Problem um: Du bist nicht mehr darauf angewiesen, dass ein Fehler gemeldet wird, du merkst die Stille. Sie fängt den Job ab, der nie startete, die Maschine, die aus war, den Dienst, der abstürzte, das Skript, das auf halbem Weg starb.
Zweitens: Behalte eine Zahl im Blick. Lass einen kleinen Befehl etwas ausgeben, das dich interessiert — Stunden seit dem letzten erfolgreichen Backup oder die Grösse der neuesten Datei — und behandle diese Zahl als überwachten Wert mit einem Schwellenwert. Ein Job kann durchlaufen und nichts schreiben; eine Zahl fängt das ab, eine grüne Meldung nicht.
Beides funktioniert auf jedem System, das einen Befehl ausführen oder einen HTTP-Aufruf machen kann, und das schliesst fast jedes Backup-Produkt, jedes Skript und jede Zeitsteuerung ein, die du ohnehin schon einsetzt.
Warum rettet dich das NAS hier nicht?
Weil es von sich aus keine Warnung senden kann und über die Backup-Jobs ohnehin nichts preisgibt. Synology schreibt im eigenen MIB-Handbuch, dass DSM keine SNMP-Traps unterstützt: Das Gerät kann von sich aus keine Warnung senden. Man kann es fragen — Zustand der Festplatten, RAID-Status inklusive degraded und crashed, freier Speicherplatz — aber nur von aussen, von etwas, das regelmässig nachfragt.
Und das Ergebnis der Backup-Jobs selbst wird überhaupt nicht preisgegeben. «Das NAS sagt es mir schon» hat also zwei Probleme: Es sagt es dir nur, wenn es gefragt wird, und über den Job sagt es dir nie etwas.
Was du diese Woche tun kannst
- Füge die Meldezeile am Ende des Backup-Jobs ein und lege das erwartete Zeitfenster fest.
- Gib eine Zahl aus — Stunden seit dem letzten gültigen Backup — und behalte sie im Blick.
- Überwache das Ziel: freien Speicherplatz und Zustand der Festplatten, damit du von einem vollen Datenträger erfährst, bevor der Job scheitert.
- Buche einen Wiederherstellungstest. Trag ihn mit einem Namen in den Kalender ein, nicht als «irgendjemand sollte mal».
Ein Backup, das du nie wiederhergestellt hast, ist eine Hoffnung. Ein Backup, das dir jeden Morgen sagt, dass es noch da ist und wie alt es ist, ist ein System.
Was wir dir nicht sagen können
- Wir können das Ergebnis eines Backup-Jobs in einem NAS nicht auslesen: Die verbreitete NAS-Software für Privat- und Geschäftskunden gibt es über das Netzwerk nicht preis, und wir tun nicht so, als wäre es anders.
- Wir können dir nicht sagen, dass sich ein Backup wiederherstellen lässt: Das beweist nur ein Wiederherstellungstest.
- Wir sehen nur, was dein System uns mitteilt: einen Job, der sich meldet, eine Zahl, die dein Skript ausgibt, oder ein Gerät, das antwortet.
Fragen, die wirklich gestellt werden
Warum scheitern Backups leise, statt einen Fehler zu melden?
Weil der Teil, der den Fehler melden würde, oft genau der Teil ist, der aufgehört hat. Ein geplanter Job, der nie startet, sendet nichts. Ein Dienst, der abgestürzt ist, sendet nichts. Ein Postfach, das die Warnung abweist, verschluckt sie. Stille sieht genau aus wie Erfolg, und darum laufen so viele Ausfälle monatelang.
Was ist die einfachste Prüfung, die wirklich funktioniert?
Lass den Backup-Job sich melden, wenn er fertig ist, und schlag Alarm, wenn diese Meldung nicht rechtzeitig eintrifft. Das dreht die Logik um: Statt auf schlechte Nachrichten zu warten, die vielleicht nie gesendet werden, merkst du die Stille. Es braucht eine einzige Zeile am Ende des bestehenden Skripts.
Was sollte ich ausser dem Job selbst überwachen?
Das Alter des letzten gültigen Backups, als Zahl: Stunden seit dem letzten erfolgreichen Durchlauf oder die Grösse der neuesten Backup-Datei. Ein Job kann fertig werden und eine leere Datei erzeugen. Eine Zahl, die du dir jeden Tag anschaust, fängt das ab; eine grüne Meldung nicht.
Wie oft sollte eine Wiederherstellung getestet werden?
Mindestens zweimal im Jahr, auf einer Maschine, die nicht die produktive ist, mit einer Stoppuhr. Du lernst dabei zwei Dinge, die dir keine Meldung sagt: ob die Daten zurückkommen und wie lange der Betrieb stillstehen würde. Schreib beides auf.