Backup-Strategie planen — RPO, RTO und die 3-2-1-Regel

Wie oft, was, wohin? Von den zwei entscheidenden Fragen zur fertigen Strategie — und warum ein ungetestetes Backup keines ist.

Es gibt zwei Sorten von Unternehmen: solche, die eine durchdachte Backup-Strategie haben, und solche, die glauben, eine zu haben. Die zweite Sorte erkennt man daran, dass auf die Frage „Wie viele Daten würdet ihr im schlimmsten Fall verlieren?“ betretenes Schweigen folgt — oder die Antwort „Wir machen doch jede Nacht ein Backup“, als wäre damit alles gesagt. Dabei ist „wir machen ein Backup“ ungefähr so beruhigend wie „wir haben einen Feuerlöscher“ — ohne zu wissen, ob er gefüllt ist, wo er hängt und ob jemand ihn bedienen kann. Eine Backup-Strategie ist nicht die Tatsache, dass gesichert wird. Sie ist die Antwort auf die Frage, was im Ernstfall genau passiert.

Dieser Beitrag aus dem SQL-Server-Notarztwagen (die Triage-Übersicht liegt unter /sql-server-notarztwagen/) führt dich von den zwei entscheidenden Fragen — wie viel Datenverlust und wie viel Ausfallzeit ist tolerierbar? — zur fertigen Strategie: dem richtigen Backup-Rhythmus, der 3-2-1-Regel und der eisernen Wahrheit, dass ein nie getestetes Backup gar keines ist. Als Beitrag der GRÜN-Stufe geht es hier um die ruhige Planung, die den Ernstfall überflüssig macht — das Gegenstück zu den akuten Backup- und Recovery-Notfällen der ROT- und GELB-Stufe.

RPO und RTO — die zwei Fragen, aus denen alles folgt

Jede sinnvolle Backup-Strategie beginnt nicht mit Technik, sondern mit zwei Fragen ans Geschäft. Die erste: Wie viele Daten dürfen wir im Ernstfall verlieren? Das ist das Recovery Point Objective (RPO) — der maximal tolerierbare Abstand zwischen dem letzten brauchbaren Sicherungspunkt und dem Moment des Ausfalls. Ein RPO von 15 Minuten heißt: Im schlimmsten Fall verlieren wir 15 Minuten Arbeit. Die zweite Frage: Wie lange darf die Wiederherstellung dauern? Das ist das Recovery Time Objective (RTO) — die maximal tolerierbare Ausfallzeit, bis das System wieder läuft. Ein RTO von einer Stunde heißt: Nach spätestens einer Stunde muss die Datenbank wieder online sein.

Das Entscheidende: Beide Werte sind Geschäftsentscheidungen, keine technischen. Sie kommen aus der Fachabteilung, dem Risikomanagement, der Geschäftsführung — nicht aus der IT. Die Frage „Wie viel Datenverlust kostet uns wie viel?“ kann nur das Business beantworten, und erst aus dieser Antwort leitet die Technik ab, wie oft und wie gesichert werden muss. Wer die Reihenfolge umdreht und erst das Backup-Schema baut und dann hofft, dass es passt, hat schon verloren — meist merkt er es erst im Ernstfall, wenn die tatsächliche Wiederherstellung dreimal so lange dauert wie gedacht oder vier Stunden Daten fehlen, wo das Geschäft nur fünfzehn Minuten verkraftet hätte.

