Woran Sie erkennen, dass es dieser Fall ist
- Die Sicherung wurde mit Fehlern abgeschlossen.
- Backup failed: VSS snapshot creation failed
- Der Schattenkopieanbieter hat einen unerwarteten Fehler festgestellt.
- Writer state: [8] Failed – Non-retryable error
- Nicht genügend Speicherplatz auf dem Datenträger.
- Zeitüberschreitung bei der Verbindung mit dem Sicherungsziel
Zugehörige Fehlercodes
- 0x80042306
- 0x8004230F
- 0x80042316
- 0x800423F4
- VSS 8193
- VSS 12289
Die schnelle Hilfe, in dieser Reihenfolge
Das Protokoll der Sicherungssoftware lesen – ganz
Nicht die Zusammenfassung, sondern die letzte Fehlermeldung vor dem Abbruch. Dort steht, ob der Agent nicht starten konnte, der Snapshot scheiterte, der Platz fehlte oder das Ziel nicht antwortete. Jede dieser vier Ursachen hat einen anderen Weg; wer bei der falschen anfängt, verliert eine Stunde.
Damit wissen Sie: Sie wissen, in welcher der vier Gruppen der Fehler liegt.
Dienst prüfen
Der Sicherungsdienst muss laufen und automatisch starten. Nach Windows-Updates, nach einem Absturz oder nach einer Umstellung von Konten steht er gelegentlich still – ohne Meldung, weil niemand ihn fragt. Ein gestoppter Dienst mit Starttyp Automatisch heißt: Er ist abgestürzt; das Systemprotokoll zeigt wann.
Damit wissen Sie: Dienst läuft oder ist neu gestartet; bei wiederholtem Absturz steht die Uhrzeit fest.
VSS-Writer prüfen
Der Volumeschattenkopie-Dienst erzeugt den konsistenten Stand, den jede Sicherung liest. Jeder beteiligte Dienst – SQL Server, Exchange, Hyper-V, das System selbst – hat einen eigenen Writer. Steht einer auf Failed, bricht die Sicherung ab. Der Writer wird zurückgesetzt, indem der zugehörige Dienst neu gestartet wird; die Tabelle im Abschnitt unten nennt die Zuordnung.
Damit wissen Sie: Alle Writer stehen auf Stable / No error.
Platz und Verbindung
VSS braucht freien Platz auf dem Laufwerk, das gesichert wird – als Faustregel mindestens zehn Prozent, bei großen Änderungsmengen mehr. Ein volles Laufwerk ist eine stille Ursache, weil die Meldung nicht vom Platz spricht, sondern vom Snapshot. Und der Agent muss sein Ziel erreichen: Satellit oder Rechenzentrum, auf Port 443. Nach Firewall-Änderungen ist das die erste Frage.
Damit wissen Sie: Freier Platz über zehn Prozent, Ziel erreichbar.
Sicherung von Hand starten und das Ergebnis abwarten
Erst wenn ein manueller Lauf durchläuft, ist der Fehler behoben. Dann die Frage, die wichtiger ist als die Ursache: Warum ist der Fehlschlag erst jetzt aufgefallen? Wer die Berichte der Sicherung nicht liest – oder keine bekommt –, erfährt vom Problem am Tag, an dem er die Sicherung braucht.
Damit wissen Sie: Ein erfolgreicher Lauf; und die Entscheidung, wer Berichte wie liest.
Dasselbe in PowerShell
Für alle, die mehr als einen Rechner betreuen
Die Befehle prüfen die vier Dinge, an denen Sicherungen auf Windows am häufigsten scheitern: der Dienst, der Schattenkopiedienst, der Platz und die Verbindung. Sie ändern nichts – mit einer Ausnahme, die als solche markiert ist.
PowerShell mit erweiterten Rechten starten – so geht es
- Windows 11
- Rechtsklick auf das Startsymbol – oder die Tastenkombination Windows + X – und dann Terminal (Administrator) wählen.
- Windows 10
- Dieselbe Tastenkombination, der Eintrag heißt dort Windows PowerShell (Administrator). Steht dort stattdessen die Eingabeaufforderung, lässt sich das in den Taskleisteneinstellungen umstellen – oder Sie nehmen den Weg darunter.
- Auf jedem Windows
- Startmenü öffnen, powershell tippen und den Treffer mit Strg + Umschalt + Eingabe öffnen. Das ist der Weg, der überall funktioniert.
- Woran Sie erkennen, dass es geklappt hat
- In der Titelleiste des Fensters steht Administrator, und die Eingabeaufforderung beginnt in C:\Windows\System32 statt in Ihrem Benutzerordner. Vorher bestätigen Sie die Abfrage der Benutzerkontensteuerung mit Ja.
- Wenn nach Zugangsdaten gefragt wird
- Dann sind Sie auf diesem Rechner kein Administrator. Im Firmennetz ist das der Regelfall und Absicht: Wer täglich mit erhöhten Rechten arbeitet, gibt einer Schadsoftware dieselben Rechte. Der richtige Weg ist die Zuarbeit durch die Administration – nicht das dauerhafte Hochstufen des eigenen Kontos.
Ein Hinweis, der wichtiger ist als er klingt: Führen Sie keinen Befehl aus, dessen Wirkung Sie nicht benennen können – auch keinen von uns. Die Blöcke unten sagen jeweils dazu, was sie tun; die, die etwas verändern, sind gekennzeichnet.
Läuft der Sicherungsdienst – und seit wann?
Ein Agent, der nach einem Update nicht wieder gestartet ist, meldet keinen Fehler, er meldet gar nichts. Die Dienstliste zeigt beides: ob er läuft und ob der Starttyp stimmt.
PS C:\> Get-Service | Where-Object { $_.DisplayName -match 'Backup|Sicherung|Agent' } | Select-Object Name, DisplayName, Status, StartTypeName DisplayName Status StartType---- ----------- ------ ---------<Agentdienst> <Backup-Agent> Stopped Automatic# Status Stopped bei StartType Automatic: der Dienst ist abgestürzt oder wurde beendetPS C:\> Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 7031, 7034, 7036; StartTime = (Get-Date).AddDays(-2) } | Where-Object Message -match '<Agentdienst>' | Select-Object TimeCreated, Id, Message | Format-List# 7031/7034 = unerwartet beendet, 7036 = Zustandswechsel mit ZeitDer Schattenkopiedienst: die häufigste Ursache
Fast jede Sicherungssoftware unter Windows nutzt den Volumeschattenkopie-Dienst (VSS), um laufende Dateien konsistent zu lesen. Ein einziger Writer im Zustand Failed lässt die ganze Sicherung scheitern.
PS C:\> vssadmin list writersWriter name: 'Microsoft Hyper-V VSS Writer' State: [1] Stable Last error: No errorWriter name: 'SqlServerWriter' State: [8] Failed Last error: Non-retryable error# Jeder Writer, der nicht Stable / No error zeigt, ist ein KandidatPS C:\> Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'VSS', 'volsnap'; StartTime = (Get-Date).AddDays(-1) } | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List# Schattenkopiespeicher je Laufwerk: zu wenig Platz = Snapshot wird verworfenPS C:\> vssadmin list shadowstorageEinen hängenden VSS-Writer zurücksetzen
Writer hängen an Diensten. Den zuständigen Dienst neu zu starten setzt den Writer zurück – ohne Neustart des Servers. Welcher Dienst zu welchem Writer gehört, sagt die Tabelle im Text.
# Beispiel SqlServerWriter: Dienst SQL Server VSS WriterPS C:\> Restart-Service -Name SQLWriter# Beispiel System Writer: KryptografiedienstePS C:\> Restart-Service -Name CryptSvc# Danach prüfenPS C:\> vssadmin list writers | Select-String -Pattern 'Writer name|State|Last error'Das verändert etwas: Ein Dienstneustart unterbricht, was der Dienst gerade tut – bei einem Datenbankdienst sind das laufende Verbindungen. Den Writer des Datenbankservers deshalb nur außerhalb der Arbeitszeit zurücksetzen, und den Hyper-V-Writer nie, während eine VM gesichert wird.
Platz und Verbindung
Zwei unspektakuläre Ursachen, die beide in einer Minute geklärt sind: Ein Laufwerk unter zehn Prozent frei bringt VSS zum Scheitern; ein Agent, der das Rechenzentrum nicht erreicht, meldet Zeitüberschreitung.
PS C:\> Get-PSDrive -PSProvider FileSystem | Select-Object Name, @{ n = 'FreiGB'; e = { [math]::Round($_.Free / 1GB, 1) } }, @{ n = 'GesamtGB'; e = { [math]::Round(($_.Used + $_.Free) / 1GB, 1) } }# Erreichbarkeit des Sicherungsziels – Adresse und Port stehen in der AgentkonfigurationPS C:\> Test-NetConnection -ComputerName <Sicherungsziel> -Port 443TcpTestSucceeded : True# Beim Satelliten im eigenen Netz: dessen Adresse statt des RechenzentrumsPS C:\> Test-NetConnection -ComputerName <Satellit> -Port 443Welcher Dienst gehört zu welchem VSS-Writer?
Die Zuordnung ist der nützlichste Teil dieser Seite, weil sie in keiner Fehlermeldung steht. Der System Writer hängt an den Kryptografiediensten (CryptSvc), der SqlServerWriter am Dienst SQL Server VSS Writer (SQLWriter), der Microsoft Exchange Writer am Informationsspeicher von Exchange, der Microsoft Hyper-V VSS Writer an der Hyper-V-Verwaltung (vmms), der WMI Writer an der Windows-Verwaltungsinstrumentation (winmgmt), der Registry Writer und der Shadow Copy Optimization Writer am VSS-Dienst selbst.
Der Neustart des zugehörigen Dienstes setzt den Writer zurück. Das ist bei den Kryptografiediensten unkritisch, bei SQL Server und Exchange nicht – dort gehen laufende Verbindungen verloren. Deshalb: Writer von Datenbank- und Maildiensten außerhalb der Arbeitszeit zurücksetzen, den Hyper-V-Writer nie, während eine VM gesichert wird.
Bleibt ein Writer nach dem Neustart des Dienstes auf Failed, ist meist ein Snapshot-Rest schuld: eine Schattenkopie, die nicht aufgeräumt wurde. Die Liste der Schattenkopien zeigt sie; das Löschen alter Kopien gehört aber nur in Hände, die wissen, dass damit auch die Vorgängerversionen weg sind, die Nutzer über den Explorer erreichen.
Warum scheitert die Sicherung immer in derselben Nacht?
Weil in dieser Nacht etwas anderes läuft: der Virenscan, die Datenbankwartung, das Windows-Update, die Replikation des Satelliten. Zwei Vorgänge, die zur selben Zeit einen Snapshot wollen oder den Datenträger auslasten, behindern sich – und der, der später kommt, bekommt die Zeitüberschreitung.
Die Zeitpläne liegen in vier verschiedenen Programmen und werden selten nebeneinander gelegt. Genau das ist der Fehler. Auf einem Blatt – was läuft wann, wie lange – zeigt sich die Überschneidung sofort; die Lösung ist eine halbe Stunde Versatz, nicht mehr Hardware.
Die zweite Variante derselben Ursache: Die Sicherung dauert länger, als das Fenster lang ist, weil die Datenmenge gewachsen ist. Dann bricht sie nicht wegen eines Fehlers ab, sondern weil ein Folgelauf sie überholt. Das steht im Protokoll als Dauer – und ist der Moment, über Satellit oder Inkrementalsicherung nachzudenken.
Was heißt „mit Fehlern abgeschlossen“ – ist die Sicherung brauchbar?
Teilweise. Die Meldung sagt, dass einzelne Dateien oder Objekte übersprungen wurden – geöffnete Dateien ohne VSS, Pfade über 260 Zeichen, Dateien ohne Leserecht für das Sicherungskonto, ein Laufwerk, das nicht mehr da ist. Der Rest ist gesichert.
Brauchbar ist die Sicherung also für alles außer dem, was fehlt – und was fehlt, steht in der Fehlerliste des Laufs. Wer die nicht liest, erfährt es bei der Wiederherstellung. Ein Lauf mit zehn übersprungenen Temp-Dateien ist in Ordnung; einer, der den Datenbankordner übersprungen hat, ist keine Sicherung.
Deshalb gilt im Betrieb: „Mit Fehlern abgeschlossen“ wird behandelt wie „fehlgeschlagen“, bis jemand die Liste gelesen und entschieden hat. Diese Entscheidung gehört ins Protokoll, nicht in den Kopf des Administrators.
Im Betrieb
Eine Sicherung, deren Fehlschlag niemand bemerkt, ist keine.
Der Fall, der im Betrieb teuer wird: Die Sicherung schlägt seit drei Wochen fehl, die Berichte gehen an ein Postfach, das niemand liest, und der Verschlüsselungsangriff kommt in der vierten Woche. Technisch war alles vorhanden – Software, Lizenz, Speicher. Es fehlte die Person, die jeden Morgen zwei Minuten auf das Ergebnis schaut.
Beim Cloud-Backup im Rechenzentrum unseres Partners TERRA CLOUD gehört die Überwachung zum Dienst: Jeder Lauf meldet sein Ergebnis an uns, ein fehlgeschlagener wird am selben Tag bearbeitet, und die automatisierte Testwiederherstellung mit Bericht prüft, ob das Gesicherte auch zurückkommt – nach Herstellerangabe Teil des Angebots, bei uns Standard. Das Protokoll daraus ist Beleg 2 der Nachweismappe.
Die Frage an Ihr Haus ist deshalb nicht, ob die Sicherung läuft, sondern wer es wüsste, wenn nicht. Eine Antwort, die eine Person nennt, ist eine gute Antwort. Eine, die „das würde auffallen“ lautet, ist keine.
Wann Sie aufhören sollten zu probieren
Alles bis zum Dienstneustart gehört in die Hand des Administrators vor Ort. Die Grenze liegt beim Löschen von Schattenkopien und bei Writern, die auch nach Neustart des Dienstes auf Failed bleiben – ab dort wird am Zustand des Servers gearbeitet, nicht mehr an der Sicherung, und das gehört in ein Wartungsfenster mit vorheriger Vollsicherung auf anderem Weg.
Häufige Anschlussfragen
Hilft ein Neustart des Servers?
Oft ja, weil er alle Writer zurücksetzt – aber er ist der Holzhammer, und er sagt nichts über die Ursache. Wer vorher die Writer-Liste und das Systemprotokoll ansieht, weiß nach dem Neustart, ob der Fehler wiederkommt. Wer nur neu startet, weiß es erst in der nächsten Nacht.
Die Sicherung läuft, aber dauert jede Nacht länger – ist das ein Fehler?
Es ist eine Vorwarnung. Wächst die Dauer, wächst die Datenmenge oder die Änderungsrate, oder ein Datenträger wird langsamer. Spätestens wenn die Sicherung ins Arbeitszeitfenster hineinragt, bricht sie ab. Die Dauer je Lauf gehört deshalb in die Berichte, die jemand liest – und ein Trend über vier Wochen ist der Moment für Satellit oder schnelleren Speicher.
Reicht es, die Sicherung auf einen anderen Tag zu verschieben?
Als Sofortmaßnahme ja, wenn eine Überschneidung mit einem anderen Lauf die Ursache ist. Als Dauerlösung nein: Jeder Tag ohne Sicherung ist ein Tag, dessen Arbeit im Ernstfall verloren wäre. Der Wiederherstellungspunkt, den Sie mit der Geschäftsführung vereinbart haben, lässt sich nicht durch Verschieben einhalten.
Wir sichern auf ein NAS und das meldet nie Fehler. Ist das gut?
Es ist verdächtig. Entweder ist alles in Ordnung, oder niemand sieht die Meldungen. Beides lässt sich mit einer Probe unterscheiden: eine Datei aus der Sicherung von vor zwei Wochen zurückholen. Dauert das länger als eine Viertelstunde oder scheitert es, haben Sie die Antwort – und der Beitrag zur geprobten Rücksicherung beschreibt, wie daraus ein Nachweis wird.
Dazu passt