Database Snapshots

In der Softwareentwicklung gibt es Situationen, in denen man sich einen Knopfdruck zum Einfrieren der Zeit wünscht – zum Beispiel kurz vor einem riskanten Deployment oder einem komplexen Datenupdate. Mit Database Snapshots bietet SQL Server genau das: eine einfache Möglichkeit, den Zustand einer Datenbank zu sichern und später ohne Mehraufwand zu analysieren oder exakt wiederherzustellen. Snapshots sind schnell, ressourcenschonend und bieten einen echten Mehrwert für Entwickler und Administratoren, die Datenintegrität und Experimentierfreude miteinander vereinbaren wollen.

Was sind Database Snapshots?

Ein Database Snapshot ist eine schreibgeschützte Momentaufnahme einer Datenbank zu einem bestimmten Zeitpunkt. Anders als bei einem klassischen Backup wird dabei keine vollständige Kopie erstellt. Stattdessen nutzt der SQL Server ein sogenanntes Copy-on-Write-Verfahren. Das bedeutet: Erst wenn eine Datenseite in der Originaldatenbank verändert wird, speichert der Snapshot die alte Version. Damit bleiben Snapshots kompakt und schnell – ideal für kurzfristige Sicherungen oder Testzwecke (Bild 1).

Zur Erinnerung: Datenseiten sind 8 KB groß und stellen die kleinste Einheit da, mit der der SQL Server arbeitet. In ihnen werden alle Arten von Daten verwaltet, sowohl Tabelleninhalte als auch Strukturen, Indizes et cetera. Kurzum: alles.

Snapshots sind eine Momentaufnahme – Backups sind Überlebensversicherung

So praktisch Database Snapshots auch sind – sie dürfen niemals(!) mit einem Backup verwechselt werden. Ein Snapshot schützt nur vor kurzfristigen oder logischen Fehlern, nicht vor Hardwareausfällen, Dateibeschädigungen oder versehentlichem Löschen der Originaldatenbank. Wenn die zugrunde liegende Datenbankdatei beschädigt wird, ist auch der Snapshot verloren, da er auf dieselben physischen Datenseiten verweist.

Snapshots eignen sich hervorragend für temporäre Sicherungen, zum Beispiel vor einem Deployment, nicht jedoch für langfristige Datensicherung oder Desaster-Recovery.

Ein vollständiges Backup-Konzept mit regelmäßigen Full-, Differential- und Log-Backups bleibt daher zwingend erforderlich – nur so lassen sich Daten auch nach einem Systemausfall oder Laufwerksverlust zuverlässig wiederherstellen.

Anwendungsfälle in der Praxis

In der Praxis lassen sich Database Snapshots in einigen interessanten Szenarien nutzen:

• Sicheres Testen von Deployments: Vor einem Versionswechsel oder Schema-Update genügt ein kurzer Snapshot-Befehl. Falls das Update fehlschlägt, kann der ursprüngliche Zustand innerhalb weniger Sekunden wiederhergestellt werden.
• Auditing und Reporting: Snapshots sind hilfreich, um Monats- oder Quartalsstände festzuhalten. Berichte und Prüfungen laufen auf einem unveränderten, konsistenten Datenstand – unabhängig von laufenden Transaktionen.
• Fehleranalyse und Datenvergleich: Nach einer Änderung lässt sich leicht nachvollziehen, welche Datensätze betroffen sind. Mit einfachen JOINs zwischen Live- und Snapshot-Datenbanken kann man Unterschiede prüfen. Eine weitere Alternative wäre ein Vergleich von Schema oder Inhalt mittels Visual Studio und dessen SQL Server Data Tools (SSDT).

Erstellen eines Snapshots

Ein Snapshot lässt sich mit einem einzigen SQL-Befehl erzeugen. Dafür muss jede Datendatei der Datenbank aufgeführt werden und eine Snapshot-Datei zugewiesen bekommen. Relevant ist hier der logische Name der Datei(en).

CREATE DATABASE SalesDB_Snapshot 
ON (NAME = SalesDB, FILENAME = 'D:\Snapshots\SalesDB.snapshot') 
AS SNAPSHOT OF SalesDB;

Welche Dateien das bei einer Datenbank konkret sind, lässt sich über die Eigenschaften oder einem Aufruf von sp_helpfile herausfinden. Der gesamte Vorgang dauert meist nur Sekunden oder weniger, da keine Kopie aller Daten erfolgt. SQL Server erstellt intern eine Sparse-Datei (.snapshot), die nur geänderte Seiten aufnimmt.

Snapshots unter Windows und Linux

SQL Server unterstützt Database Snapshots sowohl unter Windows als auch unter Linux. Das Verhalten ist weitgehend identisch, es gibt jedoch die üblichen Unterschiede bei Pfadangaben, Berechtigungen und Automatisierung.

Unter Windows werden Snapshot-Dateien auf NTFS-Volumes gespeichert. Die weiter oben bereits behandelte T-SQL-Anweisung zeigt, wie ein Snapshot unter diesem Betriebssystem angelegt wird (Bild 2). 

