SQL Server Backup-Strategien
FULL, DIFF, LOG – RPO & RTO

Grundlagen – Warum Backups mehr als Pflicht sind

Ein SQL Server-Backup ist nicht nur eine gesetzliche oder regulatorische Anforderung – es ist die einzige verlässliche Absicherung gegen Datenverlust durch Hardware-Ausfall, menschliche Fehler, Ransomware oder logische Datenbankkorruption. AlwaysOn Availability Groups schützen vor Ausfällen, aber sie replizieren auch Fehler in Echtzeit. Ein Backup ist unersetzlich.

Die drei Backup-Säulen auf einen Blick

Recovery-Modelle – Die Basis der Strategie

Das Recovery-Modell einer Datenbank bestimmt, welche Backup-Typen möglich sind und wie das Transaktionsprotokoll verwaltet wird. Es ist die wichtigste Einstellung vor jeder Backup-Planung.

-- Recovery-Modell aller Datenbanken anzeigen
SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
ORDER BY name;

-- Auf FULL umstellen (Produktionsdatenbank)
ALTER DATABASE [AppDB] SET RECOVERY FULL;

-- Wichtig: Danach sofort ein FULL-Backup erzeugen!
-- Erst ab dem ersten FULL-Backup nach der Umstellung
-- beginnt die vollständige LOG-Kette.
BACKUP DATABASE [AppDB]
  TO DISK = N'D:\Backup\AppDB_FULL.bak'
  WITH COMPRESSION, STATS = 10;

Backup-Typen im Detail

FULL Backup – Die Basis

Ein FULL Backup enthält alle Datenbankseiten zum Zeitpunkt des Backups sowie alle während des Backup-Vorgangs angefallenen Transaktionen. Es ist self-contained – ein Restore ist ohne weitere Dateien möglich.

DIFFERENTIAL Backup – Der intelligente Mittelweg

Ein DIFFERENTIAL Backup sichert alle seit dem letzten FULL geänderten Datenbank-Extents (8 Seiten). Es ist kumulativ – jedes neue DIFF enthält alle Änderungen seit dem letzten FULL, nicht nur seit dem letzten DIFF. Das vereinfacht den Restore erheblich.

LOG Backup – Point-in-Time und Log-Kürzung

Das Transaction Log Backup sichert alle seit dem letzten LOG-Backup angefallenen Log-Einträge. Es ist das Herzstück jeder professionellen Backup-Strategie: Es ermöglicht die Wiederherstellung auf jeden beliebigen Zeitpunkt und ist die einzige Methode, das Transaktionslog zu kürzen.

-- FULL Backup mit Kompression und Prüfsumme
BACKUP DATABASE [AppDB]
  TO DISK = N'\\backup-srv\SQL\AppDB\FULL\AppDB_20250425.bak'
  WITH
    COMPRESSION,
    CHECKSUM,
    STATS = 5,
    NAME = N'AppDB – FULL – 2025-04-25';

-- DIFFERENTIAL Backup
BACKUP DATABASE [AppDB]
  TO DISK = N'\\backup-srv\SQL\AppDB\DIFF\AppDB_diff_20250425_1200.bak'
  WITH DIFFERENTIAL, COMPRESSION, CHECKSUM, STATS = 5;

-- LOG Backup (kürzt auch das Transaktionslog)
BACKUP LOG [AppDB]
  TO DISK = N'\\backup-srv\SQL\AppDB\LOG\AppDB_log_20250425_1215.trn'
  WITH COMPRESSION, CHECKSUM, STATS = 10;

-- COPY_ONLY FULL – bricht LOG-Kette NICHT
-- Ideal fuer Ad-hoc-Backups, Tests, Migrationen
BACKUP DATABASE [AppDB]
  TO DISK = N'D:\Temp\AppDB_copy_only.bak'
  WITH COPY_ONLY, COMPRESSION, CHECKSUM;

RPO & RTO – Die entscheidenden Kennzahlen

