Служба теневого копирования тома (VSS): как снимают резервную копию занятого файла

«Попытался скопировать файл, который открыло другое приложение, и получил отказ: процесс не может получить доступ к файлу.» «Нас попросили снять резервную копию папки с данными, не останавливая основную систему.» «Почему программа резервного копирования спокойно копирует файл базы данных, который ещё используется?» — И в разработке бизнес-приложений, и в эксплуатации файловых серверов с этими вопросами рано или поздно сталкиваешься.

В центре ответа стоит служба теневого копирования тома (VSS, Volume Shadow Copy Service). Она встроена в Windows уже больше двадцати лет. Windows Server Backup, восстановление системы и почти все коммерческие продукты резервного копирования опираются на этот же механизм.¹

Статья рассчитана на разработчиков бизнес-приложений, которым поручают функцию «скопировать файл, который ещё используется», и на системных администраторов, которые ведут резервное копирование файловых серверов и рабочих ПК. По первичным источникам на август 2026 года она разбирает роли VSS и то, как служба работает, повседневную практику через vssadmin и где должна проходить граница: насколько глубоко разработчику стоит ввязываться в VSS. Серия «Глубины ввода-вывода Windows» смотрела внутрь диспетчера кэша и NTFS; эта статья — её продолжение, про слой снимка, который перехватывает ввод-вывод непосредственно над томом.

1. Коротко

• VSS — это набор COM-интерфейсов и координирующая служба, которые позволяют снимать резервную копию тома, пока приложение продолжает на него писать. Служба встроена в Windows начиная с Windows XP.²
• Ролей три плюс координатор. Служба VSS посредничает между запрашивающей стороной (requester), которая просит создать теневую копию (программа резервного копирования), модулем записи (writer), который на стороне приложения гарантирует согласованность данных (например, SQL Server), и поставщиком (provider), который реально создаёт снимок.¹
• Штатный системный поставщик Windows использует копирование при записи (copy-on-write). Вместо того чтобы дублировать весь том, в область различий (diff area) копируются только блоки, которые после снимка перезаписывают, — и только их содержимое до записи. Область различий должна лежать на томе NTFS.¹
• Точка покоя создаётся так: заморозка модулей записи (до 60 секунд) → создание снимка (за 10 секунд) → разморозка. Если любой из лимитов превышен, создание прерывается, и запрашивающая сторона пробует снова.¹
• Участвует ли модуль записи — от этого меняется качество копии. Снимок без участия модуля записи эквивалентен «диску в миг, когда выдернули питание» (согласованность при сбое, crash consistent). Снимок с участием уже свернул журналы и сбросил кэши: это согласованное состояние, которое само приложение гарантирует восстановимым (согласованность на уровне приложения, application consistent).³¹
• Инструмент проверки состояния — vssadmin. Через list shadows / list writers / list shadowstorage смотрите текущее состояние, через resize shadowstorage подстраивайте предел области различий. Когда область различий кончается, самые старые теневые копии удаляются без уведомления.⁴⁵¹
• Встроить запрашивающую сторону VSS в своё приложение — большая работа. Это нативный API на COM, официальной обёртки для .NET нет. В большинстве случаев хватает повторов, подстройки режима общего доступа или короткой остановки. Если VSS действительно нужен, практический ответ — скрипт DiskShadow (только Windows Server).⁶⁷
• Теневая копия сама по себе не является резервной копией. Разность копирования при записи зависит от нетронутых блоков исходного тома, поэтому она бессильна против отказа, который уносит исходный том целиком, — отказ диска, кража. На программы-вымогатели тоже нельзя положиться: сами теневые копии могут удалить (раздел 7.3) или область различий исчерпать массовой перезаписью (раздел 7.4). Смысл появляется только в связке с резервными копиями на отдельном носителе.¹

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 26, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Постановка задачи: почему занятый файл нельзя просто скопировать

Отправная точка — режим общего доступа к файлам в Windows. Когда процесс открывает файл (CreateFile), он режимом общего доступа (dwShareMode) объявляет что другим процессам разрешено делать с файлом, пока он открыт. Пока какой-то процесс держит файл открытым так, что совместное чтение не разрешено, любой процесс, который позже попытается открыть его на чтение, получит нарушение совместного доступа (ERROR_SHARING_VIOLATION, ошибка 32).⁸ В .NET это знакомый IOException («Процесс не может получить доступ к файлу, так как этот файл используется другим процессом»).

