Der IT-Leiter öffnet am Morgen das Dashboard. Alles grün. Kein Alarm, keine Fehlermeldung, keine unerwartete E-Mail. Irgendwo im Hintergrund läuft seit sechs Monaten ein Cron-Job, der planmässig um 02:00 Uhr startet, Dateien erzeugt, Logs schreibt — und dabei ausschliesslich Tabellenköpfe sichert. Keine Daten. Der Job schliesst ab. Status: Completed.
Ein Backup Monitoring, das nur auf Job-Status prüft, sieht darin kein Problem. Das ist das Problem.
Ein Backup, das niemand überwacht, ist kein Backup. Es ist eine Hoffnung: die Hoffnung, dass es funktioniert, wenn man es braucht. Wer dieses Backup Monitoring nie ernsthaft betreibt, erfährt erst im Ernstfall was er wirklich hat — zum schlechtestmöglichen Zeitpunkt.
Das beschriebene Szenario ist kein Randfall. Nach einem MySQL-Versionsupdate änderten sich bei einer E-Commerce-Plattform die Dateiberechtigungen des Datenbankdump-Jobs. Der Job lief weiter. Täglich, zuverlässig, ohne Fehlermeldung. Über 150.000 Kundenkonten, sechs Monate Bestelldaten, Zahlungsaufzeichnungen, Inventaränderungen — alles weg. Geschätzter Schaden: über 200.000 Dollar. Ursache: Das Monitoring prüfte ob der Job abgeschlossen wurde. Nicht ob der Inhalt verwertbar war.
Vier strukturelle Ursachen führen dazu, dass Backup-Fehler in der Praxis so lange unbemerkt bleiben:
Stilles Scheitern ohne Fehlermeldung. Backup-Systeme melden aktive Fehler — aber kein System meldet von sich aus, dass eine Sicherung inhaltlich leer ist, dass ein Datenbankdump nur Strukturdaten enthält oder dass ein Backup-Volume sich seit Wochen nicht mehr verändert. Kein Fehler bedeutet nicht: alles in Ordnung.
Alert Fatigue. In grösseren Umgebungen versinken Backup-Meldungen im Rauschen. Teams, die täglich Dutzende unkritische Alerts erhalten, entwickeln eine Immunität dagegen — ein Phänomen, das aus der Forschung zu medizinischen Geräten bekannt ist und sich direkt auf IT-Monitoring überträgt. Wenn tatsächlich ein kritischer Alert kommt, geht er unter.
Fehlende Ownership. In vielen KMU ist Backup eine Nebenaufgabe. Kein dediziertes Monitoring, keine definierten Eskalationspfade, kein dokumentierter Überblick darüber, was, wo und wann gesichert wird. Wer verantwortlich ist für das Backup, ist nicht zwingend verantwortlich für das Monitoring.
Cloud-Sync ist kein Backup. OneDrive, Dropbox, Google Drive — all diese Dienste synchronisieren den aktuellen Zustand. Wer eine Datei versehentlich überschreibt oder löscht, bekommt diese Änderung in die Cloud synchronisiert. Das Original ist weg. Das ist Synchronisation. Nicht Backup.
Gutes Backup Monitoring fragt nicht nur: Wurde der Job abgeschlossen? Es fragt: Was hat der Job gesichert, und kann es wiederhergestellt werden? Das sind grundlegend verschiedene Fragen.
Sechs Punkte, die ein ernsthaftes Monitoring abdecken muss:
1. Job-Abschluss und Inhalt. Ob der Job lief, ist die einfachste Prüfung — und die unzuverlässigste. Entscheidend ist, ob die gesicherte Datenmenge plausibel ist. Ein Backup, das plötzlich zehn Prozent kleiner ist als der Vortag ohne nachvollziehbaren Grund, ist ein Warnsignal.
2. Absence Alerting. Ein Job, der nicht startet, erzeugt keine Fehlermeldung. Er erzeugt Stille. Das Monitoring muss erkennen, wenn ein erwartetes Backup ausbleibt — nicht erst dann reagieren, wenn etwas aktiv fehlschlägt.
3. Backup-Grössentrend. Plötzlich kleinere Backups können auf fehlende Datenbereiche hinweisen. Plötzlich grössere Backups auf Komprimierungsprobleme oder ungeplanten Datenzuwachs. Der Trend über Zeit zeigt ausserdem, ob die Speicherkapazität ausreicht.
4. Speicherkapazität und Schwellenwerte. Wenn das Backup-Ziel voll läuft, schlägt der nächste Job fehl — oder überschreibt ältere Sicherungen. Ein Frühwarnsystem, das bei 70 oder 80 Prozent Belegung eine Meldung auslöst, verhindert das.
5. RPO-Compliance. Das Recovery Point Objective (RPO) definiert, wie viel Datenverlust ein Unternehmen tolerieren kann — also wie alt das letzte Backup maximal sein darf. Das Monitoring muss prüfen, ob das zuletzt erfolgreiche Backup innerhalb dieses Zeitfensters liegt.
6. Regelmässige Restore-Tests. Das ist der einzige Nachweis, der zählt. Ein Backup, das nie wiederhergestellt wurde, ist eine Annahme, kein Fakt. Monatliche Stichproben-Restores sowie quartalsweise vollständige Disaster-Recovery-Übungen sind der Mindeststandard.
GitLab verlor 2017 rund 300 GB Produktionsdaten durch einen versehentlich gelöschten Verzeichnisbaum. Fünf Backup-Mechanismen waren vorhanden. Keiner funktionierte wie erwartet. Nur 4,5 GB konnten gerettet werden. Das ist keine Geschichte über fehlende Backups — sondern über fehlendes Monitoring der Backup-Funktionsfähigkeit.
Ein Alerting-System, das tatsächlich hilft, braucht zentralisierte Alerts statt einzelner Meldungen pro System, definierte Eskalationspfade, verschiedene Kanäle für verschiedene Kritikalitätsstufen, regelmässige Heartbeat-Tests und Runbooks mit direkten Verweisen auf Lösungsanleitungen.
Das Gegenteil davon ist ein Posteingang voller Backup-Meldungen, die niemand mehr öffnet. Das ist keine Überwachung. Das ist Alibi.
Das Muster ist bekannt, gut belegt und hartnäckig: Unternehmen sind überzeugt, dass ihre Backups funktionieren. Bis sie es prüfen.
Branchenerhebungen zeigen: Während nahezu alle IT-Entscheider angeben, eine Backup-Strategie zu haben, konnten in Befragungen bis zu 26 % bei einem tatsächlichen Restore nicht alle Daten zurückgewinnen. Laut einer Backblaze-Erhebung von 2024 behaupten 84 % der Befragten, ihre wichtigsten Dateien gesichert zu haben — aber nur 15 % sind sich dessen wirklich sicher.
Das ist kein Einzelfall. Das ist ein Strukturproblem.
Die häufigsten Gegenargumente folgen dem gleichen Muster: „Dafür haben wir einen IT-Dienstleister." Gut. Aber wann haben Sie zuletzt einen schriftlichen Monitoring-Report erhalten? Wer darauf keine Antwort hat, hat keine Transparenz. Und wer keine Transparenz hat, verlässt sich auf Hoffnung.
Backup Monitoring ist kein Add-on zum Backup. Es ist der Nachweis, dass ein Backup existiert und wiederhergestellt werden kann. Ohne diesen Nachweis hat man kein Backup — man hat einen Job, der nachts läuft und Dateien erzeugt.
Ein grünes Häkchen im Dashboard beweist nichts ausser dass ein Job abgeschlossen wurde. Inhalt, Grösse und Vollständigkeit müssen separat geprüft werden.
Absence Alerting und regelmässige Restore-Tests sind kein Aufwand, der sich sparen lässt. Sie sind der einzige Weg, Fehler vor dem Ernstfall zu entdecken — nicht während.
Wer nicht überwacht, weiss nicht. Wer nicht testet, glaubt nur.
Für Unternehmen, die diesen Aufwand nicht intern stemmen wollen oder können: Backup ONE übernimmt das Backup-Management vollständig — inklusive proaktivem Monitoring, definierter Alert-Eskalation und regelmässiger Restore-Verifikation. Ohne dass jemand im Unternehmen jeden Morgen das Dashboard öffnen muss.
Das sind weitere Beiträge, die Sie interessieren könnten.
Zur Blogübersicht