Windows-Sicherung fehlgeschlagen: VSS prüfen

Kurzantwort: Wenn das Sicherungsprogramm ausdrücklich einen VSS-Fehler meldet, führen Sie in einer als Administrator gestarteten Eingabeaufforderung den Befehl vssadmin list writers aus. Prüfen Sie, welche VSS Writers einen Fehlerstatus melden und welcher Wert unter Last Error steht. Untersuchen Sie anschließend anhand des exakten Fehlerzeitpunkts die Anwendungs- und Systemprotokolle in der Ereignisanzeige sowie den freien Speicherplatz auf Quell- und Zielspeicher. Löschen Sie nichts und führen Sie keinen unüberlegten Neustart durch.

Was VSS eigentlich ist und warum die Sicherung fehlschlägt

Der Volumeschattenkopie-Dienst (Volume Shadow Copy Service, VSS) koordiniert bei einer Sicherung drei Beteiligte: die Sicherungsanwendung, die sogenannten Writers, die einen konsistenten Zustand der Anwendungsdaten einfrieren, und den Provider, der die eigentlichen Schattenkopien auf Speicherebene erstellt. Microsoft beschreibt dies in der Dokumentation zur VSS architecture. Daraus folgt für die Praxis: Wenn eine Sicherung fehlschlägt, muss der Fehler nicht auf dem Datenträger selbst liegen. Er kann in jeder dieser drei Ebenen oder in ihrer Kommunikation untereinander auftreten.

Wichtig ist außerdem, dass eine Schattenkopie und eine bestätigte, getrennt gespeicherte Sicherung nicht dasselbe sind. Schattenkopien können temporär oder dauerhaft gespeichert sein; ihre bloße Existenz beweist weder eine abgeschlossene noch eine wiederherstellbare Sicherung auf einem unabhängigen Ziel. Entscheidend ist eine mit dem verwendeten Werkzeug überprüfte Sicherung, nicht lediglich eine gefundene Shadow Copy. Wie Sie eine Sicherung unter Windows 11 von Grund auf einrichten – mit Dateiversionsverlauf oder Systemabbild –, erläutert der Artikel Windows 11 sichern.

Was der Befehl vssadmin list writers aussagt – und was nicht

Der Befehl vssadmin list writers zeigt laut der Dokumentation zu vssadmin list writers die angemeldeten beziehungsweise registrierten VSS Writers an. Das Werkzeug vssadmin steht laut der Übersicht der vssadmin-Befehle auch unter Windows 10 und 11 zur Verfügung. Die Ausgabe selbst erstellt keine Sicherung und löscht keine Schattenkopien – sie dient ausschließlich der Diagnose.

Unterscheiden Sie sorgfältig, was die Ausgabe belegt und was nicht:

Die Ausgabe belegt:

• Die Liste der registrierten Writers sowie deren Status und Typ
• Den letzten Fehler (Last Error) der einzelnen Writers
• Den Zustand zum Zeitpunkt der Abfrage; notieren Sie den Zeitpunkt der Ausführung separat

Die Ausgabe belegt NICHT:

• Den Zustand des Providers oder des Zielspeichers – die Writers können „Stable / No error“ melden, obwohl die Sicherung wegen des Ziellaufwerks oder eines Netzwerkpfads fehlschlägt
• Ob im Schattenkopiespeicher genügend freier Platz vorhanden ist
• Die Konsistenz der Daten in einer abgeschlossenen Sicherung, falls eine unvollständige Sicherung vorhanden ist

Die Zustände „Stable“ und „No error“ bedeuten daher nicht, dass das Problem behoben ist. Sie zeigen lediglich, dass die Writers zum Zeitpunkt der Abfrage selbst keinen Fehler melden. Rückschlüsse auf den Provider oder den Zielspeicher müssen Sie aus den weiteren Prüfschritten ziehen.

Sicheres Vorgehen Schritt für Schritt