Die beiden Größen steuern unterschiedliche Stellschrauben. Das RPO steuert die Log-Frequenz: Je weniger Datenverlust toleriert wird, desto häufiger muss das Transaktionslog gesichert werden — denn der Abstand zwischen zwei Log-Sicherungen ist genau das Fenster, das im schlimmsten Fall verloren geht. Das RTO steuert den Backup-Mix und die Storage-Nähe: Je schneller wiederhergestellt werden muss, desto wichtiger sind differenzielle Backups (die den Restore verkürzen), schnelles Storage für die Sicherungen und ihre Erreichbarkeit. Aus zwei Geschäftszahlen wird so ein konkreter technischer Plan. Ein Rechenbeispiel macht es greifbar: Verlangt das Geschäft einen RPO von 15 Minuten, ergibt sich daraus zwingend eine Log-Sicherung mindestens alle 15 Minuten — keine Diskussion, das ist reine Arithmetik. Verlangt es zusätzlich ein RTO von einer Stunde für eine 500-Gigabyte-Datenbank, dann scheidet die Wiederherstellung allein aus wöchentlichen Voll-Backups plus einer Woche Log-Ketten aus, weil das Zurückspielen viel zu lange dauern würde — also braucht es tägliche differenzielle Backups, die den Restore-Weg kurz halten. Dieselbe Datenbank, andere Geschäftszahlen, anderer Plan: Genau das ist der Sinn der Übung.

Von der Anforderung zum Rhythmus

Die folgende Skizze zeigt den ganzen Weg: von den zwei Steuergrößen über den abgeleiteten Backup-Rhythmus bis zur 3-2-1-Regel und der eisernen Verifikations-Wahrheit:

Die Skripte: sichern, prüfen, verifizieren

Schritt 1 — Die drei Backup-Typen

Der Werkzeugkasten besteht aus drei Sicherungstypen, die zusammen den Rhythmus ergeben. Hier die Grundbefehle mit den wichtigsten Optionen:

Die Optionen sind kein Beiwerk: COMPRESSION verkleinert die Dateien und beschleunigt Backup wie Restore (besseres RTO), CHECKSUM prüft die Seiten beim Sichern auf Korruption (frühe Warnung), und INIT überschreibt die Zieldatei statt anzuhängen. Voraussetzung für Log-Backups und Tail-Log ist das FULL-Recovery-Model — im SIMPLE-Model gibt es keine Log-Sicherungen und damit kein Point-in-Time-Recovery.

Schritt 2 — Backup-Frische prüfen

Schritt 3 — Verifizieren und den Weg zurück testen

RESTORE VERIFYONLY prüft nur, ob die Datei lesbar ist — das ist die Pflicht, aber nicht die Kür. Die einzige echte Verifikation ist der Test-Restore auf einem separaten System: Erst wenn aus dem Backup tatsächlich eine funktionierende Datenbank wird, ist es bewiesen. Genau hier trennt sich die echte Strategie vom Wunschdenken.

Die Strategie im Detail

Das Recovery-Model — die Grundsatzentscheidung

Bevor der Rhythmus steht, fällt eine Grundsatzentscheidung: das Recovery-Model. Im FULL-Model wird jede Transaktion im Log festgehalten, bis sie gesichert ist — das ermöglicht Log-Backups und damit Point-in-Time-Recovery (Wiederherstellung auf eine beliebige Minute) sowie das rettende Tail-Log-Backup. Der Preis: Das Log muss regelmäßig gesichert werden, sonst läuft es voll (der häufigste Anfängerfehler, eigener Notfall-Beitrag). Im SIMPLE-Model räumt der Server das Log selbst auf — bequem, aber es gibt keine Log-Backups und damit nur die Wiederherstellung auf den letzten Voll- oder Diff-Stand. SIMPLE ist eine bewusste Wahl für Datenbanken, deren RPO einen ganzen Tag verträgt (etwa reine Lese-Data-Warehouses); für alles mit echtem Transaktionsbetrieb ist FULL der Standard. Es gibt noch ein drittes Model, BULK_LOGGED, das als Sonderfall für die Dauer großer Massenoperationen (etwa Index-Rebuilds oder Bulk-Importe) gedacht ist: Es protokolliert solche Operationen minimal und hält damit das Log klein, behält aber ansonsten die Log-Sicherungskette bei. Der Haken ist, dass Point-in-Time-Recovery für den Zeitraum einer minimal protokollierten Operation nicht möglich ist — weshalb BULK_LOGGED ein Werkzeug für gezielte Wartungsfenster bleibt und nicht der Dauerzustand sein sollte. Für den Normalbetrieb gilt: FULL für transaktionale, SIMPLE für tagverträgliche Datenbanken.

