Warum wir Backups an einem Samstagmorgen testen

Samstag, 10:15 Uhr. In einer vom Produktivsystem getrennten Umgebung startet ein Server mit der Warenwirtschaft eines Kunden. Kein Mitarbeiter und kein Kunde bekommt davon etwas mit. Das Backup vom Freitagabend liefert die Daten, und wenige Minuten später erscheint der Anmeldebildschirm. Das Monitoring hält den erfolgreichen Start fest.

Der Geschäftsführer dieses Unternehmens verbringt den Vormittag mit seiner Familie. Er weiß, dass der Test läuft, weil wir das vorher gemeinsam festgelegt haben: welcher Server regelmäßig geprüft wird, in welchem Abstand, und wie der Bereitschaftsdienst reagiert, wenn bei einem echten Ausfall etwas schiefgeht.

Ein Test, der nicht für den Ernstfall gedacht ist

Ein Backup zu erstellen, ist nur der erste Schritt. Danach folgt der Teil, der bei vielen Unternehmen ausbleibt: prüfen, ob sich aus diesem Backup ein laufendes System bauen lässt. Bei manchen zeigt sich erst mitten in einer Krise, dass die Sicherung unvollständig war oder in einem Format vorliegt, das sich nicht mehr einspielen lässt. Ein Restore-Test soll das verhindern, lange bevor er gebraucht wird.

Bei diesem Kunden läuft der Test in einer Umgebung ohne Verbindung zum Produktivnetz. Die Warenwirtschaft startet dort wie an einem gewöhnlichen Morgen, mit Anmeldebildschirm und den gewohnten Prozessen im Hintergrund. Für das Unternehmen ändert sich an diesem Samstag nichts. Für uns zeigt der Test, ob die Sicherung im Ernstfall trägt, nicht erst am Tag, an dem sie gebraucht wird.

Ein Restore-Test kostet Zeit, die niemand direkt sieht. Ein Server muss bereitstehen, jemand muss die Wiederherstellung anstoßen und das Ergebnis prüfen, und der ganze Vorgang läuft am besten außerhalb der normalen Geschäftszeiten, damit er niemanden stört. Deshalb bleibt er bei vielen Unternehmen aus. Genau dieser Test zeigt, ob ein Backup im Ernstfall funktioniert.

Nicht jedes System bekommt denselben Rhythmus. Bei diesem Kunden legen wir gemeinsam fest, welcher Server monatlich getestet wird und welcher seltener drankommt, je nachdem, wie stark der Betrieb von ihm abhängt. Die Warenwirtschaft steht dabei oben auf der Liste, weil ohne sie am Montagmorgen kein Auftrag das Lager verlässt. Ein interner Dateiserver mit älteren Archiven wartet dagegen länger auf seinen nächsten Test.

Was am Montag zählt

Am Montag öffnet ein Techniker den Bericht aus dem Wochenende und kontrolliert den Ablauf Schritt für Schritt: Startzeit, Anmeldebildschirm, ob die Datenbank sauber hochgefahren ist und ob im Monitoring eine Warnung übersehen wurde. Erst danach geht die Information an den Kunden weiter. Das Ticket zeigt dem Geschäftsführer die Uhrzeit des Tests und den bestätigten Start der Anwendung.

Für ihn ist das eine Antwort auf eine Sorge, die selten laut ausgesprochen wird: ob der Hauptserver an einem echten Montag überhaupt wieder hochfährt. Ein Ticket mit Uhrzeit und bestätigtem Start lässt sich nachvollziehen, ohne dass er selbst ins System schauen muss.

Diese Antwort lässt sich nicht mit einem Satz im Vertrag festhalten. Sie entsteht erst, wenn der Test regelmäßig stattfindet, das Ergebnis dokumentiert wird und jemand am Montag hinschaut, auch wenn niemand danach fragt.

Der Satz im Protokoll

Um 10:35 Uhr fährt der Testserver wieder herunter. Im Protokoll steht ein einziger Satz: Start erfolgreich, nächster Test am 19. September. Für den Kunden bleibt dieser Samstag ein gewöhnlicher Samstag.

Bei neuen Kunden gehört dieses Gespräch zu den ersten, die wir führen: welche Systeme im Ernstfall zuerst wieder laufen müssen, wie oft ein Restore getestet wird, und wer im Bereitschaftsdienst welche Entscheidung trifft. Die Antworten landen danach in einem Kalendereintrag, den ein Techniker jeden Monat abarbeitet, egal ob der Kunde sich daran erinnert oder nicht.