Важно, что это не ошибка, а штатный механизм защиты данных. Если файл, в который пишут, прочитать посередине, читатель получит недописанное промежуточное состояние. Как подробно разобрано в «Основах взаимного исключения при файловой интеграции — лучших практиках файловых блокировок и атомарного claim», проектирование взаимного исключения — фундамент обмена данными между приложениями.

Но этот правильный механизм принципиально конфликтует с резервным копированием.

• Нарушение совместного доступа: файл, который база данных или бизнес-приложение держит открытым, может быть вообще нельзя открыть как источник копирования.
• Согласованность: даже если открыть получается (потому что совместное чтение разрешено), копирование занимает время. Пока копия идёт, приложение продолжает писать, поэтому первая и вторая половины файла могут отражать разные моменты времени, или несколько файлов (файл данных и его журнал) могут разъехаться. И как мы видели в выпуске про «диспетчер кэша», запись сначала попадает в кэш в памяти, так что смотреть только на файл на диске ещё не значит видеть самое свежее содержимое.
• Эксплуатация: «тогда просто остановите приложение и скопируйте» — в принципе разумный ответ, но для круглосуточной бизнес-системы или файлового сервера он неприемлем.

Иными словами, нужно согласованное состояние на один момент времени, не останавливая приложение. Отдельным приложениям это слишком тяжело решать самостоятельно, поэтому VSS сделали механизмом уровня ОС. VSS предлагается как каркас COM-интерфейсов, который позволяет снимать резервную копию тома, даже пока приложение продолжает на него писать.²

3. Роли VSS: запрашивающая сторона, модуль записи, поставщик

VSS раскладывается на три роли и службу, которая между ними посредничает.¹

Смысл этого разделения в том, что продукты, которые ничего друг о друге не знают, всё равно могут согласовать работу. Программа резервного копирования (запрашивающая сторона) не знает внутреннюю структуру SQL Server, но модуль записи SQL Server объявляет метаданными, какие файлы (компоненты) нужно копировать, и приводит свои данные в порядок сразу вокруг точки покоя — поэтому запрашивающая сторона может снять согласованную копию, просто следуя за этим.¹⁹ Почти каждый сторонний продукт резервного копирования, который работает на Windows, является запрашивающей стороной VSS.¹

В эксплуатации эти три роли нужно различать при диагностике. Отказ резервного копирования — это проблема запрашивающей стороны (сторона ПО), конкретного модуля записи (сторона приложения) или поставщика и области различий (сторона инфраструктуры)? От ответа целиком зависит, куда смотреть (разделы 5 и 7).

4. Как устроен снимок: копирование при записи и точка покоя

4.1. Копирование при записи: сохранить момент, не дублируя том

Слово «снимок» заставляет представить дублирование всего тома, но метод, которым на самом деле пользуется штатный системный поставщик Windows, — копирование при записи (copy-on-write). В момент снятия снимка почти ничего не копируется. Позже, когда блок исходного тома собираются перезаписать, содержимое этого блока до записи копируют в область различий (diff area, хранилище теневых копий) до того, как перезапись завершится, и только тогда запись пропускают.¹ Копировать нужно только при первой перезаписи каждого блока; перезапись уже сохранённого блока область различий больше не растит.

Чтобы прочитать «том, каким он был в тот миг», неизменённые блоки читают с исходного тома, изменённые — из области различий, и два потока складывают. Поскольку копируется только изменившаяся часть, создание мгновенно, а место занимает только разность. Оборотная сторона: чем интенсивнее пишут на том, тем быстрее расходуется область различий (об этом дальше в разделе 7), и область различий лежит на томе NTFS той же машины, что и исходные данные.¹ Этот механизм опирается на файл компонента системного поставщика, swprv.dll, и драйвер, который перехватывает ввод-вывод тома, volsnap.sys.¹ Если интересно, как перехватывают стек ввода-вывода, см. также «Фильтр-драйверы и минифильтры».

Есть и другие методы: полное копирование, при котором отсоединяют зеркало, и перенаправление при записи (redirect-on-write), при котором изменения пишут на отдельный том. Аппаратные поставщики используют тот метод, который лучше подходит дисковому массиву.¹