Die 3-2-1-Regel — wohin die Sicherungen gehören

Der beste Backup-Rhythmus nützt nichts, wenn alle Sicherungen am selben Ort liegen wie die Datenbank. Die 3-2-1-Regel streut das Risiko: drei Kopien insgesamt (Original plus zwei Backups), auf zwei verschiedenen Medien oder Speicherorten, mit einer Kopie außer Haus oder offline. Der Grund ist die Eskalationsleiter der Katastrophen: Ein Backup auf demselben SAN schützt gegen den versehentlich gelöschten Datensatz, aber nicht gegen einen SAN-Ausfall. Ein Backup im selben Rechenzentrum schützt gegen den SAN-Ausfall, aber nicht gegen Brand oder Hochwasser. Und gegen Ransomware — die moderne Hauptbedrohung — schützt nur die offline gehaltene, nicht erreichbare Kopie, denn Verschlüsselungs-Angriffe suchen gezielt nach erreichbaren Backups und nehmen sie gleich mit. Die eine Offline-Kopie ist heute kein Luxus, sondern Überlebensvoraussetzung.

Verifikation — die eiserne Regel

Es ist die wichtigste Wahrheit dieses ganzen Beitrags, und sie verträgt keine Ausnahme: Ein Backup, das nie wiederhergestellt wurde, ist kein Backup — es ist eine Hoffnung. Ein grüner Backup-Job in der Job-Historie beweist ausschließlich, dass Daten geschrieben wurden. Ob aus diesen Daten im Ernstfall wieder eine funktionierende Datenbank wird, beweist allein der Test-Restore. Die Zahl der Unternehmen, die im Schadensfall feststellen mussten, dass ihre jahrelang grünen Backups gar nicht wiederherstellbar waren — wegen beschädigter Dateien, fehlender Log-Kette, unvollständiger Sicherung —, ist erschreckend hoch. Der regelmäßige, am besten automatisierte Test-Restore ist deshalb kein optionaler Feinschliff, sondern der Teil der Strategie, ohne den alles andere wertlos ist. Wie man ihn richtig aufzieht und gleich das echte RTO misst, steht im Disaster-Recovery-Test-Beitrag.

Was du auf keinen Fall tun solltest

Die Strategie in der Routine

Eine Backup-Strategie ist kein Dokument, das man einmal schreibt und ablegt, sondern ein lebender Prozess. Drei Punkte halten sie am Leben: Erstens, die Backup-Frische und Job-Erfolge automatisiert überwachen — ein fehlgeschlagenes Backup muss am selben Tag auffallen, nicht im Schadensfall; das gehört ins Tagesminimum des Health Checks. Zweitens, den Test-Restore automatisieren und terminieren — kritische Datenbanken regelmäßig, am besten ohne menschlichen Aufwand und mit Alarm nur bei Fehlern. Drittens, RPO und RTO regelmäßig mit dem Geschäft abgleichen: Anforderungen ändern sich, eine Datenbank wächst aus ihrer alten Strategie heraus, und was vor drei Jahren als tolerierbarer Verlust galt, ist heute vielleicht ein Compliance-Verstoß. Wie die Backup-Prüfung in das große Bild der proaktiven Wartung passt, zeigt der Health-Check-Beitrag der GRÜN-Stufe.

Vertiefung in der Buchreihe

Backup-Architektur, Recovery-Modelle und Restore-Strategien füllen in der Buchreihe „SQL Server in der Praxis“ einen ganzen Band — alle Bände in der Übersicht auf der SQL-Pillar-Seite unter /sql-server/.

Verwandte Beiträge im Notarztwagen

Die Backup-Strategie ist mit vielen Themen verwoben — diese Beiträge aus dem Cluster lohnen den Blick:

