SQL Server Database Snapshots – Wann, wo, wozu? Ein Praxisratgeber

📸 SQL Server Database Snapshots – Wann, wo, wozu?

📅 14. Mai 2025 ✍️ Erfahrener SQL Server DBA ⏱ 8 Min. Lesezeit

1. Was ist ein Database Snapshot?

Ein Database Snapshot ist eine schreibgeschützte, zeitpunktbezogene Sicht auf eine Quelldatenbank. Es ist kein vollständiges Backup, sondern eine effiziente Methode, um den Zustand einer Datenbank zu einem bestimmten Zeitpunkt einzufrieren. Die Technik nutzt einen Mechanismus namens „Copy-on-Write“: Wenn sich in der Quelldatenbank eine Seite ändert, wird die ursprüngliche Seite in den Snapshot kopiert. So ist der Snapshot immer der Zustand zum Zeitpunkt seiner Erstellung – unabhängig von späteren Änderungen in der Quelle. Ein Snapshot ist nur auf demselben SQL Server-Instance wie die Quell-Datenbank verfügbar.

💡 Kernidee: Ein Snapshot ist kein Backup im klassischen Sinne, sondern eher ein „Zeitfenster“ auf Ihre Daten – ideal für schnelle Tests oder für UNDO-Operationen nach einer versehentlichen Datenänderung.

2. Erstellung und Verwaltung eines Snapshots

Die Erstellung ist denkbar einfach: Sie brauchen nur einen Namen und den Pfad für die Snapshot-Dateien. Die Syntax lautet:

CREATE DATABASE SnapshotName ON 
(NAME = LogicalFileName, FILENAME = 'Pfad\SnapshotFile.ss') 
AS SNAPSHOT OF SourceDatabase;

Ein vollständiges Beispiel:

CREATE DATABASE Sales_SS_20250514 ON 
(NAME = Sales_Data, FILENAME = 'D:\Data\Sales_SS_20250514.ss') 
AS SNAPSHOT OF SalesDB;

Sie können einen Snapshot über den SSMS-Objekt-Explorer (unter „Database Snapshots“) anzeigen oder mit SELECT * FROM sys.databases WHERE source_database_id IS NOT NULL abfragen. Das Löschen eines Snapshots erfolgt mit dem vertrauten DROP DATABASE SnapshotName. Beim Löschen werden automatisch die Snapshot-Dateien von der Festplatte entfernt.

3. Typische Einsatzszenarien (Wozu?)

🛡️ Schnelle Wiederherstellung bei Benutzerfehlern

Stellen Sie sich vor, ein Benutzer löscht versehentlich eine ganze Tabelle oder führt eine falsche UPDATE-Anweisung aus. Haben Sie einen Snapshot von vor dem Fehler, können Sie die betroffenen Daten in wenigen Sekunden zurückspielen, indem Sie die Daten aus dem Snapshot in die Quelldatenbank kopieren. Das ist oft viel schneller als ein Restore aus einem Backup, der die ganze Datenbank neu aufbauen würde.

🧪 Tests und Berichterstellung

Sie können einen Snapshot erstellen und dann in einer sicheren, schreibgeschützten Umgebung Abfragen testen, Daten analysieren oder komplexe Berichte laufen lassen, ohne die Produktionsdaten zu belasten oder zu verändern. Da der Snapshot keinerlei Schreiboperationen erlaubt, ist das Risiko einer unbeabsichtigten Änderung gleich null.

📊 Historische Auswertungen (Time Travel)

Möchten Sie den Stand Ihrer Datenbank zu einem bestimmten Stichtag (z. B. Monatsende, Quartalsende) haben? Ein Snapshot konserviert genau diesen Zustand. Sie können jederzeit darauf zugreifen, ohne dass Sie ein großes Backup wiederherstellen müssen.

💡 Best Practice: Erstellen Sie regelmäßig Snapshots vor großen Wartungsfenstern oder riskanten Skripten. Dann können Sie im Fehlerfall im Handumdrehen den vorherigen Zustand wiederherstellen.

4. Einschränkungen und Fallstricke (Wo NICHT?)

🚨 Keine Sicherung im Disaster-Recovery-Sinn: Ein Snapshot liegt immer auf demselben Speichersystem wie die Quelldatenbank. Bei einem Festplattencrash oder einem kompletten Serverausfall sind alle Snapshots ebenfalls verloren. Für Disaster Recovery benötigen Sie weiterhin klassische Backups (voll, differentiell, Log).