4.2. Как создаётся точка покоя: 60 секунд на заморозку, 10 секунд на создание

Если копирование при записи отвечает на вопрос как данные сохраняют, настоящая ценность VSS — в том, состояние какого момента сохраняют, то есть как создаётся точка покоя. Создание теневой копии идёт так.¹

flowchart TB
    accTitle: Ход создания теневой копии
    accDescr: Ход создания теневой копии. Остановка длится лишь секунды или десятки секунд; само резервное копирование идёт уже по снимку
    R["Запрашивающая сторона требует создания<br/>перечисляет модули записи и собирает метаданные"] --> M["Каждый модуль записи объявляет объекты<br/>резервного копирования (компоненты) в XML"]
    M --> P["Каждый модуль записи готовит данные<br/>сворачивает журналы, сбрасывает кэши и т. п.<br/>приводит данные в восстановимое согласованное состояние"]
    P --> F["Заморозка записи I/O у модулей записи<br/>(чтение возможно. Не более 60 секунд)"]
    F --> FS["VSS сбрасывает буферы файловой системы<br/>и замораживает файловую систему"]
    FS --> C["Поставщик создаёт теневую копию<br/>(за 10 секунд. Запись I/O всё это время заморожена)"]
    C --> T["Освобождение файловой системы → разморозка (thaw) модулей записи<br/>приложение возобновляет запись"]
    T --> B["Запрашивающая сторона выполняет резервное копирование<br/>с теневой копии столько, сколько потребуется"]

Рис. 1: Ход создания теневой копии. Останавливается только на секунды или десятки секунд; само резервное копирование идёт уже по снимку

Есть три пункта, на которые стоит обратить внимание.

1. Приложение останавливается только на миг, который нужен, чтобы создать точку покоя. Заморозка ограничена 60 секундами, создание (commit) поставщиком — 10 секундами; превысьте любой лимит — создание прерывается, и запрашивающая сторона пробует снова.¹ Само резервное копирование, которое может идти часами, выполняется по готовой теневой копии только для чтения, пока приложение продолжает работать.
2. Во время заморозки чтение всё ещё возможно. Останавливается только запись ввода-вывода.¹
3. Файловая система тоже замораживается. Поскольку VSS сбрасывает буферы файловой системы перед заморозкой, записи, которые сидели в кэше, и метаданные файловой системы попадают в снимок в согласованном порядке.¹

4.3. Согласованность при сбое и согласованность на уровне приложения

Здесь появляется важное различие, которое определяет качество резервной копии.

Теневая копия, созданная без участия модуля записи, находится в том, что терминология Microsoft называет состоянием согласованности при сбое (crash consistent). Официальное определение — «состояние диска, эквивалентное тому, которое нашли бы после катастрофического отказа, внезапно выключившего систему», а восстановление из него описано как «эквивалент перезапуска после внезапного выключения».³ Как файловая система она не повреждена, но с точки зрения приложения это «миг, когда питание выдернули посреди записи». База данных с механизмом восстановления по журналу транзакций часто может из этого выйти, но сначала должно отработать восстановление — это предпосылка, а не бонус.

При участии модуля записи каждый модуль записи непосредственно перед точкой покоя сворачивает журнал транзакций и сбрасывает кэши, приводя данные в согласованное состояние, из которого само приложение гарантирует корректное восстановление.¹ Это согласованность на уровне приложения, и именно ради неё существует механизм модуля записи. Стоит заметить: модуль записи гарантирует «согласованное, восстановимое состояние с точки зрения приложения» — он не молча фиксирует и не завершает за вас незакрытые транзакции. Незафиксированная работа при восстановлении откатывается ровно так же, как при обычном восстановлении базы данных. Модуль записи даёт эту гарантию качества, не останавливая приложение, ценой заморозки на десятки секунд.

Именно поэтому в настройках программы резервного копирования есть пункты вроде «использовать VSS» или «гарантировать согласованность приложения». Для обычного набора файлов на файловом сервере согласованность при сбое редко бывает проблемой. Но на сервере с базой данных или почтовым хранилищем то, здоров ли соответствующий модуль записи, само по себе и есть качество резервной копии.

5. Эксплуатация: vssadmin и «Предыдущие версии»

