MSSQL Backup-Strategien: Full, Differential, Transaction Log

Warum Backup-Strategien kritisch sind

Die harte Realität: 60% der Unternehmen, die ihre Daten nicht innerhalb von 72 Stunden wiederherstellen können, gehen innerhalb von 2 Jahren in Konkurs (Quelle: National Archives & Records Administration).

Typische Datenverlust-Szenarien:

• Hardware-Ausfall: Festplatten-Crash, RAID-Controller-Fehler, Server-Brand
• Ransomware: Verschlüsselte Datenbanken durch Cyber-Angriffe
• Menschliches Versagen: Versehentliches Löschen von Tabellen, falsche UPDATE-Statements ohne WHERE-Clause
• Korruption: Datenbank-Korruption durch Power-Loss, Disk-Errors
• Diebstahl: Physischer Server-Diebstahl

Die 3 MSSQL Backup-Typen verstehen

1. Full Backup (Vollsicherung)

Ein Full Backup sichert die komplette Datenbank – alle Datenseiten, Tabellen, Indizes, Stored Procedures, etc.

• Größe: Sehr groß (entspricht Datenbankgröße)
• Dauer: Längste Backup-Zeit
• Recovery: Basis für alle anderen Backups (ohne Full Backup keine Differential/Log-Backups möglich)
• Isolation: Kann eigenständig wiederhergestellt werden

Wann Full Backup:

• ✅ Täglich, wöchentlich oder monatlich (je nach DB-Größe und Änderungsrate)
• ✅ Vor großen Migrations oder Updates
• ✅ Nach Wartungsfenstern

2. Differential Backup (Differenzielle Sicherung)

Ein Differential Backup sichert nur die Daten, die seit dem letzten Full Backup geändert wurden.

• Größe: Kleiner als Full Backup, wächst aber bis zum nächsten Full Backup
• Dauer: Schneller als Full Backup
• Recovery: Benötigt das letzte Full Backup + das letzte Differential Backup
• Vorteil: Schnellere Recovery als mit Transaction Log Backups (weniger Restore-Schritte)

Wann Differential Backup:

• ✅ 1-4x täglich (zwischen Full Backups)
• ✅ Ideal für mittlere Datenbanken (10-500 GB)
• ✅ Wenn schnelle Recovery wichtiger ist als Backup-Größe

3. Transaction Log Backup (Transaktionslog-Sicherung)

Ein Transaction Log Backup sichert alle Transaktionen (INSERTs, UPDATEs, DELETEs), die seit dem letzten Log Backup aufgetreten sind.

• Größe: Sehr klein (nur Transaktionen)
• Dauer: Sehr schnell (Sekunden)
• Recovery: Ermöglicht Point-in-Time-Recovery (auf die Sekunde genau)
• Voraussetzung: Datenbank muss im FULL Recovery Model sein

Wann Transaction Log Backup:

• ✅ Alle 15-60 Minuten (je nach RPO-Anforderung)
• ✅ Für produktionskritische Datenbanken (minimaler Datenverlust)
• ✅ Wenn Point-in-Time-Recovery gefordert ist

RTO und RPO verstehen: Ihre Backup-Ziele definieren

Bevor Sie eine Backup-Strategie entwickeln, müssen Sie zwei zentrale Kennzahlen definieren:

RTO (Recovery Time Objective)

Wie schnell muss die Datenbank nach einem Ausfall wiederhergestellt sein?

• Beispiel: "Maximal 4 Stunden Downtime sind tolerierbar"
• Bestimmt: Backup-Größe, Speicherort (lokal vs. Cloud), Restore-Verfahren

RPO (Recovery Point Objective)

Wie viel Datenverlust ist akzeptabel?

• Beispiel: "Maximal 15 Minuten Datenverlust sind tolerierbar"
• Bestimmt: Backup-Frequenz (wie oft Transaction Log Backups)

Backup-Strategien für verschiedene Szenarien

Strategie 1: Kleine Datenbank (< 10 GB), niedrige Änderungsrate

Profil: Unkritische Datenbank, z.B. internes Wiki, kleines CRM

• ✅ Full Backup: Täglich um 02:00 Uhr
• ✅ Differential Backup: Nicht notwendig
• ✅ Transaction Log Backup: Nicht notwendig (Simple Recovery Model)
• ✅ Retention: 7 Tage lokal, 30 Tage offsite

Recovery-Szenario: Datenverlust maximal 24 Stunden (bis letztes Full Backup)

Strategie 2: Mittlere Datenbank (10-100 GB), Standard-Business

Profil: ERP-System, CRM, Warenwirtschaft