Schreibgeschützt: Sie können einen Snapshot nicht ändern. Er dient nur für SELECT-Abfragen oder als Quelle für einen Datenwiederherstellungsprozess.
Abhängigkeit von der Quelldatenbank: Wird die Quelldatenbank gelöscht, sind alle zugehörigen Snapshots unbrauchbar.
Speicherplatz: Ein Snapshot wächst mit jeder Änderung in der Quelldatenbank. Je mehr sich die Quelle ändert, desto größer wird der Snapshot. Er kann sogar größer werden als die Quelldatenbank selbst (wenn jede Seite einmal geändert wurde). Planen Sie ausreichend Platz auf dem Volume ein.
Leistungseinbußen: Copy-on-Write verursacht einen geringen zusätzlichen I/O-Aufwand bei Schreiboperationen in der Quelldatenbank. Bei sehr hohen Schreiblasten kann dies spürbar sein. Setzen Sie Snapshots daher nicht auf Systemen ein, die extrem schreibintensiv sind.
Nicht für alle Editionen: Database Snapshots werden nur in der Enterprise-, Developer- und Standard-Edition (ab SQL Server 2016 SP1) unterstützt. In der Express Edition sind sie nicht verfügbar.

5. Praktisches Beispiel: Daten aus Snapshot wiederherstellen

Angenommen, Sie haben vor einer riskanten Löschung einen Snapshot erstellt. Der Benutzer löscht fälschlich alle Zeilen aus der Tabelle Sales.Orders. So holen Sie die Daten aus dem Snapshot zurück:

-- 1. Fehlerhafte Daten in der Quelle sichern (optional) 
SELECT * INTO Sales.Orders_Backup FROM Sales.Orders; 
 
-- 2. Daten aus dem Snapshot in die Quelle kopieren 
INSERT INTO Sales.Orders 
SELECT * FROM Sales_SS_20250514.Sales.Orders; 
 
-- 3. Oder: gesamte Tabelle ersetzen (falls Constraints es erlauben) 
TRUNCATE TABLE Sales.Orders; 
INSERT INTO Sales.Orders 
SELECT * FROM Sales_SS_20250514.Sales.Orders;

⚠️ Achtung: Wenn zwischenzeitlich neue Daten in die Tabelle eingefügt wurden, gehen diese beim Ersetzen verloren. Seien Sie sicher, dass Sie wirklich den Snapshot-Stand wiederherstellen wollen.

6. Überwachung und Platzverbrauch

Mit diesen Abfragen behalten Sie den Speicherplatz Ihrer Snapshots im Auge:

-- Alle Snapshots und deren Größe anzeigen 
SELECT  
s.name AS SnapshotName, 
s.source_database_id, 
mf.physical_name, 
mf.size * 8 / 1024 AS SizeMB 
FROM sys.databases s 
JOIN sys.master_files mf ON s.database_id = mf.database_id 
WHERE s.source_database_id IS NOT NULL; 
 
-- Snapshot-Speicherplatz in der tempdb-relevanten DMV 
SELECT * FROM sys.dm_io_virtual_file_stats(NULL, NULL);

💡 Tipp: Löschen Sie nicht mehr benötigte Snapshots umgehend, um Speicherplatz freizugeben. Ein Snapshot, der über Wochen läuft, kann die Festplatte füllen und die Performance der Quelldatenbank beeinträchtigen.

7. Alternativen: Wann besser Backup, Replikation oder Always On?

Backup (voll, diff, log): Wenn Sie eine langfristige, historische Wiederherstellbarkeit benötigen, die über den Verlust der lokalen Festplatte hinausgeht. Snapshots ersetzen keine Backups!
Always On Availability Groups: Für Hochverfügbarkeit und Disaster Recovery mit automatischem Failover. Snapshots bieten keine Redundanz über verschiedene Server.
Replikation / Transactional Replication: Wenn Sie Daten auf andere Server verteilen möchten, die dann auch beschreibbar sein sollen. Ein Snapshot ist nur lesbar.
Temporal Tables (System-Versioned): Eine moderne Alternative, wenn Sie historische Daten über lange Zeiträume lückenlos nachverfolgen wollen. Snapshots sind punktuell, Temporal Tables automatisiert.

💡 Faustregel: Verwenden Sie Snapshots für kurzlebige, schnelle Wiederherstellungen (z. B. vor einem riskanten Update) oder für Test-/Reporting-Zwecke. Für langfristige Sicherheit bleiben Sie bei klassischen Backups.

8. Fazit – Database Snapshots richtig nutzen

Database Snapshots sind ein unterschätztes, aber extrem nützliches Feature für DBAs und Entwickler. Sie ermöglichen:

Schnelles UNDO von unbeabsichtigten Änderungen (DML-Fehler).
Sichere Testumgebungen mit produktionsnahen Daten.
Zeitreisen für Berichte oder Audits.

Die Kehrseite: Snapshots verbrauchen Speicherplatz, verursachen minimale I/O-Last und sind kein Ersatz für Backups. Nutzen Sie sie gezielt vor riskanten Aktionen oder für kurzfristige Analysen – dann werden sie zu Ihrem besten Freund im Admin‑Alltag.