Инструмент, которым системные администраторы на практике проверяют состояние VSS, — vssadmin (запускайте из командной строки с правами администратора). В актуальном справочнике команд list shadows / list writers / delete shadows / resize shadowstorage указаны как доступные и на клиенте, и на сервере.⁴ В справочнике, ориентированном на Windows Server, дополнительно перечислены create shadow / list shadowstorage / list providers и другие.⁵ Заметьте, что vssadmin умеет управлять только теневыми копиями, созданными системным поставщиком.¹

Если list writers показывает модуль записи в состоянии ошибки, подозревать нужно не сам VSS, а приложение, которое этот модуль записи предоставляет. Проверьте состояние службы владеющего приложения и журналы событий Application/System (раздел 7).

У resize shadowstorage параметр /maxsize позволяет задать предел с единицей вроде KB/MB/GB; не зададите — предела нет вовсе. Стоит заметить, что документация Microsoft прямо говорит: изменение предела хранилища — особенно его уменьшение — само по себе может привести к потере теневых копий.¹⁰ Не уменьшайте предел на томе, где хотите хранить несколько поколений, между делом.

5.1. Связь с «Предыдущими версиями»

Если на файловом сервере включить теневые копии общих папок (Shadow Copies of Shared Folders), периодически сохраняются копии файлов общей папки на определённый момент, и пользователи могут восстановить удалённый или перезаписанный файл из «Предыдущих версий» без помощи администратора.¹ Это самое знакомое применение VSS, и оно заметно снижает нагрузку на службу поддержки.

Есть, однако, предел. Теневых копий системного поставщика — максимум 512 на том, из них функция теневых копий общих папок по умолчанию хранит до 64 (меняется значением реестра MaxShadowCopies).¹ И как сказано начиная со следующего раздела, если области различий не хватает, самые старые поколения снимают автоматически. Безопаснее понимать, что «сколько поколений вы реально храните» решает не настроенное число, а объём записи и размер области различий.

6. Взгляд разработчика: нужен ли VSS собственному приложению

Дальше — взгляд разработчика. Когда просят «добавить функцию резервного копирования, которая умеет копировать файлы, даже пока они используются», как подходить к VSS?

6.1. Свою запрашивающую сторону писать дорого

API VSS и для запрашивающей стороны, и для модуля записи предоставляется как интерфейсы COM и C++ (ядро запрашивающей стороны — IVssBackupComponents).⁶ Официальной обёртки для .NET нет, и нужно корректно реализовать всё: от сбора метаданных модулей записи через управление набором снимков до очистки после ошибки. Поэтому это не то, что между делом прикручивают как одну функцию бизнес-приложения. В наших оценках заказной разработки (Custom Software Development) «построение запрашивающей стороны VSS» идёт отдельной строкой.

Есть два реалистичных ответа. Первый: оставить это существующему продукту резервного копирования с поддержкой VSS. Второй: на Windows Server запускать DiskShadow из скрипта. DiskShadow — запрашивающая сторона VSS, которая поставляется с ОС; кроме интерактивного режима у неё есть режим скрипта (diskshadow /s script.txt), и одним скриптом можно покрыть создание теневой копии, выставление её как буквы диска (expose), запуск пакетного процесса, который копирует (exec), и очистку после.⁷¹ Поток «создать теневую копию → вытащить из неё файлы своей логикой копирования → удалить» можно собрать, не написав ни одной строки COM. Однако DiskShadow есть только в Windows Server и не входит в клиентские редакции ОС.¹ Если в область требования входят и клиентские ПК, одного этого факта достаточно, чтобы склониться к готовому продукту резервного копирования.

6.2. Нужен ли VSS вообще: таблица решений

По нашему опыту, огромное большинство запросов «скопировать файл, который используется» решается без VSS. Сначала точно выясните, какого уровня требование, и только потом выбирайте инструмент.

6.3. Регистрировать ли модуль записи в своём приложении