Unter Linux wird das gleiche Prinzip auf Ext4- oder XFS-Dateisystemen verwendet. Dabei sieht deren Pfad systemtypisch anders aus.

CREATE DATABASE SalesDB_Snapshot
ON (NAME = SalesDB, FILENAME = '/var/opt/mssql/data/SalesDB.snapshot')
AS SNAPSHOT OF SalesDB;

Wichtig ist dabei, dass Snapshots nicht auf Netzlaufwerken liegen dürfen. Und der Name darf nicht schon von einem anderen Snapshot oder einer Datenbank auf der Instanz verwendet werden.

Arbeiten mit Snapshots

Ein Snapshot verhält sich wie eine normale Datenbank – mit einem entscheidenden Unterschied: Er ist schreibgeschützt. Abfragen sind jedoch problemlos möglich. Um zu erkennen, ob man es mit einer Datenbank oder nur mit einem Snapshot zu tun hat, hilft zum Beispiel ein Blick in das SQL Server Management Studio (Database | Database Snapshots) oder eine T-SQL-Abfrage auf sys.databases. Ist hier die Spalte source_database_id nicht NULL, handelt es sich um einen Snapshot und die ID ist die der Original-Datenbank.

SELECT * FROM sys.databases;

Rollback per Snapshot

Der eigentliche Zauber der Snapshots zeigt sich im Rollback. Wenn zum Beispiel ein Deployment fehlschlägt, kann die Datenbank über einen Restore-Befehl auf den exakten Zustand zum Zeitpunkt des Snapshots zurückgesetzt werden. Hierfür kommt die RESTORE DATABASE zum Einsatz. Die beiden anderen voranstehenden Anweisungen in dem folgenden Beispiel sind nicht notwendig, aber praktisch: Sie beenden alle Sessions zu der Original-Datenbank; dies ist eine Voraussetzung für das Rollback.

USE MASTER;
ALTER DATABASE SalesDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
RESTORE DATABASE SalesDB FROM DATABASE_SNAPSHOT = 'SalesDB_Snapshot';

Die Dauer der Ausführung hängt dabei vom Umfang der vorgenommenen Änderungen an der Original-Datenbank seit Erstellung des Snapshots ab.

Snapshot löschen

Wird ein Snapshot nicht mehr benötigt, so kann er einfach mit der DROP DATABASE-Anweisung gelöscht werden. Eine eigene Anweisung speziell für Snapshots existiert nicht.

DROP DATABASE SalesDB FROM DATABASE_SNAPSHOT = 'SalesDB_Snapshot';

Technischer Hintergrund

Intern arbeitet der SQL Server mit einem Copy-on-Write-Mechanismus. Beim Erstellen eines Snapshots werden keine Daten verschoben. Erst wenn sich eine Seite (8 KB) in der Originaldatenbank ändert, schreibt SQL Server die alte Version in die Snapshot-Datei (Bild 3). Lesen aus der Snapshot-Datenbank bedeutet also: Wenn eine Seite verändert wurde, kommt er aus der .snapshot-Datei – ansonsten direkt aus der original MDF/NDF-Datei.

Performance und Grenzen

Database Snapshots sind effizient, weil sie nur geänderte Daten speichern. Dennoch sollte man einige Grenzen beachten:

• Snapshots sind nicht schreibbar und können nicht gesichert oder repliziert werden.
• Bei vielen Änderungen wächst die .snapshot-Datei schnell, da jede modifizierte Seite kopiert wird.
• Snapshots erhöhen minimal die Schreiblatenz, weil die Originalseite zuerst weggeschrieben werden muss. In der Praxis ist der Overhead jedoch gering. Bei typischen Entwicklungs- oder Testsystemen bleibt der Performance-Einfluss meist unter 5 Prozent.

Snapshots automatisieren

Snapshots lassen sich leicht in Skripte integrieren – etwa mit PowerShell oder T-SQL. Ein Beispiel mit PowerShell und SMO (SQL Management Objects):

$server = New-Object Microsoft.SqlServer.Management.Smo.Server('MyServer')
 $snapshotName = 'SalesDB_Snapshot_' + (Get-Date -Format 'yyyyMMdd_HHmm')
 $query = "CREATE DATABASE $snapshotName ON (NAME = SalesDB, FILENAME='D:\Snapshots\$snapshotName.ss') AS SNAPSHOT OF SalesDB;"
 $server.ConnectionContext.ExecuteNonQuery($query)

Unter Linux kann derselbe Vorgang mit bash automatisiert werden. So lassen sich Snapshots plattformübergreifend in CI/CD-Pipelines einbinden, um vor jedem Deployment automatisch einen Wiederherstellungspunkt zu erzeugen (Bild 4).

Fazit

Database Snapshots sind ein oft unterschätztes, aber extrem nützliches Feature im SQL Server. Sie verbinden Geschwindigkeit, Einfachheit und Sicherheit – ideal für Entwickler, die flexibel arbeiten, aber dennoch Rückversicherung brauchen. Ob für Audits, Tests oder Rollbacks: Mit einem Snapshot lässt sich die Zeit beliebig lange einfrieren.