Volumeschattenkopie (VSS): Funktionsweise und Praxis ── Warum sich Dateien in Benutzung sichern lassen

„Ich wollte eine Datei kopieren, die eine andere Anwendung geöffnet hatte, und bekam die Meldung, der Prozess könne wegen anderweitiger Verwendung nicht auf die Datei zugreifen.“ „Man hat uns gebeten, den Datenordner zu sichern, ohne das Kernsystem anzuhalten.“ „Warum kann Backup-Software eine Datenbankdatei in Benutzung einfach so kopieren?“ — Ob in der Entwicklung von Fachanwendungen oder im Betrieb von Dateiservern: Früher oder später stößt man auf diese Fragen.

Im Zentrum der Antwort steht der Volumeschattenkopie-Dienst (VSS: Volume Shadow Copy Service). Er ist seit über zwanzig Jahren fest in Windows integriert, und Windows Server Backup, die Systemwiederherstellung sowie praktisch jede kommerzielle Backup-Software bauen auf diesem Fundament auf.¹

Dieser Artikel richtet sich an Entwickler von Fachanwendungen, die um eine Funktion „Dateien in Benutzung kopieren“ gebeten werden, sowie an IT-Verantwortliche, die Backups von Dateiservern und Arbeitsplatzrechnern betreiben. Auf Basis von Primärquellen mit Stand August 2026 ordnet er die Akteure und die Funktionsweise von VSS, die Praxis der Bedienung mit vssadmin sowie die Entscheidung ein, wie weit Entwickler sich überhaupt mit VSS befassen sollten. Die Reihe „Die Tiefen der Windows-E/A“ hat den Cache-Manager und NTFS von innen betrachtet — dieser Artikel ist ihre Fortsetzung und behandelt die „Snapshot“-Schicht, die sich unmittelbar über dem Volume einschiebt.

1. Zuerst das Fazit

• VSS ist eine Gruppe von COM-Schnittstellen samt koordinierendem Dienst, die es ermöglichen, ein Volume zu sichern, während eine Anwendung weiterhin darauf schreibt. Es ist seit Windows XP fest in Windows integriert.²
• Es gibt drei Rollen plus einen Koordinator. Der VSS-Dienst vermittelt zwischen dem Requester, der eine Schattenkopie anfordert (Backup-Software), dem Writer, der auf Anwendungsseite die Datenkonsistenz garantiert (etwa SQL Server), und dem Provider, der die Schattenkopie tatsächlich erzeugt.¹
• Der Windows-Standard-Systemprovider arbeitet nach dem Copy-on-Write-Verfahren. Statt das gesamte Volume zu duplizieren, verschiebt er nur die nach dem Snapshot überschriebenen Blöcke — und nur deren Inhalt vor dem Überschreiben — in einen Differenzbereich (diff area). Dieser Differenzbereich muss auf einem NTFS-Volume liegen.¹
• Ein Ruhepunkt entsteht durch „Writer einfrieren (bis zu 60 Sekunden) → Snapshot erzeugen (innerhalb von 10 Sekunden) → auftauen“. Wird eine der Zeitgrenzen überschritten, wird die Erstellung abgebrochen, und der Requester versucht es erneut.¹
• Ob ein Writer mitwirkt, entscheidet über die Qualität der Kopie. Ein ohne Writer-Mitwirkung erstellter Snapshot entspricht „der Festplatte im Moment des Stromausfalls“ (crash-konsistent); einer mit Mitwirkung hat bereits Protokolle rotiert und Zwischenspeicher geleert und befindet sich in einem konsistenten Zustand, den die Anwendung selbst als wiederherstellbar garantiert (anwendungskonsistent).³¹
• Für die Betriebsprüfung ist vssadmin das Werkzeug. Mit list shadows / list writers / list shadowstorage prüfen Sie den aktuellen Zustand, mit resize shadowstorage passen Sie die Obergrenze des Differenzbereichs an. Ist der Differenzbereich erschöpft, werden die ältesten Schattenkopien stillschweigend gelöscht.⁴⁵¹
• Einen VSS-Requester in eine eigene Anwendung einzubauen ist ein beachtliches Unterfangen. Es handelt sich um eine COM-basierte native API ohne offiziellen .NET-Wrapper. In den meisten Fällen genügen erneute Versuche, eine Anpassung des Freigabemodus oder ein kurzer Stillstand; ist VSS wirklich notwendig, ist die Skriptsteuerung von DiskShadow die praktische Lösung (nur Windows Server).⁶⁷
• Eine Schattenkopie ist selbst kein Backup. Da die Copy-on-Write-Differenz von den unversehrten Blöcken des ursprünglichen Volumes abhängt, bietet sie keinerlei Schutz gegen einen Ausfall, der das ursprüngliche Volume als Ganzes vernichtet — etwa einen Festplattendefekt oder Diebstahl. Auch gegen Ransomware ist kein Verlass, da sich Schattenkopien selbst löschen lassen (7.3) oder der Differenzbereich durch massenhaftes Überschreiben erschöpft werden kann (7.4). Erst in Kombination mit Backups auf getrenntem Medium ergibt sie einen Sinn.¹