Drei Wege zur belastbaren Backup-Strategie

Selbst-Diagnose-Kit

Eine Backup-Strategie selbst aufzustellen ist gut investierte Zeit — und genau dafür gibt es das Diagnose-Kit. Es bündelt die Skripte aus diesem Beitrag — Backup-Befehle für alle drei Typen, Frische-Prüfung, Verifikations- und Test-Restore-Vorlagen — plus einen RPO/RTO-Fragebogen für das Gespräch mit dem Geschäft, die 3-2-1-Checkliste und eine Vorlage für den Backup-Rhythmus. Damit verwandelst du „wir machen ein Backup“ in einen dokumentierten Plan, der den Namen Strategie verdient.

Festpreis-Analyse

Du willst Gewissheit, dass deine Backup-Strategie im Ernstfall trägt — inklusive eines echten Beweises, dass die Wiederherstellung funktioniert? Die Festpreis-Analyse liefert genau das: Ich prüfe die komplette Strategie gegen deine RPO/RTO-Anforderungen, kontrolliere Rhythmus, Recovery-Modelle, Lagerorte und die 3-2-1-Umsetzung, führe einen echten Test-Restore durch und messe das tatsächliche RTO — und liefere einen Bericht mit priorisierten Maßnahmen. Zum vereinbarten Festpreis, ohne Stundenzähler.

Akut-Hotline

Wenn gerade jetzt eine Wiederherstellung ansteht und du auf Nummer sicher gehen willst — oder wenn ein Backup-Problem akut geworden ist: anrufen. Halte die Information bereit, welche Backups vorliegen und in welchem Recovery-Model die Datenbank läuft. Bei einer Wiederherstellung zählt jeder richtige Schritt, und der erste ist fast immer das Tail-Log-Backup.

Häufige Fragen (FAQ)

Diese Sektion ist auf häufige Suchanfragen abgestimmt. Sie hilft dir, schnell den Punkt zu finden, der dir gerade akut weiterhilft — und sie ist gleichzeitig die Eingabe für das FAQPage-Schema auf der Seite.

Was bedeutet RPO und RTO?

RPO (Recovery Point Objective) und RTO (Recovery Time Objective) sind die zwei Steuergrößen jeder Backup-Strategie. RPO beantwortet die Frage „Wie viele Daten dürfen wir im Ernstfall verlieren?“ — also den maximal tolerierbaren Abstand zum letzten brauchbaren Sicherungspunkt; er steuert vor allem die Häufigkeit der Log-Sicherungen. RTO beantwortet „Wie lange darf die Wiederherstellung dauern?“ — also die maximal tolerierbare Ausfallzeit; sie steuert den Mix aus Backup-Typen und die Nähe der Sicherung zum Server. Beide Werte sind keine technischen, sondern Geschäftsentscheidungen: Sie kommen aus dem Business, nicht aus der IT, und die Technik leitet sich daraus ab.

Wie oft sollte ich Backups machen?

Das hängt direkt am RPO und ist deshalb keine pauschale Zahl. Die Faustkonstruktion: Ein Voll-Backup als Basis (oft wöchentlich), differenzielle Backups dazwischen zur Verkürzung der Wiederherstellung (oft täglich), und Log-Sicherungen im Takt deines RPO (im FULL-Recovery-Model häufig alle 15 Minuten, bei strengeren Anforderungen öfter). Der entscheidende Hebel für den Datenverlust ist die Log-Frequenz: Wer alle 15 Minuten das Log sichert, verliert im schlimmsten Fall 15 Minuten Daten. Die genauen Intervalle leitest du aus RPO und RTO ab — die Skizze in diesem Beitrag zeigt das Zusammenspiel.

Was ist die 3-2-1-Backup-Regel?

