Záloha Windows selhala: jak prověřit VSS

Odpověď hned: Když zálohovací nástroj hlásí konkrétně chybu VSS, spusťte v příkazovém řádku spuštěném jako správce příkaz vssadmin list writers a zjistěte, kteří VSS writers hlásí chybový stav a jaké mají Last Error. Podle přesného času selhání pak projděte protokoly aplikace a systému ve Prohlížeči událostí a prohlédněte si volné místo na zdrojovém i cílovém úložišti; nic nemažte ani nerestartujte naslepo.

Co VSS vlastně je a proč selhává záloha

Služba Stínová kopie svazku (Volume Shadow Copy Service, VSS) koordinuje při záloze tři strany: zálohovací aplikaci, tzv. writers, které zmrazí konzistentní stav dat aplikací, a provider, který vytváří samotné stínové kopie na úrovni úložiště. Microsoft to popisuje ve své dokumentaci architektury VSS architecture. Praktický důsledek je zásadní: když záloha spadne, chyba nemusí být na disku samotném, ale v kterékoli z těchto tří rovin nebo v jejich vzájemné komunikaci.

Důležité je také pamatovat, že stínová kopie a potvrzená, odděleně uložená záloha nejsou totéž. Stínové kopie mohou být dočasné i uchovávané; jejich existence sama neprokazuje dokončenou a obnovitelnou zálohu na nezávislém cíli. Výsledkem má být ověřená záloha podle použitého nástroje, ne jen nalezená shadow copy. Jak zálohu ve Windows 11 nastavit od začátku (Historie souborů, obraz disku), popisuje článek jak zálohovat Windows 11.

Co příkaz vssadmin list writers říká – a co neříká

Příkaz vssadmin list writers podle dokumentace vssadmin list writers vypíše přihlášené (registrované) VSS writers. Nástroj vssadmin je podle přehledu příkazů vssadmin k dispozici i ve Windows 10 a 11. Výpis sám žádnou zálohu nevytváří ani nemaže stínové kopie – je to diagnostický krok.

Odlište pečlivě, co výpis prokazuje a co nikoli:

Výpis prokazuje:

• Seznam registrovaných writers, jejich stav a typ
• Poslední chybu (Last Error) jednotlivých writers
• Stav v okamžiku výpisu; čas spuštění výpisu si poznamenejte zvlášť

Výpis NEPROKAZUJE:

• Zdraví provideru ani cílového úložiště – writers můžou hlásit „Stable / No error” a záloha přesto padá kvůli cílovému disku nebo síťové cestě
• Dostatek volného místa ve stínové oblasti
• Konzistenci dat v dokončené záloze, pokud nějaká částečná existuje

Stav „Stable“ a „No error“ tedy neznamená, že je problém vyřešený – znamená jen, že writers samy v okamžiku výpisu nehlásí chybu. Závěr směrem k providerovi nebo cílovému úložišti musíte udělat z dalších kroků.

Bezpečný postup krok za krokem

1. Zaznamenejte přesný čas selhání zálohy z hlášení zálohovacího nástroje – čas je klíčem k prohledávání protokolů.
2. Otevřete příkazový řádek jako správce na vlastním nebo autorizovaném systému a spusťte vssadmin list writers. Příkaz vypisuje informace o registrovaných writers; nespouští zálohu ani nemaže kopie.
3. Zapište si u každého writeru tři údaje: jméno, stav a Last Error. Důležité je provést výpis těsně po selhání, ne o den později – stav se může v mezidobí změnit a ztratíte tak stopu.
4. Otevřete Prohlížeč událostí a jděte do Protokoly systému Windows → Aplikace a Protokoly systému Windows → Systém. Filtrujte záznamy podle přesného času selhání, v okně plus minus pár minut. Nehádejte kódy naslepo – hledejte záznamy, jejichž čas sedí na moment pádu úlohy, a přečtěte si jejich text.
5. Zkontrolujte volné místo na cílovém úložišti i na zdrojovém svazku. Nedostatek místa je jedna z okolností k ověření. Potřebný prostor a stínová oblast závisejí na nástroji a konfiguraci.
6. Ověřte, zda nedošlo k výpadku I/O na médiu. Pokud záloha padá na vadném médiu, zastavte další pokusy a nejdřív zabezpečte data – originál při podezření na vadu médií neopravujte a neprocházejte znovu, aby se situace nezhoršila. Prioritou jsou data, ne zařízení.

Očekávaný výsledek: máte společně zaznamenaný stav writers, čas selhání, relevantní protokoly a prostor na svazcích. To může zúžit příčinu, ale nemusí ji samo jednoznačně určit.

Bezpečná náhradní větev: pokud writers hlásí chybu typu timeout, ale protokoly neukazují jasnou příčinu, naplánujte restart běžného počítače mimo pracovní dobu – po uložení veškeré otevřené práce. Restart může změnit přechodný stav; nejprve proto uchovejte diagnostické údaje. Na firemním počítači či serveru zásah domluvte se správcem a podle provozních pravidel.

Co v žádném případě nedělat