Стоит прояснить и обратный вопрос: должно ли своё бизнес-приложение предоставлять модуль записи VSS? Если написать его, данные вашего приложения будут копироваться с согласованностью на уровне приложения, каким бы продуктом резервного копирования ни пользовался заказчик. Есть и более лёгкий механизм, чем обычный модуль записи, — экспресс-модуль записи (express writer) (IVssExpressWriter), но всё, что он делает, — регистрирует метаданные, объявляющие, какие файлы включать или исключать.⁶ Уведомления заморозки и разморозки он не получает, поэтому не может приостановить запись вашего приложения в такт созданию снимка. Экспресс-модуль записи уместен только в паре с таким устройством хранения, которое не ломается, даже если его снимают посреди записи (то есть согласованности при сбое достаточно). Если на точке покоя реально нужна координация, нужна полная реализация модуля записи.

При этом правило для решения простое.

• Если данные живут в базе вроде SQL Server, модуль записи не нужен. Согласованность гарантирует собственный модуль записи базы.¹
• Для простого файлового хранения сначала решите это устройством процедуры сохранения. Если записать полностью во временный файл и затем подменить атомарным переименованием, снимок с согласованностью при сбое никогда не оставит после себя повреждённый сохранённый файл.
• Регистрировать модуль записи стоит рассматривать только для приложений, которые держат собственное хранилище данных на несколько файлов и нуждаются во взаимной согласованности между ними на точке покоя. Возможно, сначала стоит пересмотреть, правильно ли вообще держать такой объём данных в самодельном формате.

7. Ловушки: четыре вещи, которые бьют в эксплуатации

7.1. VSS — это ещё не резервная копия

Это самая важная ловушка. Теневая копия системного поставщика — разность, лежащая на диске той же самой машины, что и исходные данные. Если область различий потеряна, собирать уже не из чего, поэтому это не даёт никакой защиты от отказа диска, кражи или утери машины, или шифрования всего тома. Документация Microsoft сама проводит чёткую черту между теневыми копиями и резервными: «содержимое, скопированное с теневой копии на носитель вроде ленты, и есть резервная копия, а саму теневую копию после этого копирования можно удалить».¹ Теневая копия — точка покоя и быстрый способ восстановиться после ошибки, а не замена резервной копии на отдельном носителе в отдельном месте.

7.2. Ошибка модуля записи — проблема приложения

Когда программа резервного копирования падает с «ошибкой VSS», начните с того, какой модуль записи отказал, командой vssadmin list writers. Поскольку модуль записи по существу — компонент, принадлежащий приложению (или компоненту Windows)¹, главное поле расследования причины — состояние службы этого приложения и его журналы событий. Увлечься внешней картиной «ошибка программы резервного копирования» и продолжать копать только само это ПО — окольный путь. Общий шаблон сужения круга тот же, что в «Если вам досталась система без исходного кода и без документации — практический план, как сопровождать её, не останавливая работу»: сужайте список подозреваемых по фактам, которые реально наблюдаете.

7.3. Программы-вымогатели удаляют теневые копии

Это факт, который стоит знать при защите. Хочется надеяться, что если можно откатиться через «Предыдущие версии», то можно восстановиться даже после удара программы-вымогателя. Но широко известно, что очень многие такие программы удаляют теневые копии до или после шифрования именно для того, чтобы перекрыть этот путь восстановления. Удалить теневые копии можно совершенно штатной командой, лишь бы были права администратора, поэтому это не может служить последней линией обороны против злоумышленника, который уже внутри. Поэтому защита строится так: (1) относиться к теневым копиям как к «удобно, если есть», а не как к «части плана восстановления»; (2) держать отдельную офлайн-копию в другом месте, до которой злоумышленник не дотянется; и (3) никогда не давать права администратора учётным записям повседневной работы. Про защиту на всём жизненном цикле ПК, включая резервное копирование, шифрование и утилизацию, см. также «Практическое руководство по BitLocker — шифрование диска, начиная с управления ключом восстановления» и «Что сделать перед утилизацией Windows PC — практический чек-лист по стиранию данных, отвязке учётных записей и резервному копированию».

7.4. Когда область различий кончается, старые поколения исчезают без предупреждения

