Storage. Backup. Virtualisierung.
Snapshot · Version 1.9 · © Stor IT Back 2026
Ein Snapshot ist ein Point-in-Time-Abbild von Daten zu einem genau definierten Zeitpunkt. Er ermöglicht es, einen früheren Datenstand sehr schnell wiederherzustellen, ohne dafür zunächst eine vollständige Kopie aller Daten erstellen zu müssen. Je nach eingesetzter Snapshot-Technologie werden unveränderte Datenblöcke gemeinsam genutzt und nur Änderungen beziehungsweise ältere Blockversionen zusätzlich gespeichert.
Typische Einsatzbereiche von Snapshots sind:
Wichtig: Ein Snapshot ist nicht automatisch anwendungskonsistent und ersetzt normalerweise kein unabhängiges Backup. Bei Datenbanken und anderen transaktionsorientierten Anwendungen muss die Konsistenz beispielsweise über Microsoft VSS, einen Datenbank-Backup-Modus oder andere anwendungsspezifische Mechanismen sichergestellt werden.
Ein Snapshot ist grundsätzlich kein Ersatz für eine Datensicherung. Ein Snapshot speichert oder referenziert einen bestimmten Zustand der Daten und befindet sich häufig auf demselben Storage-System wie die produktiven Daten. Fällt dieses Storage-System vollständig aus oder werden sowohl Produktivdaten als auch Snapshots beschädigt oder gelöscht, steht möglicherweise auch der Snapshot nicht mehr zur Verfügung.
Ein Backup sollte dagegen eine vom Produktivsystem unabhängige Kopie der Daten bereitstellen. Je nach Sicherungskonzept befindet sich diese auf einem anderen Storage-System, einem Backup-Server, Bandmedien oder an einem weiteren Standort beziehungsweise in einer Cloud.
Snapshots und Backups ergänzen sich daher sehr gut: Snapshots ermöglichen schnelle lokale Wiederherstellungen und kurze Recovery-Zeiten, während Backups Schutz vor einem vollständigen Verlust des ursprünglichen Storage-Systems bieten.
In professionellen Backup-Lösungen werden beide Technologien häufig miteinander kombiniert. Ein Snapshot stellt kurzfristig einen stabilen Datenstand bereit, während dieser anschließend auf ein unabhängiges Backup-Ziel übertragen wird.
Die ersten Snapshot-Technologien wurden unter anderem entwickelt, um Datensicherungen und Wiederherstellungen großer Datenmengen mit möglichst geringer Unterbrechung der produktiven Systeme zu ermöglichen. Das Kopieren großer Datenbestände benötigt selbst mit schnellen Storage- und Backup-Systemen eine gewisse Zeit.
Ein historisches Beispiel: Sollen 20 TB mit einem LTO-6-Laufwerk und einer nativen Transferrate von etwa 160 MB/s gesichert werden, benötigt eine vollständige Sicherung theoretisch ungefähr 35 bis 36 Stunden. Eine Datenbank oder Anwendung kann für eine solche Zeitspanne normalerweise nicht angehalten werden.
Stattdessen wird die Anwendung kurz in einen konsistenten Zustand gebracht und anschließend ein Snapshot erzeugt. Der Snapshot stellt den Datenzustand zu diesem Zeitpunkt bereit. Danach kann die Anwendung wieder normal arbeiten, während die eigentliche Datensicherung auf Basis des Snapshots erfolgt.
Besitzt die Anwendung oder Datenbank einen geeigneten Online-Backup-Modus, muss sie für die Erstellung des Snapshots häufig nicht vollständig beendet werden. Stattdessen sorgt die Anwendung selbst dafür, dass ein konsistenter Datenstand erzeugt werden kann.
Eine klassische Möglichkeit, einen Datenstand zu einem bestimmten Zeitpunkt bereitzustellen, ist die Verwendung eines vorhandenen Datenspiegels. Statt sämtliche Daten zunächst erneut zu kopieren, wird eine Seite des Spiegels vom produktiven System getrennt.
Das Trennen eines bereits synchronisierten Spiegels dauert nur sehr kurze Zeit und ist weitgehend unabhängig von der Größe des Datenbestands. Anschließend kann die abgetrennte Seite beispielsweise für eine Datensicherung, einen Test oder eine Analyse verwendet werden, während das Produktivsystem weiterarbeitet.
Nach Abschluss der Arbeiten kann der Spiegel wieder mit dem produktiven Datenbestand synchronisiert werden. Dieses Verfahren stellt eine vollständige Datenkopie bereit, benötigt allerdings entsprechend viel zusätzlichen Speicherplatz.
Moderne Snapshot-Verfahren vermeiden in vielen Fällen eine vollständige zweite Datenkopie. Stattdessen werden unveränderte Daten gemeinsam genutzt und nur diejenigen Blöcke zusätzlich gespeichert, die sich nach der Snapshot-Erstellung verändern.
Dadurch benötigt ein neu angelegter Snapshot zunächst nur vergleichsweise wenig zusätzlichen Speicherplatz. Mit zunehmender Laufzeit und steigender Änderungsrate wächst allerdings auch der Speicherplatzbedarf des Snapshots.
Zu den wichtigsten Verfahren gehören Copy-on-Write (COW), Redirect-on-Write (ROW) sowie verschiedene pointer- und metadatenbasierte Varianten dieser Konzepte.
Beim Copy-on-Write-Verfahren (COW) verbleiben die ursprünglichen Daten zunächst an ihrer bisherigen Position. Soll ein Datenblock nach der Erstellung eines Snapshots erstmals verändert werden, wird der ursprüngliche Inhalt dieses Blocks zunächst in einen für den Snapshot vorgesehenen Bereich kopiert. Erst danach wird der produktive Block mit den neuen Daten überschrieben.
Der Snapshot greift anschließend für diesen Datenblock auf die zuvor gespeicherte ältere Version zurück. Blöcke, die sich seit Erstellung des Snapshots nicht verändert haben, müssen dagegen nicht zusätzlich kopiert werden.
Ein Vorteil von Copy-on-Write ist der vergleichsweise geringe Speicherplatzbedarf eines neu erstellten Snapshots. Bei der ersten Änderung eines bereits im Snapshot enthaltenen Blocks entsteht jedoch zusätzlicher I/O, da zunächst der bisherige Inhalt gesichert werden muss. Wie groß dieser Einfluss auf die Performance ist, hängt stark vom Storage-System, der Implementierung, dem Cache und dem jeweiligen Workload ab.
Ein bekanntes Beispiel ist der Microsoft-VSS-Systemprovider. Auch klassische Snapshots des Linux Logical Volume Managers können nach dem Copy-on-Write-Prinzip arbeiten.
Beim Redirect-on-Write-Verfahren (ROW) werden vorhandene Datenblöcke nach der Snapshot-Erstellung nicht überschrieben. Neue beziehungsweise geänderte Daten werden stattdessen an einer anderen freien Position gespeichert. Anschließend werden die entsprechenden Metadaten beziehungsweise Blockreferenzen auf die neue Position umgestellt.
Der Snapshot behält die Referenz auf die ursprünglichen Datenblöcke. Dadurch muss vor einem Schreibvorgang keine alte Blockversion zunächst in einen separaten Snapshot-Bereich kopiert werden.
Beim Löschen eines Snapshots müssen bei modernen pointer- oder metadatenbasierten Implementierungen nicht grundsätzlich sämtliche geänderten Daten zurückkopiert werden. Stattdessen können nicht mehr benötigte Blockreferenzen entfernt und anschließend nicht mehr referenzierte Blöcke wieder freigegeben werden.
Ein bekanntes Beispiel für ein pointer- beziehungsweise metadatenbasiertes Snapshot-Konzept ist NetApp ONTAP mit dem WAFL-Dateisystem. Änderungen werden in neue Blöcke geschrieben, während vorhandene Snapshots weiterhin auf die älteren Blockversionen verweisen können.
| Eigenschaft | Copy-on-Write (COW) | Redirect-on-Write (ROW) |
|---|---|---|
| Änderung eines Blocks | Alter Datenblock wird vor dem Überschreiben für den Snapshot gesichert. | Neue Daten werden an einer anderen Position geschrieben. |
| Unveränderte Daten | Werden zwischen Produktivdaten und Snapshot gemeinsam genutzt. | Werden zwischen Produktivdaten und Snapshot gemeinsam genutzt. |
| Zusätzlicher Schreibaufwand | Beim erstmaligen Ändern eines Blocks entsteht zusätzlicher I/O. | Kein vorheriges Kopieren des alten Blocks erforderlich. |
| Snapshot-Erstellung | In der Regel sehr schnell. | In der Regel sehr schnell. |
| Speicherplatzbedarf | Wächst mit der Menge der veränderten Daten. | Wächst ebenfalls mit der Menge der veränderten Daten. |
| Löschen eines Snapshots | Snapshot-Daten beziehungsweise Referenzen können freigegeben werden. | Bei modernen Implementierungen werden nicht mehr benötigte Referenzen und Blöcke freigegeben. |
| Performance | Abhängig von Implementierung, Cache und Workload. | Abhängig von Implementierung, Metadatenverwaltung und Workload. |
Die tatsächliche Anzahl möglicher Snapshots, deren Performance und die Auswirkungen auf den Speicherplatz lassen sich nicht allein aus COW oder ROW ableiten. Diese Eigenschaften hängen wesentlich von der konkreten Storage-Architektur und dem jeweiligen Produkt ab.
Snapshots können auf unterschiedlichen Ebenen einer IT-Infrastruktur erstellt werden. Das verwendete Verfahren hängt davon ab, ob beispielsweise ein Dateisystem, ein Volume Manager, ein Hypervisor, ein Storage-System oder eine Anwendung den Snapshot erzeugt.
| Snapshot-Ebene | Typische Beispiele | Vorteile | Besonderheiten |
|---|---|---|---|
| Dateisystem | ZFS, Btrfs | Direkte Kenntnis der Dateisystemstrukturen und schnelle Snapshots. | Anwendungskonsistenz muss gegebenenfalls zusätzlich sichergestellt werden. |
| Volume Manager | Linux LVM | Snapshot unabhängig von einzelnen Dateien oder Anwendungen. | Der Volume Manager kennt normalerweise nicht den Zustand einer Datenbank. |
| Hypervisor | Proxmox VE, VMware vSphere, Hyper-V | Snapshots können auf Ebene virtueller Maschinen verwaltet werden. | Guest-Agenten oder VSS verbessern die Konsistenz innerhalb der VM. |
| Storage-System | NetApp ONTAP, IBM FlashSystem, Dell Storage | Sehr schnelle Snapshots bei geringer Belastung des Hosts. | Für Anwendungskonsistenz ist häufig eine Koordination mit Server oder Applikation erforderlich. |
| Anwendung | Datenbanken und Backup-fähige Applikationen | Die Anwendung kann einen konsistenten Zustand gezielt herstellen. | Wird häufig mit Storage- oder Hypervisor-Snapshots kombiniert. |
In Unternehmensumgebungen werden diese Ebenen häufig miteinander kombiniert. Beispielsweise kann eine Backup-Software zunächst über einen Datenbank-Agenten oder Microsoft VSS einen konsistenten Zustand erzeugen und anschließend einen Snapshot auf dem Hypervisor oder Storage-System auslösen.
Microsoft Windows stellt mit dem Volume Shadow Copy Service (VSS) eine Infrastruktur für Point-in-Time-Schattenkopien von Volumes bereit. VSS wird sowohl für Datensicherungen als auch für die Windows-Funktion Vorgängerversionen verwendet.
VSS basiert auf dem Zusammenspiel mehrerer Komponenten:
Der in Windows enthaltene Systemprovider kann Schattenkopien nach dem Copy-on-Write-Prinzip erzeugen. Storage-Hersteller können zusätzlich eigene Hardware-Provider zur Verfügung stellen, bei denen die Snapshot-Erstellung direkt auf dem Storage-System erfolgt.
VSS ist besonders wichtig für Anwendungen wie Microsoft SQL Server, Exchange Server oder andere Programme, die während einer Datensicherung konsistente Zustände ihrer geöffneten Daten benötigen. Über die Funktion „Vorgängerversionen“ können Administratoren und Benutzer außerdem ältere Versionen von Dateien oder Verzeichnissen aus vorhandenen Schattenkopien wiederherstellen.
Bei Proxmox VE muss zwischen einem Snapshot einer virtuellen Maschine und einer Datensicherung unterschieden werden. Ein VM-Snapshot hält den Zustand einer virtuellen Maschine zu einem bestimmten Zeitpunkt fest und eignet sich beispielsweise als kurzfristiger Rücksetzpunkt vor Updates, Softwareinstallationen oder größeren Konfigurationsänderungen.
Ein Snapshot ersetzt jedoch keine unabhängige Datensicherung. Befindet sich der Snapshot auf demselben Storage-System wie die virtuelle Maschine, kann er bei einem vollständigen Ausfall dieses Storage-Systems ebenfalls verloren gehen.
Für Datensicherungen verwendet Proxmox VE einen integrierten Live-Backup-Mechanismus. Im Backup-Modus Snapshot kann die virtuelle Maschine während der Sicherung weiterlaufen. Proxmox sorgt dafür, dass ein definierter Datenstand für die Datensicherung bereitgestellt wird.
Ist innerhalb der virtuellen Maschine der QEMU Guest Agent installiert und aktiviert, kann Proxmox vor dem Backup das Dateisystem des Gasts kurzfristig einfrieren. Bei Windows-Gastsystemen kann dabei der Microsoft Volume Shadow Copy Service (VSS) eingebunden werden. Dadurch lässt sich die Konsistenz innerhalb der virtuellen Maschine verbessern.
Insbesondere bei Datenbanken sollte zusätzlich geprüft werden, ob die jeweilige Anwendung beziehungsweise deren VSS Writer oder Backup-Mechanismus korrekt in den Sicherungsprozess eingebunden ist. Ein crash-konsistenter VM-Zustand ist nicht automatisch mit einem anwendungskonsistenten Datenbank-Backup gleichzusetzen.
Mit dem Proxmox Backup Server (PBS) steht eine speziell für Proxmox entwickelte Backup-Plattform zur Verfügung. Die zu sichernden Daten werden in Chunks zerlegt, dedupliziert und komprimiert gespeichert. Bereits vorhandene Datenblöcke müssen nicht erneut vollständig übertragen und gespeichert werden.
Damit erfolgt die Speicherung nach dem ersten Backup im Wesentlichen inkrementell. Trotzdem stellt jeder Sicherungsstand logisch einen vollständigen Wiederherstellungspunkt dar. Für einen Restore muss der Administrator daher nicht manuell eine Vollsicherung mit einer langen Kette einzelner inkrementeller Sicherungen zusammensetzen.
Der Proxmox Backup Server unterstützt darüber hinaus Funktionen wie Prüfläufe, Aufbewahrungsregeln, Deduplizierung, Verschlüsselung und die Replikation beziehungsweise Synchronisation von Backup-Daten zwischen Backup-Servern.
Ein Snapshot stellt technisch einen definierten Datenzustand zu einem bestimmten Zeitpunkt bereit. Das bedeutet jedoch nicht automatisch, dass auch eine darauf gespeicherte Anwendung oder Datenbank anwendungskonsistent ist.
Wird beispielsweise während einer laufenden Datenbanktransaktion ein Snapshot erstellt, können sich Teile der Transaktion bereits auf dem Storage befinden, während andere Daten noch im Arbeitsspeicher oder in einem Cache liegen. Der Snapshot kann auf Blockebene korrekt sein, obwohl die Anwendung nach einer Wiederherstellung zunächst Recovery-Mechanismen ausführen muss.
Ein crash-konsistenter Snapshot entspricht ungefähr dem Zustand eines Systems nach einem plötzlichen Stromausfall. Alle Blöcke stammen aus einem definierten Zeitpunkt, Anwendungen konnten ihre internen Datenstrukturen aber möglicherweise nicht kontrolliert auf den Datenträger schreiben.
Moderne Dateisysteme und Datenbanken können solche Zustände häufig über Journale, Transaktionsprotokolle oder Recovery-Mechanismen korrigieren. Eine erfolgreiche Wiederherstellung sollte trotzdem regelmäßig getestet werden.
Bei einem anwendungskonsistenten Snapshot wird die betroffene Anwendung vor der Snapshot-Erstellung gezielt in einen konsistenten Zustand versetzt. Dazu können beispielsweise Datenbank-Backup-Modi, Microsoft VSS Writer, Guest-Agenten oder spezielle Backup-Schnittstellen verwendet werden.
Die Anwendung muss dabei häufig nur sehr kurz in diesem Zustand verbleiben. Sobald der Snapshot erstellt wurde, kann der normale Betrieb fortgesetzt werden, während die eigentliche Datensicherung im Hintergrund auf Basis des Snapshots erfolgt.
Weitere Informationen finden Sie auf unserer Seite über Online- und Offline-Datensicherungen.
Ein Snapshot ist ein Point-in-Time-Abbild von Daten zu einem bestimmten Zeitpunkt. Statt alle Daten vollständig zu kopieren, nutzen moderne Snapshot-Verfahren häufig gemeinsame Datenblöcke und speichern nur Änderungen beziehungsweise ältere Blockversionen zusätzlich. Dadurch kann ein Snapshot sehr schnell erstellt werden und benötigt zunächst nur wenig zusätzlichen Speicherplatz.
Nein. Ein Snapshot befindet sich häufig auf demselben Storage-System wie die produktiven Daten und kann bei einem vollständigen Ausfall oder Verlust dieses Systems ebenfalls verloren gehen. Ein Backup sollte eine unabhängige Kopie der Daten auf einem separaten Backup-Ziel bereitstellen. Snapshots und Backups ergänzen sich deshalb, ersetzen sich aber nicht.
Bei Copy-on-Write wird der ursprüngliche Inhalt eines Datenblocks vor dessen erster Änderung für den Snapshot gesichert. Bei Redirect-on-Write werden neue Daten dagegen an einer anderen Position gespeichert und die entsprechenden Blockreferenzen beziehungsweise Metadaten angepasst. Beide Verfahren ermöglichen speicherplatzsparende Snapshots, unterscheiden sich aber beim Umgang mit Schreiboperationen und Metadaten.
Ein Snapshot ist nicht automatisch anwendungskonsistent. Er kann einen technisch korrekten Datenstand enthalten, während sich eine Datenbank oder Anwendung gerade mitten in einer Transaktion befand. Für anwendungskonsistente Snapshots müssen Anwendungen beispielsweise über VSS, einen Datenbank-Backup-Modus oder andere geeignete Schnittstellen eingebunden werden.
Der Volume Shadow Copy Service (VSS) ist eine Windows-Infrastruktur für Point-in-Time-Schattenkopien. Dabei arbeiten VSS Requester, VSS Writer und VSS Provider zusammen. Backup-Software kann dadurch Anwendungen wie Datenbanken kontrolliert in einen konsistenten Zustand versetzen und anschließend eine Schattenkopie erstellen lassen.
Proxmox VE kann Snapshots virtueller Maschinen als schnelle Rücksetzpunkte verwenden. Für Datensicherungen besitzt Proxmox einen eigenen Live-Backup-Mechanismus. Mit aktiviertem QEMU Guest Agent können Dateisysteme während der Sicherung kurzfristig eingefroren werden; bei Windows-Gastsystemen kann dabei Microsoft VSS genutzt werden.
Ein neu angelegter Snapshot benötigt bei modernen Verfahren zunächst vergleichsweise wenig zusätzlichen Speicherplatz. Der Bedarf wächst anschließend mit der Menge der Daten, die sich seit der Erstellung des Snapshots verändert haben. Wie viel Speicher tatsächlich benötigt wird, hängt von der Änderungsrate, der Aufbewahrungsdauer und der jeweiligen Snapshot-Technologie ab.
Snapshots eignen sich vor allem für kurzfristige Wiederherstellungspunkte. Sehr viele oder sehr lange aufbewahrte Snapshots können abhängig vom Storage-System Speicherplatz und Verwaltung belasten. Für eine langfristige Aufbewahrung von Datenständen sollte normalerweise eine eigenständige Backup-Lösung verwendet werden.
