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.
Halten Sie den Backup-Plan schriftlich fest
Wenn die Backup-Routine nur im Kopf einer Person existiert, fehlt der Plan, sobald diese Person nicht erreichbar ist. Ein kurzes, aktuell gehaltenes Dokument spart im Krisenfall Zeit. Es sollte mindestens Folgendes enthalten:
- Eine Liste der gesicherten Datenbanken und den jeweiligen fachlichen Verantwortlichen
- Die vereinbarten RPO- und RTO-Werte je Datenbank
- Backup-Typen, Zeitplan und Speicherorte
- Wer Benachrichtigungen über fehlgeschlagene Backups erhält
- Wo Zertifikate und Schlüssel liegen, falls Backup-Verschlüsselung genutzt wird
- Die Schritte der Wiederherstellung und die dazu berechtigten Personen
Ein verschlüsseltes Backup lässt sich ohne das zugehörige Zertifikat nicht wiederherstellen. Bewahren Sie das Zertifikat getrennt und sicher auf, nicht am selben Ort wie die Backups.
Reihenfolge der Wiederherstellung im Störfall
Bei einem Ausfall ist die erste Reaktion oft, sofort mit der Wiederherstellung zu beginnen. Die richtige Reihenfolge verringert jedoch den Datenverlust.
- Bewerten Sie die Lage und überschreiben Sie keine vorhandenen Dateien. Die beschädigte Datenbank kann später für die Analyse benötigt werden.
- Wenn Sie das Wiederherstellungsmodell FULL nutzen und die Protokolldatei erreichbar ist, erstellen Sie zuerst eine letzte Protokollsicherung (Tail-Log).
- Entscheiden Sie, zu welchem Zeitpunkt Sie zurückkehren möchten. Nach einer fehlerhaften Operation ist das der Moment unmittelbar davor.
- Stellen Sie das vollständige Backup, danach das differenzielle Backup und die Protokollsicherungen der Reihe nach wieder her. Geben Sie die Datenbank erst im letzten Schritt frei.
- Führen Sie eine Integritätsprüfung durch und testen Sie anschließend Anwendung und Benutzerzugriffe.
Um diese Reihenfolge vorab zu proben und zu dokumentieren, können Sie auf eine SQL-Beratung zurückgreifen.
Wöchentliche Routine zur Backup-Kontrolle
Backup-Aufträge können unbemerkt ausfallen. Eine kurze wöchentliche Kontrolle zeigt Probleme, bevor Sie das Backup benötigen. Weisen Sie die Kontrolle einer Person zu und halten Sie das Ergebnis fest.
- Prüfen Sie das letzte Backup-Datum aller Datenbanken im Sicherungsverlauf in msdb.
- Sehen Sie sich Aufträge an, die fehlgeschlagen oder gar nicht gelaufen sind.
- Beobachten Sie den freien Speicherplatz auf dem Backup-Laufwerk und dessen Entwicklung.
- Vergewissern Sie sich, dass die externe Kopie tatsächlich aktualisiert wird.
- Stellen Sie sicher, dass neu hinzugekommene Datenbanken in den Plan aufgenommen wurden.
Wie Sie über Backups hinaus die Wiederherstellung aller Systeme planen, zeigt unser Leitfaden zum Disaster-Recovery-Plan.
Häufig gestellte Fragen
Kann ein Snapshot der virtuellen Maschine ein SQL-Backup ersetzen?
Für sich allein nicht. Snapshots liegen meist auf derselben Infrastruktur und sind nicht für die langfristige Aufbewahrung gedacht. Außerdem fehlt ihnen die Flexibilität, zu einem bestimmten Zeitpunkt zurückzukehren, wie sie Protokollsicherungen bieten. Sinnvoller ist es, Snapshots als zusätzliche Ebene zu betrachten, die die eigenen Backups von SQL Server ergänzt.
Sollten wir die Backup-Komprimierung nutzen?
Die Komprimierung verkleinert die Backup-Datei und verkürzt häufig auch die Dauer der Sicherung, weil weniger Daten auf den Datenträger geschrieben werden. Im Gegenzug steigt die Prozessorlast während des Backups. Beobachten Sie diesen Effekt bei Sicherungen zu Stoßzeiten und prüfen Sie, ob Ihre Edition die Funktion unterstützt.
Wie lange sollten wir Backups aufbewahren?
Darauf gibt es keine einzige richtige Antwort. Die Aufbewahrungsdauer richtet sich nach Ihren geschäftlichen Anforderungen und den für Sie geltenden gesetzlichen Pflichten. Bedenken Sie auch, wie spät ein Datenfehler bemerkt werden könnte. Wir empfehlen, Ihre Pflichten mit Ihren Steuer- und Rechtsberatern zu prüfen und die Dauer schriftlich festzulegen.
Was ist ein COPY_ONLY-Backup und wann wird es verwendet?
COPY_ONLY ist eine unabhängige Sicherung, die die bestehende Backup-Kette nicht beeinflusst. Sie wird in ungeplanten Situationen verwendet, etwa um Daten in eine Testumgebung zu übertragen oder vor einem Update eine zusätzliche Kopie zu erstellen. Ein normales vollständiges Backup verändert die Basis späterer differenzieller Backups, COPY_ONLY lässt diese Reihenfolge unverändert.
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.