Bevor eine Backup-Strategie festgelegt wird, müssen zwei Fragen mit dem Business beantwortet werden. Die Antworten definieren direkt, welche Backup-Typen und -Frequenzen nötig sind.

RPO / RTO Visualisierung – Typische Backup-Kette

RPO / RTO – Strategie-Matrix nach Anforderung

Backup-Strategien für die Praxis

Strategie A – Kleine bis mittlere Datenbanken (< 100 GB)

Strategie B – Große Datenbanken (100 GB – 1 TB)

Strategie C – VLDB (Very Large Databases, > 1 TB)

-- Backup auf 4 parallele Dateien aufteilen – bis zu 4x schneller
BACKUP DATABASE [VeryLargeDB]
  TO
    DISK = N'\\backup01\SQL\VLDB_1.bak',
    DISK = N'\\backup02\SQL\VLDB_2.bak',
    DISK = N'\\backup03\SQL\VLDB_3.bak',
    DISK = N'\\backup04\SQL\VLDB_4.bak'
  WITH
    COMPRESSION,
    CHECKSUM,
    MAXTRANSFERSIZE = 4194304, -- 4 MB (optimal fuer grosse DBs)
    BUFFERCOUNT = 50,
    STATS = 1;

Backup-Validierung – Pflicht, keine Kür

Ein Backup das nie getestet wurde, ist kein Backup. Die CHECKSUM-Option erkennt Korruption beim Schreiben – aber nur ein vollständiger Restore-Test beweist die Wiederherstellbarkeit.

-- Backup-Datei auf Integrität prüfen (ohne Restore)
RESTORE VERIFYONLY
  FROM DISK = N'\\backup-srv\SQL\AppDB\FULL\AppDB_20250425.bak'
  WITH CHECKSUM;

-- Backup-Header auslesen (Inhalt, Zeitstempel, LSN)
RESTORE HEADERONLY
  FROM DISK = N'\\backup-srv\SQL\AppDB\FULL\AppDB_20250425.bak';

-- Dateien im Backup auflisten
RESTORE FILELISTONLY
  FROM DISK = N'\\backup-srv\SQL\AppDB\FULL\AppDB_20250425.bak';

-- Point-in-Time Restore (auf Testserver!)
RESTORE DATABASE [AppDB_Test]
  FROM DISK = N'\\backup-srv\SQL\AppDB\FULL\AppDB_20250425.bak'
  WITH NORECOVERY, MOVE N'AppDB' TO N'D:\Data\AppDB_Test.mdf',
     MOVE N'AppDB_log' TO N'E:\Log\AppDB_Test_log.ldf';

RESTORE LOG [AppDB_Test]
  FROM DISK = N'\\backup-srv\SQL\AppDB\LOG\AppDB_log_20250425_1215.trn'
  WITH NORECOVERY;

-- Letztes LOG: RECOVERY = Datenbank online bringen
RESTORE LOG [AppDB_Test]
  FROM DISK = N'\\backup-srv\SQL\AppDB\LOG\AppDB_log_20250425_1300.trn'
  WITH RECOVERY, STOPAT = N'2025-04-25T12:47:00';

AlwaysOn & Backup – Optimierung durch Replikate

Availability Groups bieten eine der wirkungsvollsten Backup-Optimierungen: Die I/O-Last des Backups kann vollständig vom Primär-Replikat auf ein Sekundär verlagert werden. Das entlastet den produktiven Primary und nutzt das passive Replikat aktiv.

Backup-Präferenz in der AG konfigurieren

Wichtige Einschränkungen bei AG-Backups

-- AG Backup-Präferenz setzen
ALTER AVAILABILITY GROUP [AG_PROD]
  SET (AUTOMATED_BACKUP_PREFERENCE = PREFER_SECONDARY);