2. Die Ausgangslage ── Warum sich Dateien in Benutzung nicht einfach kopieren lassen

Ausgangspunkt ist der Freigabemodus von Windows-Dateien. Beim Öffnen einer Datei (CreateFile) legt man in Windows als Freigabemodus (dwShareMode) fest, was man anderen Prozessen erlaubt, solange man selbst die Datei geöffnet hält. Solange ein Prozess die Datei so geöffnet hält, dass er keine Lesefreigabe zulässt, scheitert jeder Prozess, der später lesend öffnen will, mit einer Freigabeverletzung (ERROR_SHARING_VIOLATION, Fehler 32).⁸ In .NET zeigt sich das als die bekannte IOException („Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird“).

Wichtig ist: Das ist kein Fehler, sondern der korrekte Mechanismus zum Schutz der Daten. Würde eine gerade beschriebene Datei mittendrin gelesen, erhielte der Lesende einen „halbfertigen, unvollständigen“ Zustand. Wie im Artikel „Grundlagen der gegenseitigen Ausschlusssteuerung bei der Dateiintegration - Best Practices für Dateisperren und atomare Claims“ ausführlich behandelt, ist das Design der gegenseitigen Ausschlusssteuerung die Grundlage jeder Zusammenarbeit zwischen Anwendungen.

Doch dieser korrekte Mechanismus steht grundsätzlich im Widerspruch zu Backups.

• Die Mauer der Freigabeverletzung: Eine Datei, die eine Datenbank oder Fachanwendung dauerhaft geöffnet hält, lässt sich mitunter als Kopierquelle gar nicht erst öffnen.
• Die Mauer der Konsistenz: Selbst wenn sich die Datei öffnen lässt (weil Lesefreigabe erlaubt ist), braucht das Kopieren Zeit. Da die Anwendung während des Kopierens weiterschreibt, können die erste und die zweite Hälfte der Datei unterschiedliche Zeitpunkte widerspiegeln, oder mehrere Dateien (etwa Datendatei und zugehöriges Protokoll) geraten gegeneinander aus dem Takt. Und wie im Beitrag zum „Cache-Manager“ gezeigt, landet ein Schreibvorgang zunächst im Arbeitsspeicher-Cache, sodass ein Blick allein auf die Datei auf der Festplatte nicht garantiert, den neuesten Stand zu sehen.
• Die Mauer des Betriebs: „Dann eben die Anwendung anhalten und kopieren“ ist im Grundsatz richtig, aber für ein rund um die Uhr laufendes Geschäftssystem oder einen Dateiserver nicht akzeptabel.

Mit anderen Worten: Der eigentliche Wunsch lautet „eine Kopie eines einzelnen, konsistenten Augenblicks, ohne die Anwendung anzuhalten“. Das ist zu viel, als dass einzelne Anwendungen es selbst lösen könnten — deshalb wurde VSS als betriebssystemweiter Mechanismus dafür geschaffen. VSS wird als COM-Schnittstellen-Framework bereitgestellt, das es ermöglicht, ein Volume zu sichern, während eine Anwendung weiterhin darauf schreibt.²

3. Die Akteure von VSS ── Requester, Writer, Provider

Der Aufbau von VSS gliedert sich in drei Rollen und den vermittelnden Dienst.¹

Der Reiz dieser Rollenteilung liegt darin, dass Produkte, die nichts voneinander wissen, dennoch zusammenarbeiten können. Die Backup-Software (der Requester) kennt die interne Struktur von SQL Server nicht, doch der Writer von SQL Server meldet als Metadaten, welche Dateien (Komponenten) gesichert werden müssen, und bringt seine eigenen Daten unmittelbar um den Ruhepunkt herum in Ordnung — der Requester muss dem nur folgen, um eine konsistente Sicherung zu erhalten.¹⁹ Nahezu jede auf Windows laufende Backup-Software von Drittanbietern ist ein VSS-Requester.¹

In der IT-Praxis wird diese Dreiteilung vor allem bei der Fehlersuche relevant. Ob ein Backup-Fehlschlag am Requester (der Software), an einem bestimmten Writer (der Anwendung) oder am Provider bzw. Differenzbereich (der Infrastruktur) liegt, entscheidet vollständig darüber, wo gesucht werden muss (Kapitel 5 und 7).

4. Wie Snapshots funktionieren ── Copy-on-Write und der „Ruhepunkt“

4.1. Copy-on-Write ── „diesen Augenblick“ bewahren, ohne das Volume zu duplizieren

Beim Wort „Snapshot“ denkt man an die Duplikation des gesamten Volumes, doch das Verfahren, das der Windows-Standard-Systemprovider tatsächlich verwendet, ist Copy-on-Write. Im Moment der Snapshot-Erstellung wird fast nichts kopiert. Erst wenn später ein Block des ursprünglichen Volumes überschrieben werden soll, wird der Inhalt dieses Blocks vor dem Überschreiben in den Differenzbereich (diff area, Schattenkopie-Speicher) verschoben, bevor der Schreibvorgang durchgelassen wird.¹ Diese Verschiebung ist nur beim ersten Überschreiben jedes Blocks nötig; das erneute Überschreiben eines bereits verschobenen Blocks lässt den Differenzbereich nicht weiter wachsen.

