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 trennt „den Mechanismus, mit dem sich eine Datei in Benutzung kopieren lässt“ von „wie weit diese Kopie tatsächlich schützt“. Er 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.

Zuerst kommen das Fazit und eine Lesehilfe nach Ziel, danach die Akteure von VSS, die Speichermethode, die Prüfung im Betrieb, die Entscheidung der Entwickler und die Fallstricke, in dieser Reihenfolge. Die technischen Erklärungen stützen sich auf Primärquellen mit Stand August 2026.

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 der Mechanismus, der die Schreibvorgänge einer Anwendung in Zusammenarbeit mit ihrem Writer kurz anhält, damit von der in diesem Augenblick erzeugten Kopie ein Backup gezogen werden kann. Eine Schattenkopie zu erzeugen macht ein Backup auf einem getrennten Medium nicht überflüssig.

Was der Mechanismus leistet

VSS ist eine Gruppe von COM-Schnittstellen samt koordinierendem Dienst, die es ermöglichen, ein Volume zu sichern, während Anwendungen weiterhin darauf schreiben. 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 den Snapshot tatsächlich erzeugt.¹

Der 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.¹

Speichermethode und Konsistenzgarantie trennen

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.¹

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).³¹

Betrieb und Entwicklung prüfen Unterschiedliches

Für den Betrieb 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 (Abschnitt 7.3) oder der Differenzbereich durch massenhaftes Überschreiben erschöpft werden kann (Abschnitt 7.4). Erst in Kombination mit Backups auf getrenntem Medium ergibt sie einen Sinn.¹

Nach Ziel oder Symptom lesen