-- Prüfen ob aktueller Knoten das bevorzugte Backup-Replikat ist
-- (in Backup-Jobs verwenden – verhindert doppelte Backups)
IF (sys.fn_hadr_backup_is_preferred_replica(N'AppDB') = 1)
BEGIN
  BACKUP LOG [AppDB]
    TO DISK = N'\\backup-srv\SQL\AppDB\LOG\AppDB_log.trn'
    WITH COMPRESSION, CHECKSUM;
  PRINT N'LOG-Backup auf bevorzugtem Replikat durchgefuehrt.';
END
ELSE
  PRINT N'Dieses Replikat ist nicht bevorzugt – kein Backup.';

-- Replikat-Backup-Status prüfen (dbaTools)
Get-DbaAgReplica -SqlInstance "SQL-NODE1" -AvailabilityGroup "AG_PROD" |
  Select-Object Name, Role, BackupPriority, AutomatedBackupPreference

Tail-Log Backup – Der letzte Rettungsanker

Bei einem Ausfall des Primary-Replikats und noch erreichbarem Datenbankfile kann ein Tail-Log Backup die zuletzt verbuchten Transaktionen sichern, bevor der Failover vollzogen wird. Dieses Backup enthält alles seit dem letzten regulären LOG-Backup.

-- Tail-Log sichern wenn Datenbank noch erreichbar aber beschaedigt
-- NO_TRUNCATE: sichert auch wenn Daten-Dateien beschaedigt sind
BACKUP LOG [AppDB]
  TO DISK = N'\\backup-srv\SQL\AppDB\LOG\AppDB_TAILLOG_emergency.trn'
  WITH
    NO_TRUNCATE, -- Auch bei beschaedigten Datendateien
    NORECOVERY, -- Datenbank geht in Restoring-Status
    CHECKSUM;

-- Danach: Restore-Kette auf Standby/DR-Server abschliessen

Automatisierung mit dbaTools

dbaTools bietet mit Backup-DbaDatabase und dem Ola-Hallengren-kompatiblen Invoke-DbaDbLogShipping eine vollständige Backup-Automatisierung. Besonders hilfreich ist die integrierte AG-Awareness: Backups werden automatisch auf dem bevorzugten Replikat ausgeführt.

# FULL Backup aller Benutzerdatenbanken mit Kompression
Backup-DbaDatabase -SqlInstance "SQL-NODE1" `
  -Type Full `
  -Path "\\backup-srv\SQL" `
  -CompressBackup `
  -Checksum `
  -Verify `
  -ExcludeDatabase "tempdb"

# LOG-Backup mit AG-Awareness (bevorzugtes Replikat)
Backup-DbaDatabase -SqlInstance "SQL-NODE1", "SQL-NODE2" `
  -Type Log `
  -Path "\\backup-srv\SQL\LOG" `
  -CompressBackup `
  -Checksum `
  -AzureBaseUrl "" # optional: direkt nach Azure

# Backup-History der letzten 7 Tage anzeigen
Get-DbaDbBackupHistory -SqlInstance "SQL-NODE1" `
  -Since (Get-Date).AddDays(-7) |
  Select-Object Database, Type, Start, End, TotalSize, CompressedBackupSize |
  Sort-Object Start -Descending

# Letzte Backup-Zeit pro Datenbank – sofort sehen welche fehlen
Get-DbaLastBackup -SqlInstance "SQL-NODE1" |
  Select-Object Name, RecoveryModel,
    LastFullBackup, LastDiffBackup, LastLogBackup |
  Where-Object { $_.LastFullBackup -lt (Get-Date).AddDays(-1) }

# Backup-Datei verifizieren (ohne Restore)
Test-DbaLastBackup -SqlInstance "SQL-NODE1" `
  -Database "AppDB" `
  -Destination "SQL-TEST01" # Restore auf Testserver!

# Ola Hallengren Maintenance Solution installieren
Install-DbaMaintenanceSolution -SqlInstance "SQL-NODE1" `
  -Database "DBAMaintenance" `
  -BackupLocation "\\backup-srv\SQL" `
  -InstallJobs `
  -LogToTable

Backup-Monitoring – Was überwacht werden muss