Um „das Volume zu diesem Augenblick“ zu lesen, werden unveränderte Blöcke aus dem ursprünglichen Volume und geänderte Blöcke aus dem Differenzbereich gelesen und zusammengesetzt. Da nur der geänderte Anteil überhaupt kopiert wird, geschieht die Erstellung augenblicklich, und der verbrauchte Speicherplatz beschränkt sich auf die Differenz. Die Kehrseite ist, dass der Differenzbereich bei einem stark beschriebenen Volume schneller aufgebraucht wird (das greift Kapitel 7 vor), und der Differenzbereich liegt auf einem NTFS-Volume derselben Maschine wie die Ausgangsdaten.¹ Getragen wird dieser Mechanismus von der Komponentendatei des Systemproviders, swprv.dll, sowie vom Treiber, der die Volume-E/A abfängt, volsnap.sys.¹ Wer sich für das „Wie“ des Eingreifens in den E/A-Stapel interessiert, findet mehr im Beitrag „Filtertreiber und Minifilter“.

Daneben gibt es noch weitere Verfahren: die vollständige Kopie, bei der ein Spiegel abgetrennt wird, und Redirect-on-Write, bei dem Änderungen auf ein separates Volume geschrieben werden; Hardware-Provider verwenden jeweils das Verfahren, das für das Speichersystem am besten passt.¹

4.2. Der Ablauf der Ruhepunkt-Erstellung ── 60 Sekunden Einfrieren, 10 Sekunden Erstellen

Beschreibt Copy-on-Write das „Wie“ der Speicherung, liegt der eigentliche Wert von VSS im „welcher Moment gespeichert wird“ — also darin, wie der Ruhepunkt entsteht. Die Erstellung einer Schattenkopie läuft wie folgt ab.¹

flowchart TB
    R["Requester fordert Erstellung an<br/>zählt Writer auf, sammelt Metadaten"] --> M["Jeder Writer meldet seine Sicherungsziele<br/>(Komponenten) als XML"]
    M --> P["Jeder Writer bereitet seine Daten vor<br/>Protokolle rotieren, Zwischenspeicher leeren usw.<br/>und bringt sie in einen wiederherstellbaren, konsistenten Zustand"]
    P --> F["Schreib-E/A der Writer einfrieren<br/>(Lesen bleibt möglich. Höchstens 60 Sekunden)"]
    F --> FS["VSS leert die Dateisystempuffer<br/>und friert das Dateisystem ein"]
    FS --> C["Provider erstellt die Schattenkopie<br/>(innerhalb von 10 Sekunden. Schreib-E/A bleibt währenddessen eingefroren)"]
    C --> T["Dateisystem freigeben → Writer auftauen (thaw)<br/>Anwendung nimmt das Schreiben wieder auf"]
    T --> B["Requester führt die Sicherung<br/>zeitlich unbegrenzt aus der Schattenkopie aus"]

Abbildung 1: Der Ablauf der Schattenkopie-Erstellung. Angehalten wird nur für einige Sekunden bis wenige Dutzend Sekunden — die eigentliche Sicherung läuft gegen den Snapshot

Es gibt drei zentrale Punkte.

1. Die Anwendung stoppt nur für den Augenblick der Ruhepunkt-Erstellung. Das Einfrieren ist auf 60 Sekunden begrenzt, die Erstellung (der Commit) durch den Provider auf 10 Sekunden; wird eine der Grenzen überschritten, wird die Erstellung abgebrochen und der Requester versucht es erneut.¹ Die eigentliche Sicherung, die Stunden dauern kann, läuft gegen die fertige, schreibgeschützte Schattenkopie, während die Anwendung weiterläuft.
2. Während des Einfrierens bleibt Lesen möglich. Nur die Schreib-E/A stoppt.¹
3. Auch das Dateisystem wird eingefroren. Da VSS die Dateisystempuffer leert, bevor es einfriert, spiegeln sich im Cache liegende Schreibvorgänge und die Metadaten des Dateisystems in konsistenter Reihenfolge im Snapshot wider.¹

4.3. Crash-Konsistenz und Anwendungskonsistenz

Hier kommt eine wichtige Unterscheidung ins Spiel, die über die Qualität der Sicherung entscheidet.

Eine ohne Mitwirkung eines Writers erstellte Schattenkopie befindet sich in dem Zustand, den Microsoft als crash-konsistent (crash consistent) bezeichnet. Die offizielle Definition lautet: „ein Datenträgerzustand, der dem Zustand entspricht, den man nach einem katastrophalen Fehler vorfindet, der das System abrupt herunterfährt“; eine Wiederherstellung daraus entspricht „einem Neustart nach einem abrupten Herunterfahren“.³ Als Dateisystem ist das nicht beschädigt, doch aus Sicht der Anwendung ist es „der Moment, in dem mitten im Schreiben der Strom abgeschaltet wurde“. Eine Datenbank mit einem Wiederherstellungsmechanismus über Transaktionsprotokolle kann sich davon oft erholen, doch dieser Wiederherstellungsvorgang ist Voraussetzung, nicht Kür.

