Backups, die im Ernstfall halten: Warum erfolgreiche Sicherungen trügen können

Es gibt einen Satz, der in der IT teuer werden kann: „Unsere Backups laufen jede Nacht durch." Das stimmt meistens sogar. Trotzdem stehen Unternehmen im Ernstfall vor einer Sicherung, aus der sich nicht das wiederherstellen lässt, was sie brauchen. Der Grund ist fast nie ein lautes Scheitern. Es ist ein stiller Fehler, der monatelang unbemerkt bleibt, weil jede einzelne Sicherung brav „erfolgreich" meldet.

Sage 100 speichert seine Daten in einer Microsoft-SQL-Server-Datenbank. Damit hängt die Sicherheit Eurer Buchhaltung, Aufträge und Stammdaten direkt an einer sauberen Sicherungsstrategie auf dem SQL Server. Dieser Beitrag zeigt, wo solche Strategien still kaputtgehen und wie Du das selbst prüfst.

Die Sicherungskette, die niemand sieht

Eine typische SQL-Server-Strategie besteht aus drei Bausteinen. Die Vollsicherung enthält den kompletten Stand. Die Differenzsicherung enthält nur die Änderungen seit der letzten Vollsicherung. Die Log-Sicherung enthält die einzelnen Transaktionen dazwischen. Zusammen ergeben sie eine Kette, mit der Du nicht nur den Stand von gestern Nacht, sondern auch einen Zeitpunkt mittags um 11:43 Uhr wiederherstellen kannst.

Entscheidend ist das Wort Kette. Eine Differenzsicherung ist für sich allein wertlos. Sie funktioniert nur zusammen mit genau der Vollsicherung, auf der sie aufbaut. Diese Vollsicherung nennt sich Differenzbasis. Und genau hier passiert der häufigste stille Fehler.

Der Klassiker: Das ungeplante Vollbackup

Stell Dir vor, Eure geplante Sicherung macht sonntags eine Vollsicherung und an den übrigen Tagen Differenzsicherungen. Alles läuft. Dann installiert jemand ein zusätzliches Tool, ein Monitoring oder eine Backup-Software, die einmalig „zur Sicherheit" eine eigene Vollsicherung zieht. Diese Vollsicherung wird ohne das Kennzeichen COPY_ONLY ausgeführt.

Was technisch korrekt klingt, hat eine unangenehme Folge: Eine normale Vollsicherung setzt die Differenzbasis neu. Ab diesem Moment beziehen sich alle Differenzsicherungen nicht mehr auf Eure geplante Sonntags-Vollsicherung, sondern auf das fremde Vollbackup. Liegt dieses Vollbackup an einem anderen Ort oder wird es nicht aufbewahrt, fehlt im Ernstfall die passende Basis. Die Differenzsicherungen laufen ins Leere, obwohl jede für sich erfolgreich war.

Genau dafür gibt es das Kennzeichen COPY_ONLY. Eine COPY_ONLY-Vollsicherung verändert die Differenzbasis nicht. Sie ist gedacht für Sonder- und Ad-hoc-Sicherungen, die den geplanten Rhythmus nicht stören sollen. Fehlt COPY_ONLY bei einem ungeplanten Vollbackup, bricht die Kette.

Weitere stille Risiken

• Fehlende Log-Sicherungen: Steht eine Datenbank im Wiederherstellungsmodell FULL, aber es werden nie Log-Sicherungen gemacht, wächst das Transaktionsprotokoll unbegrenzt. Gleichzeitig ist keine Wiederherstellung auf einen Zeitpunkt möglich.
• Lücken in der Log-Kette: Auch die Log-Sicherungen bilden eine Kette. Fehlt ein Glied, lässt sich über diese Lücke hinweg kein durchgängiger Zeitpunkt mehr herstellen.
• Sicherung auf dem falschen Laufwerk: Backups, die auf demselben Laufwerk oder gar auf der Systemplatte C: liegen, sind bei einem Hardware- oder Verschlüsselungsvorfall genauso weg wie die Originaldaten.
• Zu alte Sicherungen: Eine Vollsicherung, die Wochen zurückliegt, bedeutet im Ernstfall einen entsprechend großen Datenverlust.

Ein Backup ohne getesteten Restore ist kein Backup

Der wichtigste Satz zum Schluss zuerst: Erst ein erfolgreich getesteter Wiederherstellungslauf beweist, dass Eure Sicherung etwas wert ist. Alles davor ist eine begründete Hoffnung. Ein Restore-Test deckt nicht nur kaputte Ketten auf, sondern auch praktische Fragen: Wie lange dauert die Wiederherstellung wirklich? Wer darf sie durchführen? Sind die Sicherungen überhaupt erreichbar?

Als Orientierung hat sich die 3-2-1-Regel bewährt: Drei Kopien der Daten, auf zwei verschiedenen Medien, davon eine außer Haus. Für Sage 100 heißt das konkret: Regelmäßige Voll-, Differenz- und Log-Sicherungen, auf ein separates Ziel, plus eine Kopie an einem anderen Ort, und regelmäßige Restore-Tests.

So prüfst Du Deine Sicherungskette selbst

Der SQL Server protokolliert jede Sicherung in seiner eigenen Historie. Diese Historie lässt sich auslesen und auswerten, ganz ohne in die Produktivdatenbank einzugreifen. Genau dafür haben wir ein Werkzeug gebaut: Der SQL-Backup-Chain-Analyzer liest die exportierte Backup-Historie und prüft die Kette auf genau die Punkte aus diesem Beitrag. Er erkennt unter anderem eine verschobene Differenzbasis, fehlende Log-Sicherungen, Sicherungen auf dem falschen Laufwerk und auffällige Lücken.

Eine fertige SQL-Abfrage und eine Schritt-für-Schritt-Anleitung, wie Du die Historie aus dem SQL Server Management Studio als CSV exportierst, findest Du direkt im Tool. Die Datei wird ausschließlich lokal in Deinem Browser ausgewertet, es werden keine Daten übertragen. Datenbank- und Pfadnamen kannst Du vorher anonymisieren.

Backup ist auch ein GoBD-Thema

Eine funktionierende Datensicherung ist nicht nur Betriebssicherheit, sondern auch Teil der GoBD-Anforderungen an die Nachvollziehbarkeit und Verfügbarkeit Deiner steuerrelevanten Daten. Wie es um Sicherung, Berechtigungen, Protokollierung und Dokumentation in Deiner Sage-100-Umgebung steht, kannst Du mit unserem GoBD-Selbstcheck in wenigen Minuten einschätzen.

Wenn Du wissen willst, ob Eure Sicherungsstrategie im Ernstfall wirklich trägt, schauen wir uns das gemeinsam an. Wir betreuen Sage 100 inklusive der darunterliegenden SQL-Server-Umgebung und prüfen Sicherungskette, Wiederherstellung und Berechtigungen technisch und fachlich. Melde Dich, dann klären wir Deinen Fall.