Die 3-2-1-Regel ist die bewährte Faustregel dafür, wohin Backups gehören: drei Kopien der Daten insgesamt (das Original plus zwei Sicherungen), auf zwei verschiedenen Medien oder Speicherorten (nicht beide auf demselben SAN), und eine Kopie außer Haus oder offline. Der Sinn ist Risikostreuung: Liegen alle Backups auf demselben Storage wie die Datenbank, hilft das gegen einen Datei-Unfall, aber nicht gegen Brand, SAN-Ausfall oder Ransomware. Die eine externe, idealerweise offline gehaltene Kopie ist die Versicherung gegen den Totalverlust eines Standorts — und gegen Verschlüsselungs-Angriffe, die gezielt erreichbare Backups mitverschlüsseln.

Was ist ein Tail-Log-Backup?

Ein Tail-Log-Backup ist die allerletzte Log-Sicherung, die du unmittelbar vor einer Wiederherstellung anfertigst — sie sichert den „Schwanz“ des Transaktionslogs, also alle Transaktionen, die seit der letzten regulären Log-Sicherung noch nicht gesichert wurden. Ohne sie gehen genau diese letzten Transaktionen beim Restore verloren. Im Schadensfall (etwa eine versehentlich gelöschte Tabelle oder eine beschädigte Datendatei) ist das Tail-Log-Backup deshalb oft der entscheidende Schritt, um den Datenverlust auf nahezu null zu drücken. Es funktioniert nur im FULL- oder BULK_LOGGED-Recovery-Model und setzt voraus, dass das Log noch zugänglich ist — ein wichtiger Grund, Datendateien und Log zu trennen.

Sollte ich Backup-Compression nutzen?

In den allermeisten Fällen ja. Backup-Compression verkleinert die Sicherungsdateien oft erheblich, was gleich mehrfach Nutzen bringt: weniger Speicherplatz, schnellere Backups (weniger Daten müssen geschrieben werden) und vor allem schnellere Restores — was direkt dein RTO verbessert. Der Preis ist zusätzliche CPU-Last während des Backups, die auf modernen Servern aber selten ins Gewicht fällt. Sinnvoll ist Compression deshalb als Standard, mit wenigen Ausnahmen: Bei bereits transparent verschlüsselten Datenbanken (TDE) bringt sie auf älteren Versionen wenig, und wenn die CPU zum Backup-Zeitpunkt ohnehin am Limit läuft, will man es prüfen. Im Zweifel: einschalten.

Wie verifiziere ich, dass ein Backup funktioniert?

In zwei Stufen. Die minimale Stufe ist RESTORE VERIFYONLY und die Option BACKUP … WITH CHECKSUM: Sie prüfen, ob die Backup-Datei lesbar und in sich konsistent ist — das fängt beschädigte Dateien ab, beweist aber noch nicht die Wiederherstellbarkeit. Die einzige echte Verifikation ist deshalb der Test-Restore: das Backup auf einem separaten System tatsächlich zurückspielen und prüfen, ob daraus eine funktionierende Datenbank wird. Erst der gelungene Restore macht aus einem geschriebenen Backup ein verlässliches. Ein grüner Backup-Job ist nur die halbe Miete — die andere Hälfte ist der bewiesene Weg zurück.

Wie oft sollte ich Restore-Tests machen?

Regelmäßig und planmäßig, nicht nur im Schadensfall — denn der Schadensfall ist der schlechteste Zeitpunkt, um festzustellen, dass das Backup nicht funktioniert. Eine sinnvolle Staffel: kritische Datenbanken monatlich oder quartalsweise testen, alle anderen zumindest jährlich, und zusätzlich nach jeder größeren Änderung an der Backup-Konfiguration oder der Infrastruktur. Idealerweise automatisierst du den Test-Restore, sodass er ohne menschlichen Aufwand läuft und nur bei Fehlern Alarm schlägt. Der Test prüft dabei nicht nur, ob das Backup zurückkommt, sondern auch, wie lange es dauert — und liefert damit gleich die ehrliche Messung deines tatsächlichen RTO. Mehr dazu im Disaster-Recovery-Test-Beitrag.