Die häufigste Situation, die wir in der Praxis sehen, ist diese: Es werden Backups erstellt, aber niemand weiß, ob man aus ihnen tatsächlich wiederherstellen kann. Der Unterschied zwischen diesen beiden Sätzen entscheidet darüber, ob ein Unternehmen weiterarbeiten kann oder nicht.
Ein Backup zu erstellen ist eine Aufgabe, wiederherstellen zu können ist eine Fähigkeit. Ein ungetestetes Backup zählt nicht als Backup.
Beantworten Sie zuerst zwei Fragen: RPO und RTO
Bevor es ins technische Detail geht, muss die Geschäftsseite zwei Kennzahlen festlegen:
- RPO (Recovery Point Objective): Wie viel Datenverlust können Sie im Katastrophenfall akzeptieren? 24 Stunden, 1 Stunde, 5 Minuten?
- RTO (Recovery Time Objective): Wie lange darf es höchstens dauern, bis das System wieder läuft? Ein halber Tag, 2 Stunden?
Jeder Backup-Plan, der ohne diese beiden Kennzahlen erstellt wird, beruht auf Vermutungen. Ein Unternehmen, das einmal täglich nachts ein Backup erstellt, hat eine RPO von 24 Stunden – ein Ausfall am Nachmittag würde alle Rechnungen, Bestellungen und Zahlungen dieses Tages kosten. Ist das akzeptabel? Diese Antwort gibt das Management, nicht die IT-Abteilung.
SQL Server Backup-Typen
Vollbackup (Full Backup): Die gesamte Datenbank. Die Grundlage jeder Wiederherstellung.
Differenzielles Backup (Differential Backup): Alle Änderungen seit dem letzten Vollbackup. Verkürzt die Wiederherstellungszeit und reduziert die Backup-Größe.
Transaktionsprotokoll-Backup (Transaction Log Backup): Nur im FULL-Recovery-Modell möglich. Ermöglicht die Wiederherstellung auf einen bestimmten Zeitpunkt (z. B. eine Minute vor einem versehentlichen Löschvorgang) und verhindert ein unbegrenztes Wachstum der Protokolldatei.
Ein typisches Setup sieht so aus: wöchentlich ein Vollbackup, täglich ein differenzielles Backup, alle 15 Minuten ein Protokoll-Backup. Diese Kombination senkt die RPO auf 15 Minuten.
Die Recovery-Modell-Falle
Befindet sich Ihre Datenbank im FULL-Recovery-Modell und Sie erstellen keine Protokoll-Backups, wächst die Protokolldatei immer weiter, bis eines Tages die Festplatte voll ist. Das ist eine klassische Ursache für Vorfälle, die als „SQL ist abgestürzt“ gemeldet werden.
Die Regel ist einfach: Wenn Sie das FULL-Modell verwenden, müssen Sie regelmäßig Protokoll-Backups erstellen. Wenn nicht und Sie keine minutengenaue Wiederherstellung benötigen, ist das SIMPLE-Modell die sinnvollere Wahl.
Die 3-2-1-Regel
Eine bewährte, gesunde Backup-Verteilung:
- 3 Kopien der Daten
- 2 verschiedene Speichermedien
- 1 Kopie außerhalb des Standorts (offsite)
Heute muss ein weiterer Punkt ergänzt werden: 1 Kopie offline oder unveränderlich (immutable). Ransomware verschlüsselt oder löscht mittlerweile zuerst jedes Backup, auf das sie zugreifen kann. Ein Backup auf einem NAS im selben Netzwerk kann zusammen mit dem Hauptserver verloren gehen.
Backup-Verifizierung und Integritätsprüfung
Nach der Erstellung eines Backups:
RESTORE VERIFYONLY FROM DISK = 'D:\Backup\ERP_full.bak';Dieser Befehl bestätigt, dass das Backup lesbar ist, garantiert aber nicht die Integrität des Inhalts. Deshalb sollte regelmäßig auch eine Integritätsprüfung der Datenbank selbst durchgeführt werden:
DBCC CHECKDB ('Datenbankname') WITH NO_INFOMSGS;Eine beschädigte Datenbank zu sichern bedeutet, die Beschädigung ins Backup zu übertragen. Wird das Problem erst Monate später bemerkt, können sämtliche vorhandenen Backups bereits unbrauchbar sein.
Der Restore-Test: der am häufigsten übersprungene Schritt
Mindestens einmal pro Quartal sollte ein echter Wiederherstellungsversuch von einem Backup auf einen separaten Server durchgeführt und Folgendes dokumentiert werden:
- Wie lange hat die Wiederherstellung gedauert? (Das ist Ihre tatsächliche RTO.)
- Bei welchen Schritten gab es Probleme?
- Hat die Anwendung mit der wiederhergestellten Datenbank einwandfrei funktioniert?
- Stimmen Benutzerkonten (Login-/User-Zuordnung), Berechtigungen und Jobs?
Ein Unternehmen, das diesen Test noch nie durchgeführt hat, kennt seine tatsächliche RTO nicht – und sie mitten in einer Krise herauszufinden, ist die teuerste Art, es zu lernen.
Häufige Fehler
- Backups auf derselben Festplatte wie die Datenbank aufbewahren
- Keine Benachrichtigung bei fehlgeschlagenem Backup-Job
- Unverschlüsselte Backups in einem freigegebenen Ordner
- Systemdatenbanken (master, msdb) werden nicht gesichert
- Es wurde nie eine Aufbewahrungsrichtlinie (Retention Policy) definiert, obwohl sie genauso wichtig ist wie das Backup selbst
Fazit
Backup ist kein Kostenpunkt, sondern eine Versicherung – und wie jede Versicherung zeigt sich ihr Wert erst an einem schlechten Tag. Vergewissern Sie sich nicht nur, dass Ihre Backups existieren, sondern dass Sie aus ihnen wiederherstellen können.
Als ÇAP Teknoloji unterstützen wir bei der Konzeption, Automatisierung und Überwachung von Backup-Strategien sowie bei regelmäßigen Restore-Tests. Wenn Sie herausfinden möchten, ob Ihre aktuelle Backup-Struktur tatsächlich funktioniert, informieren Sie sich über unsere SQL-Beratung oder nehmen Sie Kontakt mit uns auf.