Mit Mitwirkung eines Writers rotiert jeder Writer unmittelbar vor dem Ruhepunkt sein Transaktionsprotokoll, leert seine Zwischenspeicher und bringt die Daten in einen konsistenten Zustand, von dem die Anwendung selbst garantiert, dass sie sich daraus korrekt wiederherstellen lässt.¹ Das ist die Anwendungskonsistenz, und sie ist der ganze Existenzgrund des Writer-Mechanismus. Zu beachten ist, dass ein Writer nur „einen für die Anwendung konsistenten, wiederherstellbaren Zustand“ garantiert — er committet nicht heimlich laufende Transaktionen und schließt sie ab. Nicht committete Arbeit wird bei der Wiederherstellung zurückgerollt, genau wie bei der gewöhnlichen Datenbankwiederherstellung. Ein Writer liefert diese Qualitätsgarantie, ohne die Anwendung anzuhalten, allein durch ein Einfrieren von wenigen Dutzend Sekunden.

Dass Backup-Software Einstellungen wie „VSS verwenden“ oder „Anwendungskonsistenz garantieren“ besitzt, ist genau der Ausdruck dieser Unterscheidung. Bei einer bloßen Dateisammlung auf einem Dateiserver ist Crash-Konsistenz kaum ein Problem; auf einem Server mit Datenbank oder Mail-Speicher ist dagegen die Gesundheit des zugehörigen Writers selbst die Qualität der Sicherung.

5. Die Praxis der Betriebsbefehle ── vssadmin und „Vorgängerversionen“

Das Werkzeug, mit dem man in der IT-Praxis den Zustand von VSS prüft, ist vssadmin (auszuführen in einer Eingabeaufforderung mit Administratorrechten). Die aktuelle Befehlsreferenz führt list shadows / list writers / delete shadows / resize shadowstorage als sowohl auf Client als auch auf Server verfügbar auf.⁴ Die auf Windows Server ausgerichtete Referenz nennt darüber hinaus unter anderem create shadow / list shadowstorage / list providers.⁵ Zu beachten ist, dass vssadmin ausschließlich Schattenkopien verwalten kann, die vom Systemprovider erstellt wurden.¹

Zeigt list writers einen Writer im Fehlerzustand, sollte man nicht VSS selbst verdächtigen, sondern die Anwendung, die diesen Writer bereitstellt. Prüfen Sie den Dienststatus der zuständigen Anwendung sowie das Anwendungs-/Systemereignisprotokoll (Kapitel 7).

Bei resize shadowstorage lässt sich die Obergrenze über /maxsize mit einer Einheit wie KB/MB/GB angeben; ohne Angabe gibt es keine Begrenzung. Zu beachten ist, dass ausdrücklich dokumentiert ist, dass schon das Ändern der Speicherobergrenze — insbesondere ihre Verkleinerung — selbst zum Verlust von Schattenkopien führen kann.¹⁰ Verkleinern Sie die Obergrenze eines Volumes, dessen Generationen Sie erhalten möchten, nicht leichtfertig.

5.1. Die Beziehung zu „Vorgängerversionen“

Aktiviert man auf einem Dateiserver „Schattenkopien freigegebener Ordner“ (Shadow Copies of Shared Folders), werden regelmäßig Momentaufnahmen der Dateien auf der Freigabe aufbewahrt, und Benutzer können eine gelöschte oder überschriebene Datei ohne Hilfe eines Administrators über die Vorgängerversionen wiederherstellen.¹ Das ist die alltäglichste Anwendung von VSS und senkt den Aufwand im Helpdesk zuverlässig.

Es gibt allerdings eine Obergrenze. Schattenkopien des Systemproviders sind pro Volume auf maximal 512 begrenzt, wovon die Funktion „Schattenkopien freigegebener Ordner“ standardmäßig bis zu 64 vorhält (änderbar über den Registrierungswert MaxShadowCopies).¹ Und wie in den folgenden Kapiteln beschrieben, werden bei knappem Differenzbereich die ältesten Generationen automatisch entfernt. Es ist sicherer, davon auszugehen, dass sich „wie viele Generationen tatsächlich erhalten bleiben“ nicht nach der konfigurierten Anzahl, sondern nach Schreibmenge und Größe des Differenzbereichs richtet.

6. Die Rolle als Entwickler ── Braucht die eigene Anwendung VSS?

Ab hier wechselt die Perspektive zum Entwickler. Wird man gebeten, „eine Backup-Funktion einzubauen, die auch Dateien in Benutzung kopieren kann“ — wie sollte man sich zu VSS verhalten?

6.1. Einen eigenen Requester zu schreiben ist ein beachtliches Unterfangen