Wer den Mechanismus verstehen will, liest ab Kapitel 2; wer den Betrieb verantwortet, liest Kapitel 5 und 7; wer entwickelt, beginnt bei der Entscheidungstabelle in Kapitel 6.2.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (26 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

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

Zuerst klären, warum sich die Datei gar nicht öffnen lässt

Ausgangspunkt ist der Freigabemodus von Windows-Dateien. Beim Öffnen einer Datei (CreateFile) legt Windows als Freigabemodus (dwShareMode) fest, was anderen Prozessen erlaubt ist, solange das Handle geöffnet bleibt. 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“ 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. Hier stehen drei getrennte Wände.

Wand 1: Eine Freigabeverletzung verhindert das Öffnen der Quelle

Eine Datei, die eine Datenbank oder Fachanwendung dauerhaft geöffnet hält, lässt sich mitunter als Kopierquelle gar nicht erst öffnen.

Wand 2: Selbst wenn sie sich öffnen lässt, ist die Kopie nicht konsistent

Selbst wenn sie sich ö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. „Lesen können“ und „in konsistentem Zustand kopieren können“ sind zwei verschiedene Probleme.

Wand 3: Die Anwendung lässt sich nicht lange genug anhalten, um zu kopieren

„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.¹

Backup-Software und Anwendungen teilen die Arbeit

Die Stärke dieser Aufteilung liegt darin, dass Produkte, die einander nicht kennen, trotzdem zusammenarbeiten können. Backup-Software (der Requester) kennt die interne Struktur von SQL Server nicht. Trotzdem lässt sich mit der folgenden Arbeitsteilung ein konsistentes Backup ziehen.¹⁹

1. Der SQL-Server-Writer meldet als Metadaten die Dateigruppe (die Komponenten), die gesichert werden muss.
2. Der Writer bringt die eigenen Daten vor und nach der Erstellung des Ruhepunkts in Ordnung.
3. Der Requester zieht das Backup gemäß dieser Meldung und dieser Zusammenarbeit.

Nahezu jede Drittanbieter-Backup-Software, die unter Windows läuft, ist ein VSS-Requester.¹

Auch beim Scheitern bestimmen die drei Rollen, wo Sie suchen

Der Ort, an dem die drei Rollen im IT-Alltag am meisten zählen, ist die Fehlersuche. Ob ein Backup-Fehler ein Problem des Requesters (der Software), eines bestimmten Writers (der Anwendung) oder des Providers und des Differenzbereichs (der Infrastruktur) ist, ändert vollständig, wo Sie nachsehen (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

Nur die Blöcke vor dem Überschreiben werden beiseitegelegt

Das Wort „Snapshot“ legt eine Kopie des gesamten Volumes nahe, aber der Windows-Standard-Systemprovider verwendet Copy-on-Write. Im Moment der Snapshot-Erstellung wird fast nichts kopiert.

Wird danach ein Block des ursprünglichen Volumes überschrieben, wird der Block vor dem Überschreiben in den Differenzbereich (diff area, Schattenkopiespeicher) verschoben, bevor der Schreibvorgang durchgelassen wird.¹ Das Verschieben ist nur beim ersten Überschreiben jedes Blocks nötig; das erneute Überschreiben eines bereits beiseitegelegten Blocks vergrößert den Differenzbereich nicht.

Beim Lesen werden ursprüngliches Volume und Differenzbereich zusammengeführt

Um „das Volume in jenem Augenblick“ zu lesen, werden unveränderte Blöcke vom ursprünglichen Volume und geänderte Blöcke aus dem Differenzbereich gelesen und zusammengeführt. Weil nur das Geänderte kopiert wird, entsteht der Snapshot in einem Augenblick, und der verbrauchte Speicher ist nur die Differenz.

Die Kehrseite: Je mehr auf ein Volume geschrieben wird, desto schneller wird der Differenzbereich verbraucht. Was den Verbrauch bestimmt, behandelt Kapitel 7.4 ausführlich. Der Differenzbereich liegt auf einem NTFS-Volume derselben Maschine wie die Originaldaten.¹

Getragen wird dieser Mechanismus von swprv.dll, der Konfigurationsdatei des Systemproviders, und von volsnap.sys, dem Treiber, der in die Volume-E/A eingreift.¹ Wen die Art des Eingriffs in den E/A-Stapel interessiert, findet mehr unter „Filtertreiber und Minifilter“.

Daneben gibt es weitere Verfahren: vollständige Kopie, bei der ein Spiegel abgetrennt wird, und Redirect-on-Write, bei dem Änderungen auf ein anderes Volume geschrieben werden. Hardware-Provider verwenden auf dem Speichersystem das jeweils passende Verfahren.¹

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

Wenn Copy-on-Write „wie gespeichert wird“ ist, dann liegt die eigentliche Stärke von VSS in „welcher Zeitpunkt gespeichert wird“, also in der Herstellung des Ruhepunkts. Die Erstellung einer Schattenkopie läuft wie folgt ab.¹

flowchart TB
    R["Requester fordert die Erstellung an<br/>listet Writer auf und sammelt Metadaten"] --> M["Jeder Writer meldet seine Backup-Ziele<br/>(Komponenten) in XML"]
    M --> P["Jeder Writer bereitet seine Daten vor<br/>rotiert Protokolle, leert Caches usw.<br/>in einen wiederherstellbaren konsistenten Zustand"]
    P --> F["Schreib-E/A der Writer wird eingefroren<br/>(Lesen bleibt möglich, bis zu 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 eingefroren)"]
    C --> T["Dateisystem freigegeben → Writer aufgetaut (thaw)<br/>Anwendungen nehmen das Schreiben wieder auf"]
    T --> B["Requester zieht das Backup von der<br/>Schattenkopie, in der benötigten Zeit"]

Abbildung 1: Der Ablauf der Schattenkopie-Erstellung. Nur wenige bis einige Dutzend Sekunden stehen still; das eigentliche Backup läuft gegen den Snapshot.

Die Stillstandszeit und die Backup-Dauer sind verschieden

Drei Punkte sind festzuhalten.

1. Die Anwendung steht nur für den Augenblick still, in dem der Ruhepunkt entsteht. Das Einfrieren ist auf 60 Sekunden begrenzt, die Erstellung (Commit) durch den Provider auf 10 Sekunden; wird eine Grenze überschritten, wird die Erstellung abgebrochen, und der Requester versucht es erneut.¹ Das eigentliche Backup, das 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 steht still.¹
3. Auch das Dateisystem wird eingefroren. VSS leert die Dateisystempuffer vor dem Einfrieren, sodass Schreibvorgänge, die im Cache lagen, und Dateisystemmetadaten in konsistenter Reihenfolge im Snapshot landen.¹

4.3. Crash-Konsistenz und Anwendungskonsistenz

Hier kommt die Unterscheidung, die über die Qualität des Backups entscheidet.

Ohne Writer: derselbe Zustand wie nach einem plötzlichen Stopp

Eine Schattenkopie ohne Mitwirkung eines Writers ist in Microsofts Terminologie ein crash-konsistenter Zustand (crash consistent). Die offizielle Definition lautet „ein Datenträgerzustand, der dem Zustand entspricht, den man nach einem katastrophalen Fehler vorfindet, der das System abrupt herunterfährt“, und die Wiederherstellung daraus gilt als „einem Neustart nach einem abrupten Herunterfahren gleichwertig“.³ Das Dateisystem ist nicht beschädigt, aber aus Sicht der Anwendung ist es „der Augenblick, in dem mitten im Schreiben der Stromstecker gezogen wurde“. Eine Datenbank mit Wiederherstellung über das Transaktionsprotokoll kann oft wiederhergestellt werden, aber die Wiederherstellung ist Voraussetzung.

Mit Writer: Die Anwendung bereitet einen wiederherstellbaren konsistenten Zustand vor

Mit Mitwirkung eines Writers rotiert jeder Writer unmittelbar vor dem Ruhepunkt seine Transaktionsprotokolle und leert seine Caches, sodass die Daten in einen konsistenten Zustand gelangen, den die Anwendung selbst als korrekt wiederherstellbar garantiert.¹ Das ist Anwendungskonsistenz, und genau deshalb gibt es den Writer-Mechanismus.

Wichtig: Der Writer garantiert „einen aus Anwendungssicht konsistenten, wiederherstellbaren Zustand“; er schließt laufende Transaktionen nicht eigenmächtig ab. Nicht festgeschriebene Arbeit wird bei der Wiederherstellung zurückgerollt (dasselbe Verhalten wie bei der normalen Datenbankwiederherstellung). Der Writer liefert diese Qualitätsgarantie, ohne die Anwendung anzuhalten, nur mit einem Einfrieren von einigen Dutzend Sekunden.

Einstellungen in Backup-Software wie „VSS verwenden“ oder „Anwendungskonsistenz garantieren“ sind der Ausdruck dieser Unterscheidung. Bei gewöhnlichen Dateien auf einem Dateiserver ist Crash-Konsistenz selten ein Problem; auf einem Server mit Datenbank oder E-Mail-Speicher ist der Zustand des zugehörigen Writers die Qualität des Backups selbst.

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

Das Werkzeug, mit dem IT-Verantwortliche den VSS-Zustand prüfen, ist vssadmin. Es wird an einer Eingabeaufforderung mit Administratorrechten ausgeführt. Prüfen Sie zuerst den Zustand anhand der Listen, und ändern Sie die Obergrenze des Differenzbereichs erst, nachdem Sie Bedarf und Verlustrisiko geklärt haben.

Was sich prüfen lässt und welcher Befehlsumfang gilt

Die aktuelle Befehlsreferenz führt list shadows / list writers / delete shadows / resize shadowstorage als auf Client und Server verfügbar auf.⁴ Die Windows-Server-Referenz dokumentiert zusätzlich create shadow / list shadowstorage / list providers und weitere.⁵ vssadmin kann nur Schattenkopien verwalten, die der Systemprovider erzeugt hat.¹

Zustandsbefehle und den Befehl zur Obergrenzenänderung auseinanderhalten

Zeigt list writers einen Writer im Fehlerzustand, ist nicht VSS selbst verdächtig, sondern die Anwendung, die diesen Writer bereitstellt. Prüfen Sie den Dienststatus der zuständigen Anwendung und die Anwendungs- und Systemereignisprotokolle (Kapitel 7).

Die Obergrenzenänderung getrennt von den Prüfbefehlen behandeln

Mit /maxsize von resize shadowstorage lässt sich die Obergrenze mit Einheiten wie KB, MB oder GB angeben; ohne Angabe gibt es keine Begrenzung. Wichtig ist die dokumentierte Warnung, dass die Änderung der Speicherobergrenze — insbesondere ihre Verkleinerung — selbst zum Verlust von Schattenkopien führen kann.¹⁰ Verkleinern Sie die Obergrenze eines Volumes, dessen Generationen Sie behalten wollen, nicht leichtfertig.

5.1. Die Beziehung zu Vorgängerversionen

Aktivieren Sie auf einem Dateiserver Schattenkopien freigegebener Ordner (Shadow Copies of Shared Folders), werden Kopien der Dateien auf der Freigabe zu bestimmten Zeitpunkten regelmäßig gehalten, und Benutzer können eine gelöschte oder überschriebene Datei ohne Hilfe eines Administrators aus den Vorgängerversionen wiederherstellen.¹ Das ist die zugänglichste Anwendung von VSS und senkt den Aufwand des Helpdesks zuverlässig.

Es gibt allerdings Obergrenzen. Schattenkopien des Systemproviders sind auf 512 pro Volume begrenzt; davon hält die Funktion Schattenkopien freigegebener Ordner standardmäßig 64 (änderbar über den Registrierungswert MaxShadowCopies).¹

Und wie die folgenden Abschnitte zeigen, werden die ältesten Generationen automatisch gelöscht, wenn der Differenzbereich knapp wird. Es ist sicherer zu verstehen, dass „wie viele Generationen übrig bleiben“ nicht von der eingestellten Generationenanzahl abhängt, sondern von Schreibvolumen und Größe des Differenzbereichs.

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

Ab hier die Sicht der Entwickler. Wenn Sie gebeten werden, „eine Backup-Funktion hinzuzufügen, die Dateien auch in Benutzung kopiert“, wie sollten Sie sich zu VSS stellen?

Klären Sie zuerst anhand der Entscheidungstabelle in Kapitel 6.2, ob VSS überhaupt nötig ist, und wählen Sie erst dann die Implementierung. Kapitel 6.1 handelt vom Requester, der eine Kopie anfordert; Kapitel 6.3 vom Writer, der es anderen ermöglicht, die Daten Ihrer eigenen Anwendung zu sichern.

6.1. Einen eigenen Requester zu schreiben ist ein beachtliches Unterfangen

Die VSS-API wird für Requester und Writer als COM- und C++-Schnittstellen bereitgestellt (auf der Requester-Seite steht IVssBackupComponents im Zentrum).⁶ Einen offiziellen .NET-Wrapper gibt es nicht, und Sie müssen das Sammeln der Writer-Metadaten, die Verwaltung der Snapshot-Sätze und die Aufräumarbeit nach Fehlern korrekt implementieren — das lässt sich nicht nebenbei als eine Funktion einer Fachanwendung einbauen. In unseren Kostenvoranschlägen für Custom Software Development behandeln wir „einen VSS-Requester selbst schreiben“ als eigenen Entwicklungspunkt.

Zuerst vorhandene Software prüfen, auf Windows Server DiskShadow

Es gibt zwei praktische Antworten. Erstens: es vorhandener VSS-fähiger Backup-Software überlassen. Zweitens, auf Windows Server: DiskShadow aus einem Skript steuern.

DiskShadow ist ein mit dem Betriebssystem mitgelieferter VSS-Requester. Neben einem interaktiven Modus hat er einen Skriptmodus (diskshadow /s script.txt); Erstellung der Schattenkopie, Veröffentlichung als Laufwerkbuchstabe (expose), Ausführung eines Batch, der die Kopie durchführt (exec), und Aufräumen lassen sich in einem einzigen Skript schreiben.⁷¹ Den Ablauf „Schattenkopie erzeugen → Dateien mit der eigenen Kopierroutine daraus ziehen → löschen“ können Sie zusammenstellen, ohne eine Zeile COM zu schreiben.

Allerdings ist DiskShadow auf Windows Server beschränkt und in Client-Editionen des Betriebssystems nicht enthalten.¹ Gehören auch Client-PCs zum Umfang, kippt die Entscheidung an diesem Punkt zu vorhandener Backup-Software.

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

Nach unserer Erfahrung lässt sich der Großteil der Anfragen zu „Dateien in Benutzung kopieren“ ohne VSS lösen. Klären Sie zuerst die Ebene der Anforderung, bevor Sie das Werkzeug wählen.

6.3. Sollte die eigene Anwendung einen Writer registrieren?

Es lohnt sich, auch die umgekehrte Frage zu klären: Sollte eine selbst entwickelte Fachanwendung einen VSS-Writer bereitstellen? Schreiben Sie einen, können die Daten Ihrer Anwendung anwendungskonsistent gesichert werden, unabhängig davon, welche Backup-Software der Kunde verwendet.

Ein Express-Writer hält Schreibvorgänge nicht an

Es gibt auch einen leichteren Mechanismus als einen vollständigen Writer, den Express-Writer (IVssExpressWriter); er registriert lediglich eine Metadaten-Erklärung, welche Dateien ein- und welche ausgeschlossen werden.⁶

Weil er keine Benachrichtigungen wie Einfrieren und Auftauen erhält, kann er die Schreibvorgänge der Anwendung nicht im Gleichschritt mit der Snapshot-Erstellung anhalten. Ein Express-Writer passt nur zusammen mit einem Speicherdesign, das nicht bricht, wenn es mitten im Schreiben erfasst wird — also dort, wo Crash-Konsistenz ausreicht. Ist Zusammenarbeit am Ruhepunkt nötig, brauchen Sie eine vollständige Writer-Implementierung.

Ob ein eigener Writer nötig ist, entscheidet die Speicherweise

Die Faustregel ist einfach.

• Sie brauchen keinen, wenn die Daten in einer Datenbank wie SQL Server liegen. Der Writer der Datenbank garantiert die Konsistenz.¹
• Bei einfacher Dateispeicherung lösen Sie es zuerst im Design der Speicherroutine. Schreiben Sie in eine temporäre Datei und tauschen Sie sie per Umbenennen ein, sodass das Speichern atomar ist, hinterlässt selbst ein crash-konsistenter Snapshot keine beschädigte Speicherdatei.
• Einen Writer zu registrieren lohnt sich nur bei Anwendungen, die einen eigenen Datenspeicher über mehrere Dateien hinweg halten und am Ruhepunkt gegenseitige Konsistenz brauchen. Bevor Sie das tun, sollten Sie vielleicht zuerst prüfen, ob so viele Daten überhaupt in einem eigenen Format liegen sollten.

7. Fallstricke ── Vier Dinge, die im Betrieb wirklich zählen

Prüfen Sie nicht nur „haben wir einen Ruhepunkt erzeugt“, sondern auch „bleibt er erhalten“ und „ist die Qualität für eine Wiederherstellung ausreichend“. Die folgenden vier Punkte müssen im Betrieb getrennt betrachtet werden.

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. Sie ist keine separate vollständige Kopie: Beim Lesen werden die noch nicht überschriebenen Blöcke des ursprünglichen Volumes mit dem Differenzbereich zusammengeführt.

Deshalb deckt sie Ereignisse nicht ab, die das ursprüngliche Volume als Ganzes mitnehmen, etwa einen Festplattendefekt oder Diebstahl bzw. Verlust der Maschine. Den Differenzbereich allein auf ein anderes Volume zu legen ändert diese Abhängigkeit nicht. Und geht der Differenzbereich selbst verloren, lässt sich die Zusammenführung ebenfalls nicht mehr herstellen.

Auch gegen Ransomware, die das gesamte Volume verschlüsselt, sind Schattenkopien kein Verlass. Die Schreibvorgänge bei der Verschlüsselung legen den Inhalt vor dem Überschreiben beiseite, aber bei einem realen Angriff gehen sie durch Löschen der Schattenkopien oder durch Erschöpfung des Differenzbereichs durch massenhaftes Überschreiben verloren. Abschnitte 7.3 und 7.4 behandeln das.

Auch Microsofts Dokumentation zieht eine klare Grenze zwischen Schattenkopie und Backup: „Der auf ein Medium wie Band kopierte Inhalt ist das Backup, und die Schattenkopie darf nach der Kopie gelöscht werden“.¹ Eine Schattenkopie ist ein Ruhepunkt und ein schneller Weg, von einem Fehler wiederherzustellen. Sie ist kein Ersatz für ein Backup auf getrenntem Medium an einem getrennten Standort.

7.2. Writer-Fehler sind Probleme auf Anwendungsseite

Wenn Backup-Software mit einem „VSS-Fehler“ scheitert, prüfen Sie in dieser Reihenfolge.

1. Ermitteln Sie mit vssadmin list writers, welcher Writer fehlschlägt.
2. Prüfen Sie den Dienststatus der Anwendung oder Windows-Komponente, die diesen Writer bereitstellt.
3. Prüfen Sie die Anwendungs- und Systemereignisprotokolle und untersuchen Sie die Ursache auf Seiten der zuständigen Anwendung.

Ein Writer ist der Sache nach eine Komponente auf Seiten der Anwendung (oder der Windows-Komponente).¹ Sich vom Anschein „ein Fehler der Backup-Software“ leiten zu lassen und nur das Backup-Produkt zu untersuchen, ist der lange Weg. Die allgemeine Eingrenzung folgt dem Muster „Verdächtige aus beobachtbaren Fakten eingrenzen“, das in „Ein System ohne Quellcode und ohne Dokumentation übernehmen“ behandelt wird.

7.3. Ransomware kommt gezielt, um Schattenkopien zu löschen

Das sollten Verteidiger wissen. Wenn Vorgängerversionen eine Datei zurücksetzen können, müssten doch auch von Ransomware verschlüsselte Dateien zurücksetzbar sein — das ist die natürliche Hoffnung, aber es ist weithin bekannt, dass viele Ransomware-Varianten Schattenkopien vor oder nach der Verschlüsselung löschen, gerade um diesen Wiederherstellungsweg zu schließen. Das Löschen von Schattenkopien lässt sich mit legitimen Befehlen ausführen, sobald der Aufrufer Administratorrechte hat; es ist daher keine letzte Verteidigungslinie gegen einen Angreifer, der bereits drin ist. Die Gegenmaßnahmen ruhen deshalb auf drei Punkten.

• Behandeln Sie Schattenkopien nicht als „Teil des Wiederherstellungsplans“, sondern als „schön, wenn sie überleben“.
• Halten Sie ein separates Offline-Backup an einem anderen Standort vor, das ein Angreifer nicht erreichen kann.
• Geben Sie den Konten des Alltagsbetriebs keine Administratorrechte.

Zur Verteidigung des gesamten PC-Lebenszyklus einschließlich Backup, Verschlüsselung und Entsorgung siehe auch „BitLocker-Praxisleitfaden“ und „Checkliste zur PC-Entsorgung“.

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

Den Verbrauch bestimmt der Bereich, nicht die Zahl der Schreibvorgänge

Wie Kapitel 4 gezeigt hat, verbraucht Copy-on-Write den Differenzbereich, wenn jeder Block nach der Snapshot-Erstellung zum ersten Mal überschrieben wird. Das erneute Überschreiben eines bereits beiseitegelegten Blocks, so oft es auch geschieht, fügt nichts hinzu; der Verbrauch hängt also nicht von der „Zahl der Schreibvorgänge“ ab, sondern davon, „wie weit der Bereich der Blöcke reicht, die seit den gehaltenen Snapshots überschrieben wurden“.

Verschwundene Generationen auch im Systemprotokoll prüfen

Erreicht der Differenzbereich seine Obergrenze, werden die Schattenkopien dieses Volumes von der ältesten an gelöscht.¹ Dem interaktiven Benutzer wird nichts gemeldet, daher fällt es oft erst auf, wenn „wir sollten zur Version der letzten Woche zurückkehren können“ sich als falsch erweist. Es ist allerdings nicht völlig still: Im Systemprotokoll werden Ereignisse der Quelle volsnap erfasst (Ereignis 25, wenn eine Kopie gelöscht wurde, weil der Differenzbereich nicht gesichert werden konnte, und Ereignisse 35 und 36, wenn die Erweiterung scheiterte oder der Vorgang beim Erreichen der Obergrenze abgebrochen wurde, unter anderem). Neben der regelmäßigen Prüfung lassen sich diese volsnap-Ereignisse in Überwachung und Alarmierung aufnehmen, damit ein Verlust sofort auffällt.

Die benötigte Aufbewahrung mit der Nutzung des Differenzbereichs abgleichen

Vorgänge, die „einen weiten Teil des Volumes überstreichen“, etwa Massenaktualisierungen von Dateien, Stapelumwandlungen oder Defragmentierung, fressen den Differenzbereich auf einmal auf — genau wegen dieser Eigenschaft „bestimmt durch den überschriebenen Bereich“.

Prüfen Sie regelmäßig mit vssadmin list shadowstorage, ob die gehaltenen Generationen die betriebliche Anforderung erfüllen („nach wie vielen Tagen merken wir eine versehentliche Löschung spätestens?“), und heben Sie die Obergrenze bei Bedarf an.⁵¹⁰

8. Zusammenfassung

VSS lässt sich am klarsten halten, wenn Sie es in drei Fragen teilen: „was in Ordnung gebracht wird“, „wie gespeichert wird“ und „wie betrieben wird“.

Was in Ordnung gebracht wird: ein konsistenter Ruhepunkt, auch in Benutzung

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 „wir wollen eine konsistente Kopie, ohne 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.

Wie gespeichert wird: den Ruhepunkt schnell erzeugen, dann gesondert sichern

Der Systemprovider arbeitet nach Copy-on-Write, und der Ruhepunkt entsteht durch „Writer einfrieren (bis zu 60 Sekunden) → erstellen (innerhalb von 10 Sekunden) → auftauen“. Ohne Writer-Mitwirkung entsteht Crash-Konsistenz, mit Mitwirkung Anwendungskonsistenz.

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.

Wie betrieben wird: den Zustand prüfen und nur so weit eingreifen, wie nötig

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 Integrationsdesign 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.

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 und sichern“, die Ursachenermittlung bei Freigabeverletzungen rund um Dateiintegration und bei Backup-Fehlschlägen (VSS-Writer-Fehler) sowie die Ordnung von Betrieb und Generationenverwaltung 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 (diff area) 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- und 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 (Schattenkopiespeicher). 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 sind 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 Vorgängerversionen gibt, macht Backups nicht überflüssig, wie im Haupttext 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.