1. Notieren Sie den exakten Zeitpunkt, zu dem die Sicherung fehlgeschlagen ist, anhand der Meldung des Sicherungsprogramms. Dieser Zeitpunkt ist der Schlüssel zur Suche in den Protokollen.
2. Öffnen Sie die Eingabeaufforderung als Administrator auf Ihrem eigenen oder einem autorisierten System und führen Sie vssadmin list writers aus. Der Befehl zeigt Informationen zu den registrierten Writers an; er startet keine Sicherung und löscht keine Kopien.
3. Notieren Sie für jeden Writer drei Angaben: Name, Status und Last Error. Führen Sie die Abfrage möglichst unmittelbar nach dem Fehler aus, nicht erst einen Tag später. Der Zustand kann sich inzwischen ändern, wodurch eine wichtige Spur verloren geht.
4. Öffnen Sie die Ereignisanzeige und wechseln Sie zu Windows-Protokolle → Anwendung sowie Windows-Protokolle → System. Filtern Sie die Einträge nach dem exakten Fehlerzeitpunkt in einem Zeitfenster von einigen Minuten davor und danach. Raten Sie Fehlercodes nicht auf Verdacht, sondern suchen Sie Einträge, deren Zeitstempel mit dem Abbruch des Jobs übereinstimmt, und lesen Sie deren vollständigen Text.
5. Prüfen Sie den freien Speicherplatz auf dem Zielspeicher und dem Quellvolume. Zu wenig Speicherplatz gehört zu den möglichen Ursachen, die überprüft werden müssen. Der benötigte Platz und die Größe des Schattenkopiespeichers hängen vom verwendeten Werkzeug und seiner Konfiguration ab.
6. Prüfen Sie, ob auf dem Speichermedium ein I/O-Fehler aufgetreten ist. Falls die Sicherung wegen eines defekten Mediums fehlschlägt, beenden Sie weitere Versuche und sichern Sie zuerst die Daten. Reparieren oder untersuchen Sie das Original bei Verdacht auf einen Mediendefekt nicht wiederholt, damit sich die Situation nicht verschlimmert. Vorrang haben die Daten, nicht das Gerät.

Erwartetes Ergebnis: Sie haben den Status der Writers, den Fehlerzeitpunkt, die relevanten Protokolle und den verfügbaren Speicherplatz auf den Volumes zusammengetragen. Damit lässt sich die Ursache eingrenzen, auch wenn sie sich daraus nicht immer eindeutig bestimmen lässt.

Sichere Ausweichoption: Wenn die Writers einen Fehler wie Timeout melden, die Protokolle aber keine eindeutige Ursache zeigen, planen Sie den Neustart eines gewöhnlichen Computers außerhalb der Arbeitszeit – nachdem alle geöffneten Arbeiten gespeichert wurden. Ein Neustart kann einen vorübergehenden Zustand verändern; sichern Sie deshalb zunächst die Diagnosedaten. Auf einem Unternehmenscomputer oder Server stimmen Sie den Eingriff mit dem Administrator ab und halten die betrieblichen Vorgaben ein.

Was Sie keinesfalls tun sollten

• Führen Sie weder vssadmin delete shadows noch vssadmin resize shadowstorage aus. Diese Eingriffe verändern oder entfernen Schattenkopien und können die Situation auch für die verbliebenen Daten verschlimmern.
• Registrieren Sie keine mit VSS verbundenen DLL-Bibliotheken auf Verdacht neu. Das ist ein unnötig invasiver Eingriff ohne eindeutig nachgewiesene Ursache.
• Starten Sie Dienste nicht auf Verdacht neu. Ein Neustart des Dienstes kann den Zustand verändern, den Sie für die Diagnose dokumentieren müssen. Bereits vorhandene Ereignisse werden durch einen gewöhnlichen Neustart jedoch nicht automatisch gelöscht.
• Deaktivieren Sie weder Sicherheitssoftware noch andere Schutzmechanismen. Das löst das Problem nicht und erhöht das Risiko.
• Reparieren Sie bei Verdacht auf ein defektes Medium nicht das Original und starten Sie darauf keine weiteren Sicherungsversuche. Die Daten haben Vorrang vor dem Gerät.

Entscheidungstabelle

Wenn das Speichermedium betroffen ist: Daten haben Vorrang

Falls sich herausstellt, dass das Sicherungsmedium selbst oder die I/O-Verbindung dorthin fehlerhaft ist, beenden Sie weitere Sicherungsversuche. Wiederholte Jobs auf einem defekten Medium können mehr Schaden als Nutzen verursachen. Sichern Sie zuerst die aktuellen Daten an einem anderen sicheren Ort und kümmern Sie sich erst danach um das Gerät oder Medium. Reparieren Sie ein empfindliches Original auf einem Datenträger mit defekten Sektoren oder einem ähnlich problematischen Medium nicht und belasten Sie es nicht unkontrolliert mit Oberflächentests. Falls es die Situation erfordert, gehört diese Arbeit in die Hände eines Fachbetriebs.

Übergabe-Checkliste und Überprüfung des Ergebnisses

Wenn Sie das Problem selbst untersuchen und das System anschließend weitergeben, etwa an einen Kollegen oder einen Fachbetrieb, stellen Sie folgende Informationen bereit:

• Exakter Zeitpunkt des Jobfehlers und Name des Sicherungsjobs
• Vollständige Ausgabe von vssadmin list writers unmittelbar nach dem Fehler – Name, Status und Last Error
• Relevante Einträge aus den Anwendungs- und Systemprotokollen einschließlich Zeitpunkt und Ereignis-ID
• Ermittelter freier Speicherplatz auf Quelle und Ziel
• Liste der ausgeführten Schritte sowie der Maßnahmen, die geholfen oder nicht geholfen haben