Die VSS-API wird sowohl für Requester als auch für Writer als COM- und C++-Schnittstellen bereitgestellt (das Herzstück eines Requesters ist IVssBackupComponents).⁶ Es gibt keinen offiziellen .NET-Wrapper, und man muss alles korrekt implementieren — vom Sammeln der Writer-Metadaten über die Verwaltung des Snapshot-Satzes bis zum Aufräumen nach einem Fehler —, sodass sich das nicht einfach nebenbei als eine Funktion einer Fachanwendung einbauen lässt. Auch bei uns wird „ein VSS-Requester in Eigenentwicklung“ in Angebotskalkulationen als eigenständiger Entwicklungsposten geführt.

Es gibt zwei realistische Lösungen. Erstens: die Aufgabe einer vorhandenen VSS-fähigen Backup-Software überlassen. Zweitens, unter Windows Server: DiskShadow per Skript ansteuern. DiskShadow ist der mit dem Betriebssystem ausgelieferte VSS-Requester und verfügt neben dem interaktiven Modus über einen Skriptmodus (diskshadow /s script.txt); ein einziges Skript kann die Erstellung der Schattenkopie, ihre Veröffentlichung als Laufwerksbuchstabe (expose), die Ausführung einer Batch-Datei für den Kopiervorgang (exec) sowie das Aufräumen umfassen.⁷¹ So lässt sich der Ablauf „Schattenkopie erstellen → Dateien mit eigener Kopierlogik daraus abziehen → löschen“ realisieren, ohne eine einzige Zeile COM zu schreiben. DiskShadow ist jedoch ausschließlich für Windows Server verfügbar und nicht in Client-Editionen des Betriebssystems enthalten.¹ Sind auch Client-PCs Teil der Anforderung, spricht allein das schon für den Einsatz vorhandener Backup-Software.

6.2. Braucht es überhaupt VSS? ── Eine Entscheidungstabelle

Nach unserer Erfahrung lässt sich die überwiegende Mehrheit der Anfragen „Datei in Benutzung kopieren“ auch ohne VSS lösen. Klären Sie zunächst genau, welches Anforderungsniveau tatsächlich vorliegt, bevor Sie ein Werkzeug wählen.

6.3. Sollte die eigene Anwendung einen Writer registrieren?

Auch die umgekehrte Frage lohnt sich zu klären: Sollte die eigene Fachanwendung einen VSS-Writer bereitstellen? Schreibt man einen, werden die eigenen Anwendungsdaten unabhängig davon, welche Backup-Software der Kunde einsetzt, mit Anwendungskonsistenz gesichert. Es gibt daneben auch einen leichtgewichtigeren Mechanismus als einen gewöhnlichen Writer, den Express-Writer (IVssExpressWriter), doch dieser tut nichts weiter, als Metadaten zu registrieren, welche Dateien einzuschließen oder auszuschließen sind.⁶ Er erhält keine Einfrier-/Auftau-Benachrichtigungen und kann daher das Schreiben der Anwendung nicht auf die Snapshot-Erstellung abstimmen. Ein Express-Writer eignet sich nur in Kombination mit einem Speicherdesign, das auch bei einer Aufnahme mitten im Schreibvorgang nicht beschädigt wird (also Crash-Konsistenz ausreicht); ist tatsächlich eine Abstimmung am Ruhepunkt nötig, braucht es die vollständige Writer-Implementierung.

Dennoch ist der Entscheidungsmaßstab einfach.

• Liegen die Daten in einer Datenbank wie SQL Server, ist kein eigener Writer nötig. Der Writer der Datenbank garantiert die Konsistenz.¹
• Bei einfacher Dateiablage löst man das Problem zuerst über das Design des Speichervorgangs. Schreibt man vollständig in eine temporäre Datei und ersetzt sie dann per atomarer Umbenennung, hinterlässt auch eine crash-konsistente Momentaufnahme nie eine beschädigte gespeicherte Datei.
• Eine Writer-Registrierung lohnt sich nur bei Anwendungen, die einen eigenen, mehrere Dateien umfassenden Datenspeicher betreiben und am Ruhepunkt gegenseitige Konsistenz benötigen. Es kann sich zunächst lohnen zu überdenken, ob es überhaupt sinnvoll ist, so große Datenmengen in einem selbst entwickelten Format zu halten.

7. Fallstricke ── Vier Dinge, die im Betrieb wirklich zuschlagen

7.1. VSS ist selbst kein Backup

Das ist der wichtigste Fallstrick. Eine Schattenkopie des Systemproviders ist eine Differenz auf der Festplatte derselben Maschine wie die Originaldaten. Geht der Differenzbereich verloren, lässt sich nichts mehr zusammensetzen — gegen einen Festplattendefekt, den Diebstahl bzw. Verlust der Maschine oder die Verschlüsselung eines gesamten Volumes bietet das folglich keinerlei Schutz. Auch Microsofts eigene Dokumentation zieht eine klare Grenze zwischen Schattenkopie und Backup: „Der auf ein Medium wie Band kopierte Inhalt einer Schattenkopie ist das Backup, und die Schattenkopie selbst darf nach dieser Kopie gelöscht werden.“¹ Eine Schattenkopie ist ein Ruhepunkt und ein schneller Weg zur Wiederherstellung nach einem Fehler — kein Ersatz für ein Backup auf getrenntem Medium an einem getrennten Standort.