Как разобрано в разделе 4, копирование при записи расходует область различий только когда каждый блок перезаписывают впервые после снятия снимка. Сколько угодно дальнейших перезаписей уже сохранённого блока к расходу не добавляют, поэтому сколько израсходовано, решает не «сколько было записей», а «насколько широкий диапазон блоков перезаписали с момента сохранённого снимка». И как только область различий упирается в предел, теневые копии этого тома удаляются, начиная с самых старых.¹ Интерактивному пользователю ничего не сообщают, поэтому часто это всплывает, только когда «я должен мочь откатиться к версии прошлой недели» оказывается уже неправдой. Совсем беззвучно, впрочем, не бывает: в журнале System пишутся события источника volsnap (идентификатор 25, когда копию удалили, потому что не удалось освободить место под область различий, 35/36, когда расширение не удалось или его прервали, упершись в предел, и так далее). Помимо периодических проверок, включение этих событий volsnap в мониторинг и оповещения позволяет быстро поймать потерю. Причина, по которой массовые операции, которые затрагивают большой диапазон блоков тома — массовые обновления файлов, пакетные преобразования, дефрагментация — могут исчерпать область различий за один заход, как раз в этом свойстве: расход решает диапазон перезаписанных блоков. Регулярно сверяйте, удовлетворяет ли число хранимых поколений бизнес-требованию («не больше скольких дней может пройти, прежде чем кто-то заметит случайное удаление?») с использованием, которое показывает vssadmin list shadowstorage, и расширяйте предел, если нужно.⁵¹⁰

8. Итог

• Причину, по которой занятый файл обычно нельзя скопировать, составляют нарушение совместного доступа и согласованность, и это правильный механизм защиты данных. VSS — ответ уровня ОС на «хочу согласованную копию, не останавливая приложение».
• VSS — каркас, в котором служба VSS посредничает между тремя ролями — запрашивающая сторона (просит), модуль записи (гарантирует согласованность) и поставщик (создаёт) — позволяя программам резервного копирования и бизнес-приложениям, которые ничего друг о друге не знают, согласовать работу.
• Системный поставщик использует копирование при записи, и точка покоя создаётся так: заморозка модулей записи (до 60 секунд) → создание (за 10 секунд) → разморозка. Без участия модуля записи получается согласованность при сбое; с ним — согласованность на уровне приложения.
• Эксплуатационное состояние проверяйте через vssadmin (list shadows / list writers / list shadowstorage). При ошибке модуля записи подозревайте сторону приложения и регулярно смотрите использование области различий.
• Разработчикам сначала по таблице решений проверить, нельзя ли решить задачу повторами, режимом общего доступа, окном остановки или устройством интеграции, и обращаться к VSS только когда он действительно нужен. Скрипт DiskShadow (только Server) или существующий продукт — реалистичный ответ, раньше собственной реализации.
• Теневая копия — не резервная копия. Это не больше чем разность, зависящая от нетронутых блоков исходного тома; она бессильна против потери этого исходного тома, как при отказе диска, и на неё нельзя положиться против программ-вымогателей, учитывая, что теневые копии можно удалить или область различий исчерпать. Сочетайте её с офлайн-копией, хранимой в другом месте.

Похожие статьи

• Основы взаимного исключения при файловой интеграции — лучшие практики файловых блокировок и атомарного claim
• Глубины ввода-вывода Windows (часть 4) — диспетчер кэша: когда ваш WriteFile на самом деле доходит до диска?
• Глубины ввода-вывода Windows (часть 5) — внутренняя структура NTFS: файловая система через MFT
• Если вам досталась система без исходного кода и без документации — практический план, как сопровождать её, не останавливая работу
• Практическое руководство по BitLocker — шифрование диска, начиная с управления ключом восстановления
• Что сделать перед утилизацией Windows PC — практический чек-лист по стиранию данных, отвязке учётных записей и резервному копированию

Смежные области консультирования

KomuraSoft LLC занимается проектированием и разработкой бизнес-приложений с функциями вроде «копирование файлов, которые ещё используются» и резервного копирования, расследованием первопричин нарушений совместного доступа вокруг файловой интеграции и отказов резервного копирования (ошибки модуля записи VSS), а также наведением порядка в схеме резервного копирования файловых серверов и управлении поколениями. Можно начать с вопроса, является ли VSS правильным требованием вообще.

• Разработка приложений для Windows
• Расследование ошибок и причин
• Технические консультации и ревью дизайна
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Если есть теневые копии, резервное копирование уже не нужно?

