Збій копіювання Windows: перевірка VSS

Коротка відповідь: Якщо засіб резервного копіювання повідомляє саме про помилку VSS, запустіть від імені адміністратора командний рядок і виконайте vssadmin list writers. З’ясуйте, які VSS writers повідомляють про помилковий стан і що вказано в полі Last Error. Потім за точним часом збою перегляньте журнали програми й системи в Переглядачі подій та перевірте вільне місце у вихідному й цільовому сховищах; нічого не видаляйте й не перезавантажуйте навмання.

Що таке VSS і чому резервне копіювання завершується збоєм

Служба тіньового копіювання томів (Volume Shadow Copy Service, VSS) під час резервного копіювання координує роботу трьох сторін: програми резервного копіювання, так званих writers, які фіксують узгоджений стан даних програм, і provider, що створює самі тіньові копії на рівні сховища. Microsoft описує це в документації про архітектуру VSS architecture. Практичний наслідок дуже важливий: якщо резервне копіювання завершується збоєм, проблема може бути не в самому диску, а в будь-якому з цих трьох рівнів або в обміні даними між ними.

Також важливо пам’ятати, що тіньова копія та підтверджена резервна копія, яка зберігається окремо, — не одне й те саме. Тіньові копії можуть бути тимчасовими або збереженими, але сама їхня наявність не доводить, що резервне копіювання на незалежний носій завершилося успішно й дані можна відновити. Результатом має бути перевірена резервна копія, створена відповідним інструментом, а не лише знайдена shadow copy. Як налаштувати резервне копіювання у Windows 11 із самого початку — за допомогою Історії файлів або образу диска — описано в статті як створювати резервні копії Windows 11.

Що показує команда vssadmin list writers — і чого вона не показує

Відповідно до документації vssadmin list writers, команда vssadmin list writers виводить список підключених, тобто зареєстрованих, VSS writers. Згідно з оглядом команд vssadmin, інструмент vssadmin доступний також у Windows 10 і 11. Саме виведення списку не створює резервну копію й не видаляє тіньові копії — це діагностичний крок.

Чітко розрізняйте, що цей список підтверджує, а чого ні:

Список підтверджує:

• Перелік зареєстрованих writers, їхній стан і тип
• Останню помилку (Last Error) кожного writer
• Стан на момент виконання команди; час її запуску запишіть окремо

Список НЕ ПІДТВЕРДЖУЄ:

• Справність provider або цільового сховища — writers можуть повідомляти «Stable / No error», хоча резервне копіювання все одно завершується збоєм через цільовий диск або мережевий шлях
• Наявність достатнього вільного місця в області тіньових копій
• Узгодженість даних у завершеній резервній копії, якщо існує якась часткова копія

Отже, стани «Stable» і «No error» не означають, що проблему вирішено. Вони лише свідчать, що на момент виконання команди самі writers не повідомляли про помилку. Висновки щодо provider або цільового сховища потрібно робити за результатами наступних кроків.

Безпечна процедура крок за кроком

1. Запишіть точний час збою резервного копіювання з повідомлення відповідної програми — він потрібен для пошуку в журналах.
2. Відкрийте командний рядок від імені адміністратора на власній або авторизованій системі та виконайте vssadmin list writers. Команда виводить інформацію про зареєстровані writers, але не запускає резервне копіювання й не видаляє копії.
3. Запишіть для кожного writer три значення: ім’я, стан і Last Error. Важливо отримати список одразу після збою, а не наступного дня: за цей час стан може змінитися, і ви втратите важливий слід.
4. Відкрийте Переглядач подій і перейдіть до Журнали Windows → Програма та Журнали Windows → Система. Відфільтруйте записи за точним часом збою, охопивши кілька хвилин до та після нього. Не вгадуйте коди навмання — шукайте записи, час яких збігається з моментом збою завдання, і прочитайте їхній текст.
5. Перевірте вільне місце в цільовому сховищі та на вихідному томі. Брак місця — одна з обставин, які потрібно виключити. Необхідний обсяг і розмір області тіньових копій залежать від інструмента та конфігурації.
6. Перевірте, чи не було помилок введення-виведення на носії. Якщо резервне копіювання завершується збоєм через несправний носій, припиніть подальші спроби та спочатку захистіть дані. Якщо є підозра на несправність носія, не ремонтуйте оригінал і не виконуйте на ньому повторних перевірок, щоб не погіршити ситуацію. Пріоритетом є дані, а не пристрій.

Очікуваний результат: у вас разом зібрані стан writers, час збою, відповідні журнали та відомості про вільне місце на томах. Це може звузити коло можливих причин, хоча не завжди дає змогу однозначно визначити одну з них.

Безпечний запасний варіант: якщо writers повідомляють про помилку типу timeout, але журнали не показують зрозумілої причини, заплануйте перезавантаження звичайного комп’ютера поза робочим часом, попередньо зберігши всю відкриту роботу. Перезавантаження може змінити тимчасовий стан, тому спочатку збережіть діагностичні дані. Втручання в корпоративний комп’ютер або сервер узгодьте з адміністратором і виконуйте відповідно до внутрішніх правил експлуатації.

Чого в жодному разі не слід робити