7.2. Ein Writer-Fehler ist ein Problem auf Anwendungsseite

Scheitert Backup-Software mit einem „VSS-Fehler“, ermitteln Sie zunächst mit vssadmin list writers, welcher Writer fehlgeschlagen ist. Da ein Writer im Kern eine Komponente der Anwendung (oder einer Windows-Komponente) ist,¹ liegt der Hauptschauplatz der Ursachenermittlung im Dienststatus dieser Anwendung und in ihren Ereignisprotokollen. Lässt man sich vom äußeren Erscheinungsbild „Fehler der Backup-Software“ mitreißen und untersucht nur die Backup-Software weiter, macht man einen Umweg. Das allgemeine Vorgehen zur Eingrenzung entspricht dem im Artikel „Wenn Sie ein System ohne Quellcode und ohne Dokumentation übernehmen“ behandelten Muster: Verdächtige anhand beobachtbarer Fakten eingrenzen.

7.3. Ransomware kommt gezielt für Ihre Schattenkopien

Das ist ein Fakt, den man rein zur Verteidigung kennen sollte. Man ist versucht zu hoffen, dass sich mit den Vorgängerversionen auch nach einem Ransomware-Befall wiederherstellen ließe — doch es ist allgemein bekannt, dass ein Großteil der Ransomware vor oder nach der Verschlüsselung gezielt Schattenkopien löscht, um genau diesen Wiederherstellungsweg zu versperren. Das Löschen von Schattenkopien lässt sich mit einem völlig regulären Befehl ausführen, sobald Administratorrechte vorliegen, und kann daher keine letzte Verteidigungslinie gegen einen bereits eingedrungenen Angreifer sein. Die Grundpfeiler einer Gegenmaßnahme sind daher: (1) Schattenkopien eher als „praktisch, falls vorhanden“ denn als „Teil des Wiederherstellungsplans“ einordnen, (2) zusätzlich ein Offline-Backup an einem getrennten Standort vorhalten, das ein Angreifer nicht erreichen kann, und (3) Konten für den alltäglichen Betrieb keine Administratorrechte einräumen. Zur Verteidigung über den gesamten PC-Lebenszyklus hinweg — einschließlich Backup, Verschlüsselung und Entsorgung — siehe auch „BitLocker-Praxisleitfaden“ und „Checkliste vor der Entsorgung eines Windows-PCs“.

7.4. Ist der Differenzbereich erschöpft, verschwinden die ältesten Generationen stillschweigend

Wie in Kapitel 4 gezeigt, verbraucht Copy-on-Write den Differenzbereich nur, wenn ein Block nach der Snapshot-Erstellung zum ersten Mal überschrieben wird. Wiederholtes Überschreiben eines bereits verschobenen Blocks erhöht den Verbrauch nicht weiter, sodass sich der Verbrauch nicht nach der „Anzahl der Schreibvorgänge“ richtet, sondern nach der „Breite des Bereichs an Blöcken, die seit der aufbewahrten Momentaufnahme überschrieben wurden“. Und ist der Differenzbereich an seiner Obergrenze angelangt, werden die Schattenkopien dieses Volumes von der ältesten an gelöscht.¹ Der interaktive Benutzer wird darüber nicht benachrichtigt, sodass es meist erst auffällt, wenn sich „ich müsste doch zur Version der letzten Woche zurückkönnen“ als nicht mehr wahr herausstellt. Völlig unbemerkt bleibt es allerdings nicht: Im Systemprotokoll werden Ereignisse der Quelle volsnap erfasst (Ereignis-ID 25, wenn eine Kopie gelöscht wird, weil sich kein Platz im Differenzbereich schaffen ließ, 35/36 bei fehlgeschlagener Erweiterung oder Abbruch beim Erreichen der Obergrenze, und ähnliche). Nehmen Sie diese volsnap-Ereignisse zusätzlich zu regelmäßigen Prüfungen in Ihre Überwachung und Alarmierung auf, um einen Verlust frühzeitig zu bemerken. Dass Massenvorgänge, die „das ganze Volume überstreichen“ — Massenaktualisierungen von Dateien, Stapelkonvertierungen, Defragmentierung —, den Differenzbereich mit einem Schlag aufzehren können, liegt genau an dieser Eigenschaft: Der Verbrauch richtet sich nach dem überschriebenen Bereich. Prüfen Sie regelmäßig anhand der Nutzung von vssadmin list shadowstorage, ob die Anzahl der tatsächlich vorgehaltenen Generationen die betriebliche Anforderung erfüllt („nach spätestens wie vielen Tagen fällt ein versehentliches Löschen auf?“), und erweitern Sie die Obergrenze bei Bedarf.⁵¹⁰

8. Zusammenfassung

