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