• ✅ Full Backup: Sonntag 01:00 Uhr
• ✅ Differential Backup: Mo-Sa um 02:00 Uhr
• ✅ Transaction Log Backup: Stündlich (während Geschäftszeiten 07:00-19:00)
• ✅ Retention: 14 Tage lokal, 90 Tage offsite

Recovery-Szenario:

• Datenverlust maximal 1 Stunde (bis letztes Log Backup)
• Recovery benötigt: 1 Full + 1 Differential + alle Log Backups seit Differential

Strategie 3: Große Datenbank (> 100 GB), produktions-kritisch

Profil: E-Commerce-Datenbank, Finanzanwendung, Online-Services

• ✅ Full Backup: Täglich um 01:00 Uhr
• ✅ Differential Backup: Alle 6 Stunden (07:00, 13:00, 19:00)
• ✅ Transaction Log Backup: Alle 15 Minuten (24/7)
• ✅ Retention: 30 Tage lokal (Fast Storage), 1 Jahr offsite (Tape/Cloud)
• ✅ Zusätzlich: AlwaysOn Availability Groups für Failover

Recovery-Szenario:

• Datenverlust maximal 15 Minuten
• RTO: < 2 Stunden
• Failover auf Sekundär-Replika: < 30 Sekunden

T-SQL: Backup-Skripte in der Praxis

Full Backup erstellen

-- Full Backup einer Datenbank
BACKUP DATABASE [MeineDatenbank]
TO DISK = 'D:\Backups\MeineDatenbank_Full_20260115.bak'
WITH 
  FORMAT,                -- Überschreibt vorhandene Backup-Datei
  INIT,                  -- Initialisiert neues Backup-Set
  NAME = 'MeineDatenbank-Full Backup',
  SKIP,                  -- Überspringt Ablaufdatum-Prüfung
  NOREWIND,              -- Kein Tape-Rewind
  NOUNLOAD,              -- Medium bleibt geladen
  COMPRESSION,           -- Aktiviert Backup-Kompression
  STATS = 10;            -- Fortschrittsanzeige alle 10%

-- Backup-Informationen anzeigen
RESTORE HEADERONLY 
FROM DISK = 'D:\Backups\MeineDatenbank_Full_20260115.bak';

Differential Backup erstellen

-- Differential Backup (nur Änderungen seit letztem Full Backup)
BACKUP DATABASE [MeineDatenbank]
TO DISK = 'D:\Backups\MeineDatenbank_Diff_20260115_0200.bak'
WITH 
  DIFFERENTIAL,          -- Differential-Modus
  FORMAT,
  INIT,
  NAME = 'MeineDatenbank-Differential Backup',
  COMPRESSION,
  STATS = 10;

Transaction Log Backup erstellen

-- Transaction Log Backup
BACKUP LOG [MeineDatenbank]
TO DISK = 'D:\Backups\MeineDatenbank_Log_20260115_0800.trn'
WITH 
  FORMAT,
  INIT,
  NAME = 'MeineDatenbank-Transaction Log Backup',
  COMPRESSION,
  STATS = 10;

-- WICHTIG: Datenbank muss im FULL Recovery Model sein
ALTER DATABASE [MeineDatenbank] 
SET RECOVERY FULL;

Automatisierung mit SQL Server Agent Jobs

Manuelle Backups sind fehleranfällig. Nutzen Sie SQL Server Agent Jobs für Automatisierung:

1. SQL Server Management Studio (SSMS) öffnen
2. SQL Server Agent → Jobs → New Job
3. Job-Name: Daily_Full_Backup_MeineDatenbank
4. Steps → New → Type: Transact-SQL script
5. T-SQL Backup-Befehl einfügen
6. Schedules → New → Täglich um 01:00
7. Notifications → Email bei Fehler (Database Mail einrichten)

Recovery-Szenarien: So stellen Sie Daten wieder her

Szenario 1: Komplette Datenbank wiederherstellen (Full Backup)

-- Schritt 1: Datenbank in RESTORING-Modus versetzen (keine Verbindungen)
USE master;
GO

ALTER DATABASE [MeineDatenbank] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

-- Schritt 2: Full Backup wiederherstellen
RESTORE DATABASE [MeineDatenbank]
FROM DISK = 'D:\Backups\MeineDatenbank_Full_20260115.bak'
WITH 
  REPLACE,              -- Überschreibt vorhandene Datenbank
  RECOVERY;             -- Datenbank ist nach Restore online

-- Schritt 3: Datenbank wieder Multi-User
ALTER DATABASE [MeineDatenbank] SET MULTI_USER;
GO

Szenario 2: Full + Differential wiederherstellen