Betrachten Sie das Problem erst als behoben, wenn drei Bedingungen erfüllt sind:

1. Ein neuer Sicherungsjob wurde erfolgreich und ohne Fehler abgeschlossen.
2. Die Writers melden in der Ausgabe nach dem neuen Job keinen Fehler. Beachten Sie jedoch, dass dies allein weder den Zustand des Providers noch des Ziels garantiert – deshalb ist Punkt 3 erforderlich.
3. Sie haben aus der Sicherung erfolgreich eine Stichprobe von Dateien in einen separaten Ordner wiederhergestellt und geprüft, ob sich die Daten öffnen lassen und inhaltlich stimmen. Die Wiederherstellung in einen anderen Ordner überschreibt keine Originaldateien und bestätigt die Nutzbarkeit der geprüften Stichprobe. Sie beweist jedoch nicht, dass sämtliche Anwendungen oder die gesamte Sicherung wiederhergestellt werden können.

Ohne diesen letzten Schritt ist selbst eine „erfolgreiche“ Sicherung lediglich eine Aussage im Protokoll. Führen Sie bei einer kritischen Anwendung zusätzlich einen passenden Test ihrer Wiederherstellung und Konsistenz durch, statt nur einige Dokumente zu öffnen.

Häufig gestellte Fragen

Muss ich die Eingabeaufforderung für die VSS-Diagnose als Administrator ausführen?

Ja, vssadmin erfordert eine als Administrator ausgeführte Eingabeaufforderung auf einem System, für das Sie eine entsprechende Berechtigung besitzen. vssadmin list writers verändert dabei keinerlei Daten, sondern zeigt lediglich die registrierten Writers an, wie die Microsoft-Dokumentation bestätigt.

Bedeutet der Status „Stable“ bei den Writers, dass alles in Ordnung ist?

Nein. Die Writers können Stable und No error melden, während die Sicherung dennoch wegen des Providers, des Zielspeichers oder mangelnden freien Speicherplatzes fehlschlägt. Die Writer-Ausgabe belegt nur den Zustand der Anwendungsebene, nicht den der übrigen Kette. Prüfen Sie deshalb zusätzlich die Protokolle und den verfügbaren Speicherplatz.

Kann ich alte Schattenkopien löschen, wenn die Sicherung fehlschlägt?

In dieser Phase ist davon abzuraten. Befehle wie vssadmin delete shadows verändern den Bestand der Schattenkopien und können die Situation verschlimmern. Beginnen Sie die Diagnose mit der Writer-Ausgabe und den Protokollen zum exakten Fehlerzeitpunkt.

Reicht ein erfolgreich ausgeführter neuer Job als Nachweis, dass das Problem behoben ist?

Nein. Betrachten Sie das Problem erst dann als behoben, wenn ein neuer Job erfolgreich abgeschlossen und anschließend eine Stichprobe von Dateien in einen separaten Ordner wiederhergestellt wurde. Eine Schattenkopie ist außerdem nicht dasselbe wie eine bestätigte, getrennt gespeicherte Sicherung.

Sollte man den Computer statt einer Diagnose einfach neu starten?

Bei einem gewöhnlichen PC kann ein Neustart helfen, allerdings erst nach dem Speichern aller Arbeiten und als geplanter Schritt, nicht auf Verdacht. Bei Unternehmensservern ist dieses Vorgehen ungeeignet – dort erfordert ein Neustart ein genehmigtes Verfahren und ein geplantes Wartungsfenster. Ein erfolgreicher neuer Job und ein Wiederherstellungstest bestätigen das Ergebnis der Fehlerbehebung, aber nicht automatisch die ursprüngliche Fehlerursache.

Wann Sie das Problem einem Techniker übergeben sollten

Wenn der Fehler auch nach einer sicheren Prüfung wiederholt auftritt, halten Sie den genauen Wortlaut und Zeitpunkt des Fehlers, das Gerätemodell sowie die Ergebnisse der beschriebenen Schritte bereit. Für eine gewöhnliche Systemreparatur können Sie den Serviceauftrag verwenden. Sind ungesicherte Daten gefährdet oder meldet der Speicher Lesefehler, haben die Daten Vorrang: Nutzen Sie die Übersicht für Geräte und Daten und führen Sie keine weiteren Reparaturen am Original durch.

Quellen und Prüfdatum

Die technischen Quellen wurden am 4. Oktober 2026 geprüft.

• Microsoft: vssadmin list writers
• Microsoft: vssadmin (Befehlsübersicht, gilt auch für Windows 10/11)
• Microsoft: VSS architecture