• Dass sich eine Datei in Benutzung nicht einfach kopieren lässt, ist eine Frage von Freigabeverletzungen und Konsistenz — und das ist der korrekte Mechanismus zum Schutz der Daten. VSS ist die betriebssystemweite Antwort auf „ich möchte eine konsistente Kopie, ohne die Anwendung anzuhalten“.
• VSS ist ein Rahmenwerk, in dem der VSS-Dienst zwischen drei Rollen vermittelt — Requester (fordert an), Writer (garantiert Konsistenz) und Provider (erstellt) —, sodass Backup-Software und Fachanwendungen, die nichts voneinander wissen, zusammenarbeiten können.
• Der Systemprovider arbeitet nach Copy-on-Write, und ein Ruhepunkt entsteht durch „Writer einfrieren (bis zu 60 Sekunden) → erstellen (innerhalb von 10 Sekunden) → auftauen“. Ohne Mitwirkung eines Writers entsteht Crash-Konsistenz, mit Mitwirkung Anwendungskonsistenz.
• Die Betriebsprüfung erfolgt mit vssadmin (list shadows / list writers / list shadowstorage). Bei einem Writer-Fehler die Anwendungsseite verdächtigen, die Nutzung des Differenzbereichs regelmäßig prüfen.
• Entwickler sollten zunächst anhand der Entscheidungstabelle prüfen, ob sich das Problem durch erneute Versuche, den Freigabemodus, eine Stillstandszeit oder ein Abstimmungsdesign lösen lässt, und erst bei echtem Bedarf zu VSS greifen. Ein DiskShadow-Skript (nur Server) oder vorhandene Software sind die realistischere Lösung gegenüber einer Eigenimplementierung.
• Eine Schattenkopie ist kein Backup. Sie ist nichts weiter als eine Differenz, die von den unversehrten Blöcken des ursprünglichen Volumes abhängt, ist gegen den Verlust dieses ursprünglichen Volumes — etwa durch einen Festplattendefekt — machtlos und gegen Ransomware ebenfalls kein verlässlicher Schutz, da sich Schattenkopien löschen oder der Differenzbereich erschöpfen lässt. Kombinieren Sie sie mit einem Offline-Backup an einem getrennten Standort.

Verwandte Artikel

• Grundlagen der gegenseitigen Ausschlusssteuerung bei der Dateiintegration - Best Practices für Dateisperren und atomare Claims
• Die Tiefen der Windows-E/A (Teil 4) ── Cache-Manager: Wann Ihr WriteFile wirklich die Festplatte erreicht
• Die Tiefen der Windows-E/A (Teil 5) ── NTFS von innen: Das Dateisystem anhand der MFT verstehen
• Wenn Sie ein System ohne Quellcode und ohne Dokumentation übernehmen ── Praktisches Vorgehen für den ununterbrochenen Betrieb
• BitLocker-Praxisleitfaden ── Laufwerksverschlüsselung, beginnend mit der Verwaltung des Wiederherstellungsschlüssels
• Was Sie vor der Entsorgung eines Windows-PCs erledigen sollten ── Praktische Checkliste für Datenlöschung, Kontotrennung und Backups

Verwandte Beratungsleistungen

Die KomuraSoft LLC übernimmt Design und Entwicklung von Fachanwendungen mit Funktionen wie „Dateien in Benutzung kopieren/sichern“, die Ursachenermittlung bei Freigabeverletzungen rund um Dateiintegration und bei Backup-Fehlschlägen (VSS-Writer-Fehler) sowie die Ordnung von Betrieb und Generationsverwaltung für Dateiserver-Backups. Gerne beginnen wir auch bei der Frage, ob VSS für Ihre Anforderung überhaupt notwendig ist.

• Windows-Anwendungsentwicklung
• Fehleruntersuchung und Ursachenanalyse
• Technische Beratung und Design-Review
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wenn ich Schattenkopien habe, brauche ich dann noch Backups?

Nein, das entfällt nicht. Die vom Windows-Standard-Systemprovider erzeugten Schattenkopien sind Copy-on-Write-Differenzen — sie sind keine separate, vollständige Kopie des Volumes zu diesem Zeitpunkt, sondern hängen von den unveränderten Blöcken des ursprünglichen Volumes ab. Selbst wenn Sie den Differenzbereich auf einem separaten Volume ablegen, bleibt es dabei: Geht das ursprüngliche Volume verloren, ist keine Wiederherstellung mehr möglich, und gegen Ereignisse, die das ursprüngliche Volume als Ganzes vernichten — etwa einen Festplattendefekt oder einen gestohlenen bzw. verlorenen PC —, bietet das keinerlei Schutz. Dasselbe gilt für Ransomware: Der Schreibvorgang bei der Verschlüsselung verschiebt zwar die Blöcke vor dem Überschreiben in den Differenzbereich, doch bei realen Angriffen werden entweder die Schattenkopien selbst gelöscht oder der Differenzbereich durch massenhaftes Überschreiben erschöpft — darauf ist also kein Verlass. Auch Microsofts eigene Dokumentation zieht eine klare Grenze zwischen beidem: Ein Backup ist das, was von einer Schattenkopie auf ein Medium wie Band kopiert wurde, und nach dieser Kopie darf die Schattenkopie selbst gelöscht werden. Eine Schattenkopie ist ein „Ruhepunkt, von dem aus ein Backup gezogen wird“ und ein „schneller Weg, um von einem kleinen Fehler wiederherzustellen“ — kein Ersatz für ein Backup auf getrenntem Medium an einem getrennten Standort.