-- Schritt 1: Full Backup wiederherstellen (NORECOVERY = weitere Backups folgen)
RESTORE DATABASE [MeineDatenbank]
FROM DISK = 'D:\Backups\MeineDatenbank_Full_20260115.bak'
WITH 
  NORECOVERY,           -- Datenbank bleibt im RESTORING-Modus
  REPLACE;

-- Schritt 2: Differential Backup wiederherstellen
RESTORE DATABASE [MeineDatenbank]
FROM DISK = 'D:\Backups\MeineDatenbank_Diff_20260115_0200.bak'
WITH 
  RECOVERY;             -- Datenbank ist jetzt online

-- Ergebnis: Datenbank-Status wie um 02:00 Uhr (Differential-Zeitpunkt)

Szenario 3: Full + Differential + Transaction Logs (Point-in-Time Recovery)

-- Schritt 1: Full Backup wiederherstellen
RESTORE DATABASE [MeineDatenbank]
FROM DISK = 'D:\Backups\MeineDatenbank_Full_20260115.bak'
WITH NORECOVERY, REPLACE;

-- Schritt 2: Differential Backup wiederherstellen
RESTORE DATABASE [MeineDatenbank]
FROM DISK = 'D:\Backups\MeineDatenbank_Diff_20260115_0200.bak'
WITH NORECOVERY;

-- Schritt 3: Transaction Log Backups wiederherstellen (alle seit Differential)
RESTORE LOG [MeineDatenbank]
FROM DISK = 'D:\Backups\MeineDatenbank_Log_20260115_0800.trn'
WITH NORECOVERY;

RESTORE LOG [MeineDatenbank]
FROM DISK = 'D:\Backups\MeineDatenbank_Log_20260115_0815.trn'
WITH NORECOVERY;

RESTORE LOG [MeineDatenbank]
FROM DISK = 'D:\Backups\MeineDatenbank_Log_20260115_0830.trn'
WITH NORECOVERY;

-- Schritt 4: Datenbank auf spezifischen Zeitpunkt wiederherstellen
RESTORE LOG [MeineDatenbank]
FROM DISK = 'D:\Backups\MeineDatenbank_Log_20260115_0845.trn'
WITH RECOVERY,
     STOPAT = '2026-01-15 08:42:30';  -- Point-in-Time: genau 08:42:30 Uhr

-- Ergebnis: Datenbank-Status exakt wie am 15.01.2026 um 08:42:30 Uhr

Retention Policies: Wie lange aufbewahren?

Retention Policy definiert, wie lange Backups aufbewahrt werden. Balance zwischen Speicherkosten und Recovery-Möglichkeiten.

Typische Retention-Strategien:

Grandfather-Father-Son (GFS) Rotation

Bewährtes Rotations-Schema für langfristige Backup-Aufbewahrung:

• Son (Täglich): Letzte 7 Tage (tägliche Full/Differential Backups)
• Father (Wöchentlich): Letzte 4-5 Wochen (wöchentliche Full Backups, z.B. Sonntag)
• Grandfather (Monatlich): Letzten 12 Monate (monatliche Full Backups, z.B. erster Sonntag)
• Optional (Jährlich): Letzte 5-7 Jahre (Compliance-Archivierung)

Automatische Bereinigung alter Backups (T-SQL)

-- Löscht Backup-Dateien älter als 30 Tage
EXECUTE master.dbo.xp_delete_file 
  0,                                    -- Backup-Dateien (1 = Report-Dateien)
  N'D:\Backups',                        -- Backup-Verzeichnis
  N'bak',                               -- Dateierweiterung
  N'2026-01-01T00:00:00',               -- Dateien älter als dieses Datum
  1;                                    -- Unterordner einschließen

-- Alternativ: SQL Server Maintenance Plan "Cleanup Task"

Speicherorte: Lokal, Offsite, Cloud

Lokal (On-Premise Storage)

Vorteile:

• ✅ Schnellster Restore (Gigabit LAN)
• ✅ Volle Kontrolle
• ✅ Keine laufenden Cloud-Kosten
• ✅ DSGVO-konform (Daten bleiben in Deutschland)

Nachteile:

• ❌ Gefährdet bei Brand, Diebstahl, Naturkatastrophen
• ❌ Benötigt redundante Hardware (RAID, NAS)

Offsite (Externes Rechenzentrum, Tape)

Vorteile:

• ✅ Schutz vor lokalem Katastrophenfall
• ✅ Langfristige Archivierung (Tape = günstig für große Datenmengen)

Nachteile:

• ❌ Langsamer Restore (Transport erforderlich)
• ❌ Manuelle Prozesse (Tape-Handling)

Cloud (Azure Blob Storage, AWS S3, Wasabi)

Vorteile:

• ✅ Geografische Redundanz (automatische Replikation)
• ✅ Skalierbar (unbegrenzter Speicher)
• ✅ Automatisierbar (API-Integration)
• ✅ Kosteneffizient für Archiv-Tiers (z.B. Azure Cool/Archive Storage)

Nachteile:

• ❌ Laufende Kosten
• ❌ Restore dauert länger (Bandbreite-abhängig)
• ❌ DSGVO-Compliance prüfen (EU-Region wählen!)

Empfohlene Hybrid-Strategie:

• ✅ Lokal: Letzte 7-30 Tage (schneller Restore)
• ✅ Cloud/Offsite: Langzeit-Archiv (1-7 Jahre)
• ✅ 3-2-1-Regel beachten: 3 Kopien, 2 Medientypen, 1 Offsite

Backup-Testing: Testen oder scheitern

Eine nicht getestete Backup-Strategie ist wertlos! Viele Unternehmen merken erst im Ernstfall, dass:

• ❌ Backup-Dateien korrupt sind
• ❌ Restore-Prozesse nicht dokumentiert sind
• ❌ Restore länger dauert als erwartet (RTO nicht erfüllt)
• ❌ Berechtigungen fehlen (Restore scheitert an Permissions)

Backup-Test-Plan (Vierteljährlich durchführen):

1. Test-Restore durchführen:
   • Full Backup auf Test-Server wiederherstellen
   • Zeit stoppen (RTO-Check)
   • Datenbank-Integrität prüfen: DBCC CHECKDB
2. Point-in-Time Recovery testen:
   • Testdaten mit Zeitstempel einfügen
   • Log Backup erstellen
   • Restore auf spezifischen Zeitpunkt
   • Prüfen, ob Testdaten vorhanden/fehlen (je nach Zeitpunkt)
3. Disaster Recovery Drill:
   • Simuliere vollständigen Server-Ausfall
   • Restore auf komplett neuen Server
   • Alle Applikationen müssen funktionieren
4. Dokumentation aktualisieren:
   • Restore-Prozeduren schriftlich festhalten
   • Kontaktpersonen, Passwörter, Speicherorte dokumentieren

Häufige Backup-Fehler vermeiden

❌ Fehler 1: Backups auf gleicher Disk wie Datenbank

Problem: Festplatten-Crash = Datenbank UND Backup weg.

Lösung: Backups auf separate physische Disk/NAS/Cloud speichern.

❌ Fehler 2: Kein Transaction Log Backup trotz FULL Recovery Model

Problem: Transaction Log wächst unkontrolliert, füllt Festplatte.

Lösung: Bei FULL Recovery Model MUSS regelmäßig Log Backup erstellt werden!

-- Check Recovery Model
SELECT name, recovery_model_desc
FROM sys.databases
WHERE name = 'MeineDatenbank';

-- Auf SIMPLE umstellen (wenn Log Backups nicht benötigt)
ALTER DATABASE [MeineDatenbank] SET RECOVERY SIMPLE;

❌ Fehler 3: Keine Backup-Verschlüsselung

Problem: Backup-Dateien enthalten sensible Daten unverschlüsselt.

Lösung: SQL Server Backup-Verschlüsselung nutzen (ab SQL Server 2014).

-- Backup mit Verschlüsselung (AES 256)
BACKUP DATABASE [MeineDatenbank]
TO DISK = 'D:\Backups\MeineDatenbank_Full_Encrypted.bak'
WITH 
  COMPRESSION,
  ENCRYPTION (
    ALGORITHM = AES_256,
    SERVER CERTIFICATE = MyCertificate
  );

❌ Fehler 4: Keine Monitoring & Alerting

Problem: Backups schlagen fehl, aber niemand bemerkt es.

Lösung: SQL Server Agent Email-Benachrichtigungen + Monitoring-Tool (z.B. SQL Sentry, Redgate SQL Monitor).

Best Practices: Checkliste

Fazit: Backup ist Pflicht, Recovery ist König

Eine professionelle MSSQL Backup-Strategie ist Lebensversicherung für Ihre Daten. Datenverlust kann existenzbedrohend sein – investieren Sie Zeit in eine solide Backup-Infrastruktur.

Die wichtigsten Takeaways:

• ✅ Definieren Sie RTO & RPO (Basis jeder Backup-Strategie)
• ✅ Kombinieren Sie Full, Differential und Log Backups richtig
• ✅ Automatisieren Sie Backups (SQL Server Agent)
• ✅ Speichern Sie Backups redundant (lokal + offsite/cloud)
• ✅ Testen Sie Restore vierteljährlich (oder scheitern im Ernstfall)
• ✅ Monitoring ist Pflicht (sofortige Benachrichtigung bei Fehlern)