• Nespouštějte vssadmin delete shadows ani vssadmin resize shadowstorage – tyto zásahy mění nebo ruší stínové kopie a mohou zhoršit situaci i u zbývajících dat.
• Nepřeregistrovávejte naslepo žádné DLL knihovny související s VSS; je to zbytečně invazivní krok bez jasně prokázané příčiny.
• Nerestartujte služby naslepo. Restart služby bez znalosti konkrétní chyby může změnit stav, který potřebujete zdokumentovat. Existující události ale běžný restart automaticky nemaže.
• Nevypínejte zabezpečení softwaru ani jiné ochrany – to řešení není a riziko roste.
• U podezření na vadné médium neopravujte originál a nespouštějte na něm další pokusy o zálohu; data mají přednost před zařízením.

Rozhodovací tabulka

Když je dotčené médium: data mají přednost

Pokud se ukáže, že vadné je samo záložní médium nebo I/O na cestě k němu, zastavte další zálohovací pokusy. Opakované spouštění úlohy na vadném médiu může způsobit víc škody než užitku. Nejdřív zabezpečte aktuální data do jiného bezpečného umístění, teprve poté řešte zařízení nebo médium samotné. Citlivý originál, který leží na disku s chybnými sektory nebo podobně problematickém nosiči, neopravujte ani skenováním typu surface testů nekontrolovaně – to je práce pro odborný servis, pokud to situace vyžaduje.

Předávací checklist a ověření výsledku

Pokud problém řešíte sami a předáváte systém dál (např. kolegovi nebo servisu), předejte tyto údaje:

• Přesný čas selhání jobu a jméno zálohovací úlohy
• Kompletní výstup vssadmin list writers těsně po selhání – jméno, stav, Last Error
• Relevantní záznamy z protokolů Aplikace a Systém včetně času a ID události
• Zjištěný stav volného místa na zdroji a cíli
• Seznam provedených kroků a toho, co pomohlo či nepomohlo

Problém považujte za vyřešený až po splnění tří podmínek:

1. Nový zálohovací job proběhl úspěšně bez chyb.
2. Writers ve výpisu po novém jobu nehlásí chybu (vězte ale, že ani to samo o sobě negarantuje zdraví provideru a cíle – proto bod 3).
3. Ze zálohy jste úspěšně obnovili vzorek souborů do samostatné složky a ověřili, že se data otevřou a odpovídají. Test do jiné složky nepřepíše původní soubory a potvrdí použitelnost ověřeného vzorku. Není to důkaz obnovitelnosti všech aplikací či celé zálohy.

Bez toho posledního kroku je i „úspěšná“ záloha jen tvrzení v protokolu. U kritické aplikace přidejte odpovídající test její obnovy a konzistence, nejen otevření několika dokumentů.

Často se ptáte

Musím na diagnostiku VSS použít příkazový řádek jako správce?

Ano, vssadmin vyžaduje příkazový řádek spuštěný jako správce na systému, ke kterému máte oprávnění. Samotný vssadmin list writers přitom data nijak nemění, jen vypisuje registrované writers, jak potvrzuje dokumentace Microsoftu.

Znamená stav „Stable“ u writers, že je vše v pořádku?

Nikoli. Writers můžou hlásit Stable a No error, přesto záloha padá kvůli provideru, cílovému úložišti nebo volnému místu. Výpis writerů prokazuje jen stav aplikační vrstvy, ne zbytek řetězce, proto pokračujte protokoly a kontrolou místa.

Můžu smazat staré stínové kopie, když záloha padá?

Nedoporučuji to v této fázi. Příkazy typu vssadmin delete shadows mění stav stínových kopií a mohou situaci zhoršit. Diagnostiku veďte nejdřív výpisem writers a protokoly podle přesného času selhání.

Stačí úspěšný nový job jako důkaz vyřešení problému?

Ne. Problém považujte za vyřešený až po úspěšném novém jobu a následné obnově vzorku souborů do samostatné složky. Stínová kopie navíc není totéž co potvrzená, odděleně uložená záloha.

Má se místo diagnostiky prostě restartovat počítač?

Restart může pomoct u běžného PC, ale až po uložení práce a jako plánovaný krok, ne naslepo. Na firemních serverech to takto nefunguje – tam vyžaduje restart schválený postup a plánované okno údržby. Nový úspěšný job a test obnovy ověří výsledek nápravy, nikoli automaticky původní příčinu chyby.

Kdy předat problém technikovi

Pokud se chyba opakuje i po bezpečné kontrole, připravte přesný text a čas chyby, model zařízení a výsledek popsaných kroků. Pro běžnou opravu systému můžete použít servisní objednávku. Pokud jsou ohrožena nezálohovaná data nebo úložiště hlásí chyby čtení, mají přednost data: použijte rozcestník zařízení a dat a nepokračujte v opravách originálu.

Zdroje a datum kontroly

Technické zdroje byly zkontrolovány 4. října 2026.

• Microsoft: vssadmin list writers
• Microsoft: vssadmin (přehled příkazů, platí i pro Windows 10/11)
• Microsoft: VSS architecture