Нет, не отменяет. Теневые копии, которые создаёт штатный системный поставщик Windows, — это разностные данные по схеме копирования при записи: отдельной «полной копии тома на тот момент» нет, они зависят от ещё не перезаписанных блоков исходного тома. Даже если область различий (diff area) лежит на другом томе, потеря исходного тома по-прежнему делает восстановление невозможным. При отказе диска, краже или утере ПК, когда исходный том пропадает целиком, теневая копия бессильна. То же с программами-вымогателями: сама запись шифрования копирует блоки «до перезаписи» в область различий, но в реальных атаках теневые копии удаляют или область различий исчерпывают массовой перезаписью, так что на это рассчитывать нельзя. Документация Microsoft разделяет одно и другое: резервная копия — это данные, скопированные с теневой копии на носитель вроде ленты, и после этого копирования саму теневую копию можно удалить. Теневая копия — это точка покоя, с которой снимают резервную копию, и быстрый способ откатиться после мелкой ошибки, а не замена резервной копии на другом носителе и в другом месте.

Хочу, чтобы своё бизнес-приложение копировало занятые файлы. Стоит ли использовать VSS?

Реалистичный первый шаг — обойтись без этого. Запрашивающую сторону VSS нужно писать против нативного COM API (IVssBackupComponents и родственные интерфейсы). Официальной обёртки для .NET нет, поэтому встроить это в своё приложение — отдельная большая работа. Если требование сводится к «когда-нибудь прочитать файл, в который пишет другой процесс», достаточно повторов. Если другое приложение разрешает совместное чтение — откройте файл с тем же режимом общего доступа. Если приложение можно ненадолго остановить, копирование в паузу в работе — самый простой и надёжный вариант. VSS оправдан только когда нужно «снять согласованную копию всего набора данных приложения, которое нельзя останавливать». И даже тогда сначала смотрите готовый продукт резервного копирования с поддержкой VSS или скрипт DiskShadow, а не свою реализацию.

vssadmin list writers показывает модуль записи в состоянии ошибки. Что делать?

Базовый подход — разбирать это как проблему приложения, которому принадлежит этот модуль записи. vssadmin list writers показывает зарегистрированные модули записи вместе с их состоянием, поэтому сначала определите, какой именно модуль записи отказал. Модули записи предоставляют приложения вроде SQL Server или компоненты Windows (например, реестр), поэтому причина почти всегда лежит не в самом VSS, а в состоянии службы владеющего приложения или в ошибках журналов Application и System. Перезапустите соответствующую службу и сузьте условия воспроизведения; если это не помогает, сверьтесь со сведениями поддержки этого приложения. Тот же первый шаг уместен, когда программа резервного копирования падает с ошибкой VSS.

Теневая копия исчезла, а я этого не заметил. Почему?

Самая частая причина — нехватка места в области различий (хранилище теневых копий). При копировании при записи содержимое каждого блока копируется в область различий при первой перезаписи после снимка, поэтому чем шире диапазон перезаписанных блоков, тем больше расходуется область различий. Как только назначенный предел достигнут, Windows удаляет самые старые теневые копии, чтобы освободить место. Интерактивному пользователю ничего не сообщают: копии просто исчезают. Обычно это всплывает, когда кто-то рассчитывает вернуть версию прошлой недели через «Предыдущие версии», а её уже нет (в журнале System всё же пишутся события источника volsnap, например идентификатор 25; если их держать на мониторинге, исчезновение можно заметить). Проверьте использование и предел командой vssadmin list shadowstorage и при необходимости поднимите предел через vssadmin resize shadowstorage. Имейте в виду, что само изменение предела — особенно его уменьшение — тоже может привести к потере теневых копий.

Как «Предыдущие версии» в Проводнике связаны с VSS?

«Предыдущие версии» — один из входов, через который достают прошлую версию файла из теневой копии, созданной VSS. На файловом сервере включение «теневых копий общих папок» (Shadow Copies of Shared Folders) приводит к тому, что теневые копии снимаются по расписанию, и пользователи могут щёлкнуть файл в общей папке правой кнопкой и самостоятельно восстановить его из «Предыдущих версий». Польза в том, что случайное удаление или перезапись можно откатить без помощи администратора. Но поскольку за этим стоят теневые копии, есть верхняя граница числа хранимых поколений, и если области различий не хватает, самые старые поколения исчезают первыми. Как сказано в тексте статьи, наличие «Предыдущих версий» не значит, что резервные копии не нужны.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.