• Не запускайте vssadmin delete shadows або vssadmin resize shadowstorage — ці команди змінюють чи видаляють тіньові копії та можуть погіршити стан навіть тих даних, що залишилися.
• Не реєструйте повторно навмання DLL-бібліотеки, пов’язані з VSS. Це зайве й надто агресивне втручання без чітко підтвердженої причини.
• Не перезапускайте служби навмання. Перезапуск служби без розуміння конкретної помилки може змінити стан, який потрібно задокументувати. Водночас звичайне перезавантаження не видаляє автоматично вже наявні події.
• Не вимикайте захист програмного забезпечення чи інші засоби безпеки — це не усуває проблему, а лише збільшує ризик.
• Якщо є підозра на несправність носія, не ремонтуйте оригінал і не запускайте на ньому нові спроби резервного копіювання; дані важливіші за пристрій.

Таблиця рішень

Якщо проблема стосується носія: дані мають пріоритет

Якщо з’ясується, що несправним є сам носій резервних копій або на шляху до нього виникають помилки введення-виведення, припиніть подальші спроби резервного копіювання. Повторний запуск завдання на несправному носії може завдати більше шкоди, ніж користі. Спочатку збережіть актуальні дані в іншому безпечному місці й лише після цього вирішуйте проблему з пристроєм або самим носієм. Не ремонтуйте чутливий оригінал, розміщений на диску з пошкодженими секторами чи на подібному проблемному носії, і не перевіряйте його безконтрольними поверхневими тестами. Якщо цього потребує ситуація, таку роботу слід доручити професійному сервісу.

Контрольний список для передавання та перевірка результату

Якщо ви намагаєтеся розв’язати проблему самостійно, а потім передаєте систему далі, наприклад колезі або сервісному центру, надайте такі відомості:

• Точний час збою завдання та назву завдання резервного копіювання
• Повний результат vssadmin list writers, отриманий одразу після збою: ім’я, стан і Last Error
• Відповідні записи з журналів Програма та Система із зазначенням часу й ідентифікатора події
• Виявлений обсяг вільного місця на джерелі та цілі
• Перелік виконаних кроків із зазначенням того, що допомогло, а що ні

Вважайте проблему вирішеною лише після виконання трьох умов:

1. Нове завдання резервного копіювання успішно завершилося без помилок.
2. Після нового завдання writers у списку не повідомляють про помилки. Однак пам’ятайте, що саме по собі це не гарантує справності provider і цільового сховища — тому потрібен пункт 3.
3. Ви успішно відновили з резервної копії зразок файлів до окремої папки та перевірили, що дані відкриваються й відповідають очікуваному вмісту. Відновлення до іншої папки не перезапише оригінальні файли та підтвердить придатність перевіреного зразка. Проте воно не доводить можливість відновлення всіх програм або всієї резервної копії.

Без останнього кроку навіть «успішна» резервна копія залишається лише твердженням у журналі. Для критично важливої програми додайте відповідний тест її відновлення та узгодженості, а не обмежуйтеся відкриттям кількох документів.

Часті запитання

Чи потрібно для діагностики VSS запускати командний рядок від імені адміністратора?

Так, для vssadmin потрібен командний рядок, запущений від імені адміністратора в системі, на роботу з якою ви маєте дозвіл. Команда vssadmin list writers не змінює дані, а лише виводить список зареєстрованих writers, що підтверджує документація Microsoft.

Чи означає стан «Stable» у writers, що все гаразд?

Ні. Writers можуть повідомляти Stable і No error, але резервне копіювання все одно може завершуватися збоєм через provider, цільове сховище або брак вільного місця. Список writers показує лише стан прикладного рівня, а не всього ланцюжка, тому далі перевірте журнали та вільне місце.

Чи можна видалити старі тіньові копії, якщо резервне копіювання завершується збоєм?

На цьому етапі я не рекомендую цього робити. Команди на кшталт vssadmin delete shadows змінюють стан тіньових копій і можуть погіршити ситуацію. Спочатку виконайте діагностику за допомогою списку writers і журналів, орієнтуючись на точний час збою.

Чи достатньо успішного нового завдання, щоб вважати проблему вирішеною?

Ні. Вважайте проблему вирішеною лише після успішного виконання нового завдання та подальшого відновлення зразка файлів до окремої папки. Крім того, тіньова копія — не те саме, що підтверджена резервна копія, яка зберігається окремо.

Чи варто замість діагностики просто перезавантажити комп’ютер?

Перезавантаження може допомогти на звичайному ПК, але лише після збереження роботи та як запланований крок, а не навмання. На корпоративних серверах так діяти не можна: перезавантаження потребує затвердженої процедури й запланованого вікна обслуговування. Нове успішне завдання та тест відновлення підтвердять результат виправлення, але не обов’язково первинну причину помилки.

Коли слід передати проблему технічному спеціалісту

Якщо помилка повторюється навіть після безпечної перевірки, підготуйте точний текст і час помилки, модель пристрою та результати описаних кроків. Для звичайного ремонту системи можна скористатися формою замовлення сервісу. Якщо під загрозою опинилися дані без резервної копії або сховище повідомляє про помилки читання, пріоритет мають дані: скористайтеся розділом про пристрої та відновлення даних і не продовжуйте ремонтувати оригінал.

Джерела та дата перевірки

Технічні джерела перевірено 4 жовтня 2026 року.

• Microsoft: vssadmin list writers
• Microsoft: vssadmin (огляд команд, також стосується Windows 10/11)
• Microsoft: VSS architecture