SQL Server Recovery Model: Das richtige Modell für deine Datenbanken finden

Die Wahl des richtigen Recovery Models für eine SQL Server-Datenbank ist entscheidend für Datensicherheit, Wiederherstellungsstrategien und Performance. Doch welches Recovery Model ist das richtige für deine Anwendung? „Full“, „Simple“ oder „Bulk-Logged“? Die Antwort hängt von mehreren Faktoren ab – in diesem Beitrag zeige ich dir, worauf du achten, mit wem du sprechen solltest und wie du eine optimale Backup-Strategie entwickelst.

1. Warum das Recovery Model wichtig ist

Das Recovery Model bestimmt, wie SQL Server mit Transaktionsprotokollen umgeht und welche Backup- und Wiederherstellungsoptionen verfügbar sind.

Wichtige Fragen zur Auswahl:

• Wie wichtig ist Datenverlustminimierung für dein Unternehmen?
• Welche Wiederherstellungszeit ist akzeptabel?
• Wie oft ändern sich Daten in der Datenbank?
• Gibt es gesetzliche oder Compliance-Anforderungen für Datenaufbewahrung?

Beteiligte Parteien:

• Datenbankadministratoren (DBA): Umsetzung der Backup-Strategie
• IT-Management: Entscheidung über Wiederherstellungsrichtlinien
• Geschäftsführung: Anforderungen an Verfügbarkeit und Datenverlust
• Auditoren/Compliance-Teams: Vorschriften zur Datenaufbewahrung und -sicherung

2. Die drei Recovery-Modelle im Vergleich

Welche Werte sind wichtig?

• RPO (Recovery Point Objective): Wie viel Datenverlust ist akzeptabel?
• RTO (Recovery Time Objective): Wie schnell muss das System nach einem Ausfall wieder verfügbar sein?

Tipp: Falls dein Unternehmen strikte Datenverlust-Anforderungen hat, solltest du unbedingt FULL als Recovery Model wählen und Transaktionsprotokoll-Backups regelmäßig durchführen.

3. Beispielhafte Backup-Strategie für ein sicheres Recovery

Eine optimale Backup-Strategie hängt von der Datenbankgröße, Transaktionshäufigkeit und Recovery-Anforderungen ab. Hier ein Beispiel für eine produktive OLTP-Datenbank mit FULL Recovery Model:

Backup-Zeitplan:

Weil es sich so problemlos einsetzen lässt und auf sehr viele (dynamische) Situationen eigenständig eingehen kann, empfehle ich die Nutzung der Ola Hallengren Wartungs-Skripte.

• Samstag, 03:00 Uhr: Full Backup (komplette Datenbanksicherung)
• Täglich, 12:00 & 18:00 Uhr: Differential Backup (nur geänderte Daten seit letztem Full Backup)
• Alle 2 Stunden: Transaction Log Backup (ermöglicht Point-in-Time Recovery)
• Externe Speicherung: Backup-Kopie auf Cloud- oder Offsite-Speicher

-- Full Backup (Samstags)
EXECUTE dbo.DatabaseBackup
   @Databases = 'USER_DATABASES',
   @Directory = 'D:\Backup',
   @BackupType = 'FULL',
   @Verify = 'Y',
   @Compress = 'Y',
   @CheckSum = 'Y',
   @CleanupTime = 24

-- Differential Backup (täglich)
EXECUTE dbo.DatabaseBackup
   @Databases = 'USER_DATABASES',
   @Directory = 'D:\Backup',
   @BackupType = 'DIFF',
   @Verify = 'Y',
   @Compress = 'Y',
   @CheckSum = 'Y',
   @CleanupTime = 24

-- Transaction Log Backup (alle 2 Stunden)
EXECUTE dbo.DatabaseBackup
   @Databases = 'USER_DATABASES',
   @Directory = 'D:\Backup',
   @BackupType = 'LOG',
   @Verify = 'Y',
   @Compress = 'Y',
   @CheckSum = 'Y',
   @CleanupTime = 24

Hinweis: Falls dein Unternehmen eine 3rd-Party Backup-Software wie Veeam, Commvault oder Rubrik nutzt, stelle sicher, dass sie SQL Server aware ist und mit Transaktionsprotokollen korrekt umgeht.

4. Wichtige Überlegungen zur Recovery-Strategie

Dinge, die oft übersehen werden:

• Backup-Retention: Wie lange müssen Backups aufbewahrt werden?
• Testen der Wiederherstellung: Ein Backup ist nutzlos, wenn du es nicht zurückspielen kannst!
• Monitoring & Alerts: Stelle sicher, dass Backup-Fehler sofort gemeldet werden:
  EXEC msdb.dbo.sp_add_alert @name = 'Backup Failed', @message_id = 18210, @severity = 16, @notification_message = 'Backup fehlgeschlagen!';
• Speicherplatzmanagement: Überwache Backup-Größen, um Speicherengpässe zu vermeiden.

Tipp: Simuliere regelmäßig Disaster Recovery-Szenarien, um sicherzustellen, dass dein Team im Ernstfall weiß, was zu tun ist.

Fazit: Das richtige Recovery Model sichert deine Daten

Die Wahl des passenden Recovery Models ist keine einmalige Entscheidung – sie muss regelmäßig an Geschäftsanforderungen angepasst werden.

• FULL Recovery Model für produktive, transaktionsintensive Systeme
• SIMPLE Recovery Model für nicht kritische Testumgebungen
• BULK-LOGGED für große Datenimporte
• Regelmäßige Backups mit einem durchdachten Zeitplan
• Monitoring & regelmäßige Tests der Wiederherstellung

Hast du Fragen oder nutzt du spezielle Backup-Strategien in deinem Unternehmen? Lass es mich wissen!

Björn Peters

Björn arbeitet auch weiterhin aus Griechenland als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.