Ich möchte, dass meine eigene Fachanwendung Dateien in Benutzung kopiert — sollte ich VSS verwenden?

Der realistische erste Schritt ist, einen Weg zu finden, der ohne VSS auskommt. VSS-Requester müssen gegen eine COM-basierte native API (etwa IVssBackupComponents) geschrieben werden, und es gibt keinen offiziellen .NET-Wrapper, sodass die Einbindung in eine eigene Anwendung ein beachtliches Unterfangen ist. Lautet die Anforderung lediglich, „eine Datei irgendwann lesen zu können, die ein anderer Prozess gerade schreibt“, genügt ein erneuter Versuch; erlaubt die andere Anwendung Lesefreigabe, genügt es, mit passendem Freigabemodus zu öffnen. Lässt sich die Anwendung kurz anhalten, ist das Kopieren in einer betrieblichen Pause am einfachsten und zuverlässigsten. VSS verdient seinen Platz erst, wenn die Anforderung lautet, „einen vollständigen Datenbestand einer nicht anhaltbaren Anwendung in konsistentem Zustand zu duplizieren“ — und selbst dann sollten Sie zunächst eine vorhandene VSS-fähige Backup-Software oder ein DiskShadow-Skript in Betracht ziehen, bevor Sie selbst etwas implementieren.

vssadmin list writers zeigt einen Writer im Fehlerzustand. Was soll ich tun?

Im Grundsatz untersucht man das als Problem der Anwendung, der dieser Writer gehört. vssadmin list writers zeigt die registrierten Writer samt Status an, sodass Sie zunächst ermitteln, welcher Writer fehlgeschlagen ist. Da Writer von Anwendungen wie SQL Server oder von Windows-Komponenten (etwa der Registrierung) bereitgestellt werden, liegt die Ursache fast immer im Dienststatus der zuständigen Anwendung oder in Fehlern, die im Anwendungs-/Systemereignisprotokoll erfasst sind — nicht in VSS selbst. Starten Sie den betreffenden Dienst neu und grenzen Sie die Reproduktionsbedingungen ein; hilft das nicht, prüfen Sie die Supportinformationen dieser Anwendung. Dieses Vorgehen ist auch der richtige erste Schritt zur Eingrenzung, wenn Backup-Software mit einem VSS-Fehler scheitert.

Eine Schattenkopie ist verschwunden, ohne dass ich es bemerkt habe. Warum?

Die häufigste Ursache ist ein voller Differenzbereich (Schattenkopie-Speicher). Bei Copy-on-Write wird der Inhalt eines Blocks beim ersten Überschreiben nach der Snapshot-Erstellung in den Differenzbereich verschoben; je größer der überschriebene Bereich, desto mehr Differenzbereich wird verbraucht. Ist die zugewiesene Obergrenze erreicht, löscht Windows die ältesten Schattenkopien zuerst, um Platz zu schaffen. Das geschieht ohne Benachrichtigung des interaktiven Benutzers und fällt daher meist erst auf, wenn jemand erwartet, über „Vorgängerversionen“ zur Version der letzten Woche zurückzukehren, und sie nicht mehr vorfindet (im Systemprotokoll werden allerdings Ereignisse der Quelle volsnap erfasst, etwa Ereignis-ID 25, sodass eine Beobachtung dieser Ereignisse einen frühzeitigen Hinweis liefert). Prüfen Sie Nutzung und Obergrenze mit vssadmin list shadowstorage und erhöhen Sie die Grenze bei Bedarf mit vssadmin resize shadowstorage. Beachten Sie dabei, dass schon das Ändern der Obergrenze — insbesondere ihre Verkleinerung — selbst zum Verlust von Schattenkopien führen kann.

Wie hängen die „Vorgängerversionen“ des Explorers und VSS zusammen?

„Vorgängerversionen“ ist einer der Zugangswege, um frühere Dateiversionen aus einer von VSS erzeugten Schattenkopie abzurufen. Auf einem Dateiserver sorgt die Aktivierung von „Schattenkopien freigegebener Ordner“ (Shadow Copies of Shared Folders) dafür, dass regelmäßig Schattenkopien angelegt werden; Benutzer können eine Datei in einem Freigabeordner mit der rechten Maustaste anklicken und sie selbst über die Vorgängerversionen wiederherstellen. Der Vorteil ist, dass sich Lösch- oder Überschreibfehler ohne Zutun eines Administrators beheben lassen. Da dem im Kern aber Schattenkopien zugrunde liegen, gibt es eine Obergrenze für die Anzahl der aufbewahrten Generationen, und reicht der Differenzbereich nicht aus, verschwinden zuerst die ältesten Generationen. Dass „es gibt Vorgängerversionen“ kein Ersatz für Backups ist, wurde im Haupttext bereits erläutert.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.