Теневое копирование тома (VSS): устройство и практика — почему резервное копирование может скопировать файл, который ещё используется

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

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

Эта статья рассчитана на разработчиков бизнес-приложений, которым поручают функцию «скопировать файл, который ещё используется», и на IT-специалистов, которые ведут резервное копирование файловых серверов и рабочих ПК. По первичным источникам на август 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). Смысл появляется только в связке с резервными копиями на отдельном носителе.¹

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

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

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

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

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

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

3. Действующие лица VSS — запрашивающая сторона, модуль записи, поставщик

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

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

В IT-эксплуатации момент, когда эти три роли действительно нужно держать в голове, — поиск неисправностей. Отказ резервного копирования — это проблема запрашивающей стороны (сторона ПО), конкретного модуля записи (сторона приложения) или поставщика / области различий (сторона инфраструктуры) — и от этого целиком меняется, куда смотреть (разделы 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. Повседневная эксплуатация VSS — vssadmin и «Предыдущие версии»

Инструмент, которым IT-специалисты на практике проверяют состояние 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 нет, и нужно корректно реализовать всё: от сбора метаданных модулей записи через управление набором снимков до зачистки после ошибки — поэтому это не то, что между делом прикручивают как одну функцию бизнес-приложения. В наших оценках заказной разработки «построение запрашивающей стороны 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 нужно писать против нативного API на COM (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, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.