Как включить vss на windows 7 - Windowsa.top - ваш верный помощник с OS Windows

Распознавание голоса и речи на C#

UnmanagedCoder 05.05.2025

Интеграция голосового управления в приложения на C# стала намного доступнее благодаря развитию специализированных библиотек и API. При этом многие разработчики до сих пор считают голосовое управление. . .

Реализация своих итераторов в C++

NullReferenced 05.05.2025

Итераторы в C++ — это абстракция, которая связывает весь экосистему Стандартной Библиотеки Шаблонов (STL) в единое целое, позволяя алгоритмам работать с разнородными структурами данных без знания их. . .

Разработка собственного фреймворка для тестирования в C#

UnmanagedCoder 04.05.2025

C# довольно богат готовыми решениями – NUnit, xUnit, MSTest уже давно стали своеобразными динозаврами индустрии. Однако, как и любой динозавр, они не всегда могут протиснуться в узкие коридоры. . .

Распределенная трассировка в Java с помощью OpenTelemetry

Javaican 04.05.2025

Микросервисная архитектура стала краеугольным камнем современной разработки, но вместе с ней пришла и головная боль, знакомая многим — отслеживание прохождения запросов через лабиринт взаимосвязанных. . .

Шаблоны обнаружения сервисов в Kubernetes

Mr. Docker 04.05.2025

Современные Kubernetes-инфраструктуры сталкиваются с серьёзными вызовами. Развертывание в нескольких регионах и облаках одновременно, необходимость обеспечения низкой задержки для глобально. . .

Создаем SPA на C# и Blazor

stackOverflow 04.05.2025

Мир веб-разработки за последние десять лет претерпел коллосальные изменения. Переход от традиционных многостраничных сайтов к одностраничным приложениям (Single Page Applications, SPA) — это. . .

Реализация шаблонов проектирования GoF на C++

NullReferenced 04.05.2025

«Банда четырёх» (Gang of Four или GoF) — Эрих Гамма, Ричард Хелм, Ральф Джонсон и Джон Влиссидес — в 1994 году сформировали канон шаблонов, который выдержал проверку временем. И хотя C++ претерпел. . .

C# и сети: Сокеты, gRPC и SignalR

UnmanagedCoder 04.05.2025

Сетевые технологии не стоят на месте, а вместе с ними эволюционируют и инструменты разработки. В . NET появилось множество решений — от низкоуровневых сокетов, позволяющих управлять каждым байтом. . .

Создание микросервисов с Domain-Driven Design

ArchitectMsa 04.05.2025

Архитектура микросервисов за последние годы превратилась в мощный архитектурный подход, который позволяет разрабатывать гибкие, масштабируемые и устойчивые системы. А если добавить сюда ещё и. . .

Многопоточность в C++: Современные техники C++26

bytestream 04.05.2025

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

Источник

Снятие снапшота — именно с этого начинается любой бекап. До тех пор, пока мы не знаем, как сбросить все буфера на диск и привести файлы с данными в консистентное состояние, мы не бекапы делаем, а занимаемся копированием файлов с непредсказуемым содержимым внутри. Понимая важность снапшотов, все вендоры стараются дать нам если не полностью готовую функцию (типа Time Mashine в MacOS), то хотя бы набор ручек, за которые можно подёргать (вроде модуля dm-snap в ядре Linux).

Но сегодня речь пойдёт про самую распространённую ОС — Microsoft Windows, где эта задача решается с помощью Volume Shadow Copy сервиса, известного в народе под аббревиатурой VSS (Volume Snapshot Service). А нашего внимания он удостоился из-за того, что, несмотря на всю популярность своего материнского корабля, сам он окутан вуалью из тайн и мистических слухов. Давайте уже как-то разберёмся с этой штукой.

А, собственно, что с ним за проблема? Вот есть документация, где вполне адекватно и красиво описано, как всё работает. Есть утилита vssadmin, позволяющая вполне годно создавать и удалять снапшоты. Что не так-то, и где сложности?

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

Хотя упомянутый выше vssadmin как-то вроде и работает, и снапшоты даже делает, и вообще молодец. Но это всё до того момента, пока ты не начинаешь вникать в тонкости, где может выясниться, что репорт об успешно созданном снапшоте — это репорт о чём угодно, только не об успешно созданном снапшоте.

Вот поэтому и захотелось немного поговорить о том, как же на самом деле работает VSS. И да, строго говоря, результатом работы VSS является созданная shadow copy. Но дабы не ломать язык и не мучить вас транслитом, давайте просто писать снапшот.

Какова роль VSS

Не сомневаюсь, что 90% читающих прекрасно понимают, зачем нужны снапшоты, но ради оставшихся 10% потерпите несколько предложений. Или сразу идите в следующий раздел.

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

Сами снапшоты ничего не знают про ваши файлы и папки. Они работают на уровень ниже файловой системы — с блочными устройствами и блоками данных. Если придерживаться терминологи Microsoft, то снапшот — это место, именуемое Shadow Storage, куда записываются изменённые блоки данных и откуда их можно извлекать с целью переписать данные на оригинальном диске. Тут можно запомнить для себя два нюанса. Первый — только что сделанный спапшот занимает ровно ноль байт. Это просто пре-алоцированное место, куда файловая система может копировать измененные блоки (или наоборот, новые блоки, но не суть). И второй — теневая копия суть есть дифференциальный бекап. Все данные, которые вы изменили, не удаляются, а отправляются на хранение в этой зоне.

Где найти VSS

Обнаружить следы VSS можно двумя классическими способами: через GUI или в консоли. В зависимости от конкретной версии системы пути могут немного отличаться, но суть будет одинакова. Итак, есть у меня в лабе Windows Server 2019, и если сделать ПКМ на любом диске в проводнике, мы увидим два пункта: Configure Shadow Copies и Restore previous versions.

Если зайти в мастер настроек, то можно включить создание теневых копий для любого диска, задать расписание, по которому они будут создаваться и, что самое интересное, указать место хранения этих копий. Строго говоря, даже не самих копий, а так называемой diff area — места, куда сбрасываются перезаписанные на оригинальном томе сектора. То есть мы запускаем создание снапшота одного диска, а его данные физически храним на другом. Функция архиполезная и позволяет не просто снижать нагрузку на конкретном диске, но и делать фокусы а-ля снимаем снапшот одной ноды в кластере и цепляем его к другой.

После того, как вы всё настроите на свой вкус, появляется смысл в пункте Restore previous versions. Чисто технически туда и до этого можно было зайти, однако внутри, скорее всего, будет только гнетущая пустота.

Но всё это баловство с графическим интерфейсом, и как мы знаем, до добра это не доводит, поэтому открываем powershell (или даже cmd, почему нет) — и там у нас имеется два варианта из коробки: vssadmin и diskshadow. Первая утилита есть практически на любой системе, начиная с WinXP/Win2003. Нет её только на Windows 8. По какой-то таинственной причине из “восьмёрки” вырезали инструменты управления теневыми копиями, но потом осознали свою неправоту и вернули всё на место. А вот diskshadow доступен только на серверных вариантах Windows. Это уже более продвинутый вариант vssadmin, позволяющий работать не только в интерактивном режиме, но и выполнять целые скрипты, написанные на понятном этому интерпретатору языке. Да и просто это более адекватный и поддающийся контролю инструмент.

И запоминаем самое важное: это две разные утилиты, существующие в разных контекстах. Теневая копия, сделанная в одной утилите, будет видна другой, однако статус у неё будет неоперабельный.

Вот отличный пример: мы создали снимок в diskshadow и пытаемся удалить его с помощью vssadmin. Сам снимок мы видим, но он не в нашем контексте, поэтому сорян, у нас нет здесь власти.

Технически ничего не мешает одновременно делать снимки с помощью vssadmin и diskshadow. Хотя есть вероятность, что получите сообщение типа Another shadow copy is in progress. Но это так, к слову пришлось. Не надо пытаться одновременно делать несколько снапшотов разными программами.

Как появился VSS

Итак, судя по написанному выше, всё просто: нам надо просто брать появляющиеся блоки и сохранять их куда-то в сторонку, чтобы при необходимости вынимать обратно. Сразу возникает первый вопрос: а что именно надо сохранять в нашем теневом хранилище? Ведь действительно, можно просто писать в него все приходящие новые блоки и сохранять в метаданные, на какое место они (блоки) должны были быть записаны. А можно поступить чуть сложнее и записывать новые блоки сразу на полагающееся им место, а в хранилище отправлять содержимое перезаписываемых блоков. Что лучше и как выбрать? На самом деле право на жизнь имеют оба варианта, и какой выбрать — зависит исключительно от воли вендора. Первый подход (redirect-on-write, RoW, если оперировать грамотными терминами) быстро пишется, но долго читается. Зато если надо откатиться на первоначальное состояние, это делается моментально — мы просто удаляем наше теневое хранилище. Второй подход (copy-on-write, CoW) пишется медленней, читается быстрее и моментально удаляет копии предыдущих состояний. VSS, к слову, придерживается парадигмы CoW, а в снапшотах VMware реализован RoW.

Но на самом деле этот вопрос не самый важный из тех, которые стоит себе задать перед тем, как начать перехватывать появляющиеся блоки и складывать их в сторонке. Главный вопрос — в какой именно момент надо осуществлять перехват?

Давайте рассмотрим хрестоматийную ситуацию с файлом базы данных. (И если у вас уже заскрипел песок на зубах, смело пропускайте следующие два абзаца.) Итак: у нас есть банальная SQL Server база данных в виде mdf файла, и тут к нам прилетает какой-то запрос. SQL, как порядочное приложение, начинает старательно вносить изменения в файл, а мы старательно перехватываем каждый новый блок данных падающих на диск и пишем в нашу теневую копию. Всё хорошо и здорово, но тут выключили свет. Потом свет включили, сервер запустили и мы даже базу восстановили из нашей теневой копии, но тут оказывается, что SQL не запускается. Говорит — база в не консистентном состоянии. Это значит следующее: во время нормальной работы завершение каждой транзакции помечается специальным флагом. Сервер его видит и знает, что всё хорошо. А тут сервер загружается, видит, что из его базы торчит какой-то кусок данных, флага нет и, следовательно, что с этим всем делать — он понятия не имеет. То ли удалить, то ли дописать, то ли ещё что-то. Но у нас тут не угадайка, а всё должно быть однозначно и консистентно. Поэтому он принимает решение выключиться, дабы не поломать базу ещё сильнее.

Хорошо, но как избежать подобных приключений? Отличным вариантом будет подождать, пока SQL сервер допишет свою транзакцию, пометит её как завершённую, и потом мы быстренько заберём все появившиеся новые блоки. Отличный вариант, который надо срочно реализовывать! Вот только есть небольшая проблема: до этого мы говорили про одно приложение и один файл, с которым оно работает. Научиться общаться с условным SQL Server много ума не надо, но что делать с остальными миллиардами существующих приложений? А что делать, в конце концов, с самой ОС, у которой внутри огромное количество своих процессов и открытых файлов? Вот примерно с такими проблемами и столкнулись учёные мужи из Microsoft, когда пришли к выводу, что надо реализовать некий общий интерфейс, через который можно будет сразу всем прокричать нечто вроде: “Сейчас мы будем делать снапшот, так что быстренько сворачиваемся и сбрасываем буфера на диск! Приостанавливайте свою кипучую деятельность и приводите данные в консистентный вид!”. Ну а назвать эту штуку они решили, как вы уже догадались, Volume Snapshot Service. Или просто VSS.

И тут можно воскликнуть — но ведь в Windows 2008 был представлен Kernel Transaction Manager! Это разве не то же самое? Он же как раз занимается тем, что приводит файлы на диске в консистентное состояние. А вот и нет! То есть да, KTM приводит, но отвечает только за дисковые операции, а что там происходит с приложениями — его мало волнует. А ведь многим из этих приложений важна не просто целостность файлов, но и что в них записано. Классический пример — это Exchange и Active Directory. И тут мы подошли к важной теме:

Как устроен VSS

Чтобы не прыгать с места в карьер громады страшных терминов и процессов, начнём с высокоуровневого описания. Поэтому ограничимся таким списком компонентов:

VSS Writer. В кириллическом простонародье известен как просто райтер, поэтому так и будем его называть в дальнейшем, вызывая праведный гнев ненавистников англицизмов.

Райтер занимается тем, что выстраивает мостик взаимодействия между VSS подсистемой и конкретным приложением. Поэтому а) в любой системе их будет достаточно много (проверьте у себя с помощью vssadmin list writers) б) райтер всегда пишется поставщиком приложения, ибо кроме него никто не знает, что там и как должно происходить во время создания снапшота.

Соответственно, райтер по своей сути выполняет роль “регулировщика”: сначала он говорит приложению подготовиться к снапшоту, затем даёт отмашку VSS сервису делать снапшот. Или не даёт, если приложение не смогло за установленный промежуток времени подготовить свои файлы.

Также хочется отметить, что райтеры — это какие-то невероятно нежные ребята, которые зачастую ломаются без каких-либо внешних признаков. Поэтому если в выводе vssadmin list writers в поле State вы увидите что-то, отличающееся от Stable, это надо чинить, ибо сделать консистентный бекап, увы, не получится.
VSS Provider. Тот самый парень, который занимается созданием и управлением снапшотами. Известен тем, что бывает софтовый или хардовый. Список установленных в системе провайдеров можно посмотреть с помощью команды vssadmin list providers. По дефолту, с системой идет Microsoft Software Shadow Copy provider. Он даже отлично и замечательно работает, но до тех пор, пока вы не подключите к системе брендовую СХД. Хорошие вендоры всегда снабжают свои железки управляющим софтом, в составе которого находится и родной провайдер к этой железяке. Благодаря этому можно уже делать всякие хитрые трюки, которые реализованы в вашем оборудовании, и именно поэтому мы в Veeam так гордимся списком интеграций с железом.
VSS Requestor. Участник процесса, который инициирует создание VSS снапшота или восстановление данных. Можно сказать, что реквестор — это бекапное приложение, которое общается с райтерами и провайдерами. Может показаться, что его роль незначительна, однако от грамотности реализации реквестора зависит качество получаемого результата. То есть VSS не будет за вас думать, что и в каком виде надо сделать. Чем более чёткие инструкции выдаст реквестор, тем более предсказуемым будет результат.

Как в итоге всё выглядит на самом высоком уровне: реквестор стучится в Volume Shadow Copy сервис, тот отдаёт команду райтерам предупредить приложения о надвигающемся снапшоте, райтеры рапортуют об успехе, а сервис отдаёт команду провайдерам делать снапшоты. О результатах докладывается реквестору.

Но на деле, очевидно, всё несколько сложнее. На первом шаге реквестор проверяет, что вообще есть в наличии и с кем предстоит общаться. Затем после составления списка райтеров он обращается к провайдеру, объясняя, что он хочет заснапшотить и где должен располагаться снапшот. Это называется SnapshotSet. В большинстве случаев он будет располагаться на том же вольюме, что и оригинальный диск. А меньшинство случаев — это те самые хардварные провайдеры, которые поставляются вместе с СХД. Для них нормой считается создавать отдельный вольюм для снапшота, который называется storage snapshot. А в определённых случаях можно так и вообще перемещать снапшот на другое физическое устройство, чтобы выкачивать данные уже оттуда, а не с прода. Без хардварных провайдеров сделать такое не выйдет.

Следом начинается стадия, именуемая Prepare for backup. На этом этапе мы должны уже не просто изучить метаданные райтеров, а запросить их реальные статусы и приготовиться к самой жаркой поре: все райтеры должы будут отработать один за другим. Причём каждый должен уложиться в отведённое ему время, которое по умолчанию равно 60 секундам. Так решили в Microsoft, забыв уточнить причины. Но есть ещё приложения-чемпионы, например, Exchange. Его авторы посчитали, что 20 секунд более чем достаточно, и остановились на таком лимите. А чем чревато невыполнение этого этапа, который в документации называется OnFreeze? Тем, что райтер вернёт сообщение об ошибке, и снапшот не будет сделан. После чего в интерфейсе Veeam появится одна из каноничных ошибок вроде “VSSControl: Failed to freeze guest, wait timeout». Тут радует одно: в логах VSS всегда будет написано, какой именно райтер завалил задание. А по самим ошибкам уже столько KB написано, что вспоминать страшно. Но если вы вдруг сомневаетесь, то точно вам говорю — написанному в них можно смело верить. И если после всего получается, что у вас слишком медленное хранилище, и за отведённое время не получается сбросить все кэши на диск, ну, значит, так оно и есть. Физику не обманешь, а вот железо надо хоть иногда обновлять.

Но это был пессимистичный вариант (прошу понять меня правильно, но беды с VSS — это очень частная причина обращений в сапорт), а в оптимистичном можно начинать самый важный этап. Как только райтеры рапортуют, что всё, вся деятельность в системе заморожена, а кеши сброшены на диск, у нас есть десять(!!!) секунд на создание снапшота, после чего райтеры будут принудительно разморожены, и всё закрутится вновь. И можно сказать, что на этом процесс бекапа заканчивается, и всё что нужно — это просто импортировать наш снапшот и скачать его куда-то к себе, чтобы сохранить под семью замками. Однако есть одно важное Но — log truncate. Фундаментально это вообще не связанные операции и транкейт зависит только от бекапа логов, но как все мы понимаем — на пользовательском уровне эти вещи связаны в единый процесс. То есть, прежде чем выкачивать снапшот, надо не забыть выдать команду backup log, которая запустит операцию транкейта. И после этого совесть наша чиста.

Но что дальше происходит с данными? Если мы действительно используем какое-то приложение для бекапов, которое запустило весь этот процесс, дождалось его завершения и скачало данные в своё хранилище, то снимок можно просто удалить одной командой. Поскольку VSS пропагандирует CoW подход, то речь здесь действительно о банальном удалении нашей аллоцированной зоны, ведь все новые данные сразу пишутся на оригинальный диск. Это называется non-persistent shadow copy, и она не имеет никакого смысла без оригинального диска.

Чтобы пройти этот путь вручную, достаточно открыть консоль и набрать:

PS C:\Windows\system32> diskshadow
Microsoft DiskShadow version 1.0
Copyright (C) 2013 Microsoft Corporation
On computer:  VEEAM,  17.05.2021 19:18:44

DISKSHADOW> add volume c: # добавляем в задание диск С

DISKSHADOW> create	# создаём снапшот
Alias VSS_SHADOW_1 for shadow ID {a1eef71e-247e-4580-99bc-ee62c42221d6} set as environment variable.
Alias VSS_SHADOW_SET for shadow set ID {cc9fab4d-3e7d-44a5-9a4d-0df11dd7219c} set as environment variable.

Querying all shadow copies with the shadow copy set ID {cc9fab4d-3e7d-44a5-9a4d-0df11dd7219c}

        * Shadow copy ID = {a1eef71e-247e-4580-99bc-ee62c42221d6}               %VSS_SHADOW_1%
                - Shadow copy set: {cc9fab4d-3e7d-44a5-9a4d-0df11dd7219c}       %VSS_SHADOW_SET%
                - Original count of shadow copies = 1
                - Original volume name: \\?\Volume{7fd0c79d-0000-0000-0000-602200000000}\ [C:\]
                - Creation time: 17.05.2021 19:19:45
                - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2
                - Originating machine: veeam.university.veeam.local
                - Service machine: veeam.university.veeam.local
                - Not exposed
                - Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}
                - Attributes:  Auto_Release Differential

Number of shadow copies listed: 1

Здесь мы видим, что успешно создался снапшот со своим Shadow copy ID, и для удобства ему сразу присвоили алиас VSS_SHADOW_1. Этими данными вполне можно оперировать, если возникает такое желание. Однако не будем уходить в сторону и попробуем прочитать содержимое этого снимка. Для чего подмонтируем его в качестве диска.

DISKSHADOW> expose {a1eef71e-247e-4580-99bc-ee62c42221d6} Z:
The shadow copy is a non-persistent shadow copy. Only persistent shadow copies can be exposed.

Однако на такое, казалось бы, простое и законное желание мы получили не менее законный отлуп, ибо сделали non-persistent снимок, а, значит, единственное, на что он годится — это записать его поверх родного, удалив на нём всю информацию, которая появилась после создания этого снимка. Но такая история нас не устраивает, поэтому стираем всё безжалостно.

DISKSHADOW> delete shadows all # или только нужный ID
Deleting shadow copy {a1eef71e-247e-4580-99bc-ee62c42221d6} on volume \\?\Volume{7fd0c79d-0000-0000-0000-602200000000}\ from provider {b5946137-7b9f-4925-af80-51abd60b20d5} [Attributes: 0x00420000]...

Number of shadow copies deleted: 1

И начинаем всё заново, только теперь укажем, что нам нужна персистентная копия, чтобы мы могли использовать её как полноценный диск.

DISKSHADOW> add volume C:

DISKSHADOW> set context persistent # вот этот момент

DISKSHADOW> create
Alias VSS_SHADOW_1 for shadow ID {346d896b-8722-4c01-bf01-0f38b9abe20a} set as environment variable.
Alias VSS_SHADOW_SET for shadow set ID {785983be-e09d-4d2a-b8b7-a4f722899896} set as environment variable.

Querying all shadow copies with the shadow copy set ID {785983be-e09d-4d2a-b8b7-a4f722899896}

        * Shadow copy ID = {346d896b-8722-4c01-bf01-0f38b9abe20a}               %VSS_SHADOW_1%
                - Shadow copy set: {785983be-e09d-4d2a-b8b7-a4f722899896}       %VSS_SHADOW_SET%
                - Original count of shadow copies = 1
                - Original volume name: \\?\Volume{7fd0c79d-0000-0000-0000-602200000000}\ [C:\]
                - Creation time: 17.05.2021 19:38:45
                - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3
                - Originating machine: veeam.university.veeam.local
                - Service machine: veeam.university.veeam.local
                - Not exposed
                - Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}
                - Attributes:  No_Auto_Release Persistent Differential

Number of shadow copies listed: 1

Как мы видим: Attributes: No_Auto_Release Persistent Differential. Поэтому если теперь вы сделаете expose, то снапшот примаунтится как полноценный диск, по которому можно перемещаться и копировать с него файлы. Диск, само собой, виртуальный и состоит из блоков оригинального диска, плюс блоки изменившихся данных, читая которые, мы можем видеть состояние оригинального диска на момент снапшота. Всё просто.

Только учтите, пожалуйста, такой момент, если вдруг решите, что нашли святой грааль: в таком режиме нельзя занимать данными больше 50% места на диске. Один блок свыше — и всё, диск переполнился.

Что тут хочется ещё сказать, а вернее, спросить: если всё так просто, то почему же я говорю, что всё так сложно? Проблема в том, что, отдавая на боевом сервере команду vssadmin create shadow, мы, конечно, создаём какой-то снимок, но как себя будут чувствовать приложения после отката на этот снимок, мы предсказать не можем. Это не шутка: команда create признаёт наличие ошибок при выполнении как вариант нормы. Райтер не вернул вовремя Ок от приложения? Да кому это надо, го делать снапшот, я создал.

Поэтому когда за дело берётся настоящее бекапное приложение вроде Veeam Backup & Replication, то речь идёт не об одной команде, а о целой россыпи предварительных запросов, в результате которых формируется огромнейшая команда (это не метафора для красного словца, а реальность), в которой учитываются состояния райтеров и приложений на целевой системе, с жестким требованием соответствия всех статусов необходимым. Словом, количество мест, где что-то может пойти не так, вырастает на порядок. Ведь нам главное — не снапшот создать, закрыв глаза на сопутствующие потери, а гарантировать консистентность данных внутри него.

Как лечить VSS

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

Другая проблема — это железо. Помните про временные рамки для райтеров? Про десять секунд на снапшот? Для многих это ограничение становится проблемой из-за того, что СХД физически не успевает сделать требуемые действия за отведённое время. Как это лечится? А вот никак. Или покупаем более мощное железо, или ищем пути снижения нагрузки, чтобы операция была проведена за выделенный промежуток времени.

Если посмотрите одно из самых популярных KB1680: VSS Timeout when backing up Exchange VM, то легко обнаружите, что первые три шага для решения всех проблем с VSS — сделайте снапшот вручную и посмотрите чтобы это заняло менее 20 секунд, перезагрузитесь и попробуйте снизить нагрузку. Вот так и живём, да.

И что же делать, если VSS падает, в ивентах ничего нет, а понять, что происходит надо? Тут я могу порекомендовать три хороших статьи:

КВ от Veeam, посвящённое анализу поведения VSS с помощью diskshadow.
Другое KB от Veeam, посвящённое сбору информации с помощью vsstrace из Windows SDK. Но скажу сразу, это уже не для слабых духом.
И видео от моего коллеги, где он наглядно показывает, как работать с информацией из первых двух пунктов =) Рассказывает он действительно хорошо, но с непривычки голова у вас от объёма информации заболит, это я вам обещаю.

Также в гугле можно найти массу толковых советов по поводу приведения VSS в чувства, только рекомендую не бросаться на первый попавшийся случай, а постараться найти наиболее похожий именно на вашу проблему. По коду ошибки, например. Потому что слишком много возможных комбинаций ошибок, приложений и причин их возникновения.

А на сегодня всё. Я и так хотел кратенько, но получилось больше десяти страниц текста. Поэтому самое время закругляться. Если хочется раскрытия какой-то другой темы или углубиться в детали VSS, то обязательно пишите об этом в комментариях.

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку

Источник

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

Служба теневого копирования Volume Shadow Copy Service (VSS) обеспечивает две функции, которые помогут администратору сэкономить время и избавиться от лишних хлопот. Первая из них — моментальный снимок (краткосрочная резервная копия всех файлов тома NTFS). Благодаря моментальному снимку или теневой копии пользователи могут самостоятельно восстановить случайно удаленный файл или исправить последствия ошибочного выбора команды Save («Сохранить») вместо Save As («Сохранить как»). VSS не предназначен для замены текущей стратегии архивирования, как будет показано ниже. Вторая важная возможность VSS — архивирование файлов, открытых или блокированных таким приложением, как Microsoft SQL Server или Microsoft Exchange.

VSS создает теневые копии по расписанию или по требованию. Использовать службу VSS в Windows 2003 и для системного восстановления Vista просто. В данной статье показано, как настроить резервные копии с использованием VSS в Windows 2003 и преобразовать базовые диски в динамические, не повредив теневые копии. В процессе применения VSS администратору могут пригодиться рекомендации, приведенные во врезке «Пять советов по VSS».

Принципы работы VSS

Служба VSS создает моментальный снимок всех файлов на томе NTFS или томе-источнике. Теневые копии хранятся в области, именуемой кэшем теневых копий. Том, на котором находится кэш теневых копий, называется томом хранения теневой копии. Кэш теневых копий, как правило, невидим для пользователей, так как находится в скрытой системной папке System Volume Information.

По умолчанию кэш теневых копий создается на томе-источнике, но можно создать его на отдельном физическом диске, чтобы повысить быстродействие и отказоустойчивость. Прежде чем активизировать службу VSS, необходимо выбрать место для хранения кэша теневых копий, так как впоследствии кэш нельзя переместить, не потеряв содержащиеся в нем моментальные снимки. Кроме того, следует учитывать, что при отключении теневых копий на томе удаляются все существующие теневые копии.

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

Активизация VSS

Чтобы активизировать службу VSS, следует выбрать My Computer, затем щелкнуть правой кнопкой мыши на томе, на котором предстоит включить VSS, и выбрать пункт Properties. На странице Properties требуется щелкнуть на вкладке Shadow Copies. Если это уже сделано, необходимо решить, нужно ли сохранить кэш теневых копий на другом томе другого диска.

Затем выделите том-источник и щелкните на кнопке Settings. В диалоговом окне Settings можно выбрать другой том для хранения теневой копии, как показано на экране 1. Можно изменить размер области хранения и расписание (щелкнув на кнопке Schedule), если не подходит готовое расписание. По умолчанию моментальные снимки формируются с понедельника до пятницы в 7 часов утра и в полдень. Моментальные снимки следует создавать по необходимости, делать это каждый час не нужно.

Завершив настройку параметров, щелкните на кнопке OK. На странице Properties требуется щелкнуть на кнопке Enable, чтобы активизировать теневые копии на данном томе. Последует запрос об использовании расписания и настроек по умолчанию; необходимо принять это предложение и щелкнуть на кнопке Yes, а затем вновь на кнопке OK.

Сторонникам утилит командной строки полезно освоить настройку VSS с использованием Vssadmin и Schtasks вместо графического интерфейса. С помощью Vssadmin можно создавать, удалять и изменять размеры теневых копий, наряду с другими операциями. Schtasks применяется для создания, редактирования и удаления назначенных задач.

Требования к дисковому пространству. При активизации VSS немедленно выделяется 100 Мбайт пространства на диске, и VSS может занимать до 10% размера жесткого диска. В моментальных снимках отражаются только изменения по сравнению с предшествующим моментальным снимком, поэтому для их хранения требуется меньше места, чем может показаться на первый взгляд. Однако в кэше теневых копий может храниться только 64 копии. Если не хватит дискового пространства или будет создан 65-й моментальный снимок, то самый старый моментальный снимок удаляется, чтобы освободить место для нового. Из-за избыточности при создании моментальных снимков рекомендуется активизировать VSS только на томах, на которых хранятся пользовательские данные или есть возможность архивировать открытые файлы.

Использование теневых копий Windows 2003

Чтобы обеспечить доступ клиентских компьютеров к предыдущим версиям файлов, необходимо приложение Previous Versions Client, поставляемое вместе с Vista и Windows 2003. Previous Versions Client можно установить и на Windows XP Professional SP1 (файл twcli32.msi находится в папке %Windir%System32ClientsTwclientX86 на компакт-диске Windows 2003), и на Windows 2000 (нужно загрузить соответствующую версию из Web-узла Microsoft по адресу http://www.microsoft.com/downloads/details.aspx?amp;displaylang=en&familyid=e382358f-33c3-4de7-acd8-a33ac92d295e&displaylang=en). Чтобы установить клиентскую программу на компьютеры пользователей, следует дважды щелкнуть на файле для запуска установки либо развернуть его через групповую политику или Microsoft Systems Management Server (SMS).

Теневые копии предназначены для использования с Common Internet File System (CIFS), расширенным вариантом протокола Server Message Block, поэтому для доступа к предшествующим версиям файла или папки на сервере нужно подключаться через общую папку. Даже после регистрации на сервере необходимо использовать путь Universal Naming Convention (UNC). Например, для доступа к старым версиям файла на сервере с именем UptownDC в общей папке Sales требуется щелкнуть на кнопке Start, выбрать пункт Run и ввести команду

Uptowndcsales

Щелкните на кнопке OK, а затем правой кнопкой мыши на нужном файле и выберите пункт Properties. На вкладке Previous Versions перечислены моментальные снимки и показаны дата и время их создания (см. экран 2). Здесь представлены три варианта действий: View, Copy и Restore. В режиме View копия файла открывается только для чтения; это удобно для выбора нужной копии. В режиме Restore документ, его разрешения NTFS и параметры шифрования восстанавливаются в первоначальном месте, а текущая версия перезаписывается. Более безопасный вариант — Copy, при котором файл копируется в новое место.

Если нужно восстановить удаленный файл, то очевидно, что нельзя щелкнуть правой кнопкой мыши на файле в общей папке и выбрать его свойства. В этом случае необходимо перейти на уровень папки. Вместо UNC-пути UptowndcSales подключение выполняется к административному ресурсу диска C (на котором размещается папка Sales): UptowndcC$. Щелкните правой кнопкой мыши на папке Sales, выберите пункт Properties и щелкните на соответствующей кнопке, чтобы просмотреть, копировать или восстановить все содержимое папки. Если нужен лишь один файл, следует скопировать папку в новое место, затем щелкнуть правой кнопкой мыши на файле и работать с предыдущими версиями этого файла.

Vista и теневые копии

Vista — первая настольная операционная система со встроенными функциями теневых копий. Теневые копии Vista — часть механизма восстановления системы; они называются точками восстановления. По умолчанию точки восстановления активизируются для тома C, и теневые копии файлов создаются ежедневно, если на томе есть хотя бы 300 Мбайт свободного пространства.

Заранее планируемая задача SR создает точки восстановления и активизируется только в том случае, если компьютер бездействовал не менее 10 минут и питается от сети переменного тока. Если по какой-то причине задача SR не запущена в назначенное время, она будет выполнена при первой возможности. Можно назначить точки восстановления и для других томов. Vista отводит до 15% пространства на жестком диске для хранения точек восстановления.

Чтобы настроить точки восстановления и управлять ими, щелкните Start, а затем щелкните правой кнопкой мыши Computer и выберите пункт Properties. В меню Tasks следует перейти к пункту System protection. Для доступа к System protection необходимы административные полномочия, поэтому при запросе от механизма контроля учетных записей щелкните на кнопке Continue.

На вкладке System Protection страницы System Properties (экран 3) можно вручную создать одноразовую точку восстановления: выберите том и щелкните Create, дайте имя точке восстановления и вновь щелкните Create. Процесс может занять несколько минут, в зависимости от размера тома, но после его завершения выдается подтверждение об успешном выполнении. Если создание точек восстановления для тома автоматизировано, Vista создает новую точку восстановления для тома каждый день и при запуске системы.

Доступ к предыдущим версиям файлов и папок в Vista происходит так же, как при доступе через общую папку Windows 2003 с клиента с установленным приложением Previous Versions Client. Но пользователи Vista могут обращаться к прошлым версиям файлов и папок локально. Достаточно открыть Windows Explorer, щелкнуть правой кнопкой мыши на файле или папке, выбрать пункт Properties, а затем щелкнуть на вкладке Previous Versions (экран 4). Варианты такие же, как у прошлых версий Previous Versions Client, и функционируют они аналогичным образом.

VSS и сети хранения данных

Еще одно важное достоинство VSS в Windows Server 2003 Enterprise Edition и Datacenter Edition — возможность быстро и просто копировать и перемещать данные в сети хранения данных SAN. VSS может создать теневую копию тома размером в несколько терабайтов, которую можно экспортировать из SAN и импортировать на сервер всего за несколько минут, очень быстро перемещая большие массивы данных. Каждый производитель систем хранения данных по-разному реализует эту функцию, поэтому за подробной информацией следует обратиться к поставщику.

Настройка конфигурации VSS

Для томов с VSS рекомендуется размер кластеров не менее 16 Кбайт. Записи VSS преобразуются в файлы 16-Кбайт блоками. На томах величиной от 2 до 4 Тбайт размер кластера по умолчанию — 4 Кбайт. Но при кластерах размером менее 16 Кбайт поставщик VSS не может определить, был ли файл дефрагментирован или изменен. Поэтому VSS обрабатывает дефрагментированный файл так же, как измененный, — генерирует новую теневую копию файла. После дефрагментации диска с малыми кластерами кэш теневых копий может очень быстро расти и перезаписывать существующие теневые копии. Дополнительную информацию об этом можно найти в статье Microsoft «Shadow copies may be lost when you defragment a volume» по адресу http://support.microsoft.com/kb/312067.

Выяснить размер кластеров тома можно с помощью команды Fsutil. Например, чтобы узнать размер кластера тома C, введите команду

fsutil fsinfo ntfsinfo C:

Если размер кластера менее 16 Кбайт и его нужно увеличить, необходимо сделать резервную копию данных, переформатировать том, указав больший размер кластера, а затем восстановить данные. Следует учесть, что механизм сжатия файлов в NTFS действует лишь в отношении кластеров размером 4 Кбайт, поэтому приходится выбирать между сжатием и VSS.

Взаимодействие NTBackup и VSS

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

Утилита резервного копирования Windows 2003, NTBackup, использует VSS, чтобы обеспечить полноту и согласованность архивных копий. VSS взаимодействует с компонентом записи приложения, связанного с файлом. Компонент записи защищает данные приложения и предоставляет информацию, в частности, о местонахождении данных и методах архивации и восстановления. Приложения без компонента записи не могут взаимодействовать со службой VSS. В худшем случае администратор может попытаться восстановить важный файл и обнаружить, что его нет вообще: он никогда не архивировался, так как приложение не может взаимодействовать с VSS. В Windows 2003 существуют компоненты записи для AD и NTFS. Чтобы отыскать все доступные компоненты записи на сервере, нужно ввести команду

vssadmin list writers

При запуске NTBackup в Windows 2003 утилита требует ввести список всех компонентов записи, известных VSS. Служба VSS не только перечисляет компоненты записи, но и предоставляет все известные метаданные о них, в том числе методы архивации и восстановления, применяемые в компоненте записи. VSS использует метаданные, чтобы определить, какие приложения поддерживают теневые копии. Если NTBackup направляет в службу VSS запрос на создание теневой копии, то VSS посылает известным компонентам записи сообщение о необходимости заморозить все операции записи данных, создать теневую копию и сохранить ее в разностном файле. Разностный файл отслеживает изменения со времени создания последней теневой копии. Резервное копирование выполняется с использованием данных из разностного файла.

Мониторинг функционирования VSS

Мониторинг теневых копий с использованием системного монитора в Windows 2003 поможет предупредить потенциальные неполадки, прежде чем они повлияют на пользователей. Например, системный монитор предупреждает, что пространство на диске, использованное для теневых копий, приближается к максимально допустимой величине. По умолчанию системный монитор не содержит объектов или счетчиков, которые отслеживают характеристики теневых копий, но администратор может ввести их самостоятельно. Инструкции по созданию счетчиков даны в статье Microsoft «Add counters to System Monitor», опубликованной по адресу http://technet2.microsoft.com/windowsserver/en/library/47a7a162-294d-4307-af7e-b679e65858521033.mspx?mfr=true.

С помощью утилиты Volperf (с ключом /install) из набора ресурсов Microsoft Windows Server 2003 Resource Kit можно дополнить системный монитор объектами теневого копирования и следующими счетчиками:

% Disk Used by Diff Area File: процент пространства на диске, используемого всеми разностными файлами тома;
Allocated Space (MB): пространство памяти (Мбайт), выделенное для конкретного тома;
Maximum Space (MB): максимальное пространство (Мбайт), выделенное для тома хранения теневой копии;
Nb of Diff Area Files: число разностных файлов;
Nb of Shadow Copies: число теневых копий в кэше теневых копий;
Size of Diff Area Files: общий размер разностных файлов для выбранного тома;
Used Space (MB): величина пространства (Мбайт), использованного в томе хранения теневой копии

Преобразование базового диска в динамический и служба VSS

Иногда полезно добавить лишний аппаратный уровень отказоустойчивости, создав зеркальный набор. Зеркальные наборы можно строить только на динамических дисках, поэтому базовый диск необходимо преобразовать в динамический. В документации утверждается, что преобразование дисков из базовых в динамические не приводит к потере данных. Однако в документации ничего не говорится о том, что при неверном преобразовании могут быть удалены существующие теневые копии. Если том-источник и кэш теневых копий расположены на разных томах, то преобразование может оказаться сложной задачей. Дополнительные сведения о различиях между базовым и динамическим дисками описаны в статье «Диски для серверов Windows — базового или динамического типа», опубликованной в Windows IT Pro/RE № 1 за 2003 г.

Выбор процедуры для преобразования VSS-совместимого базового диска в динамический зависит от местонахождения кэша теневых копий на загрузочном томе.

Сценарий 1 — кэш теневых копий расположен не на загрузочном томе. Если кэш теневых копий находится не на загрузочном томе, то необходимо сначала размонтировать том-источник (том, для которого сделан моментальный снимок) с помощью утилиты командной строки Mountvol с параметром /P (/P демонтирует том). Затем следует преобразовать том, содержащий кэш теневых копий, в динамический том. С этого момента начинается отсчет времени: у администратора есть лишь 20 минут, чтобы смонтировать том-источник с использованием утилиты Mountvol или оснастки Disk Management консоли управления MMC. Если том-источник не будет смонтирован за 20 минут, то все теневые копии будут утеряны. Наконец, верните том-источник в оперативный режим и преобразуйте его в динамический том.

Сценарий 2 — кэш теневых копий размещен на загрузочном томе. Если кэш теневых копий находится на загрузочном томе, достаточно просто преобразовать том, содержащий кэш теневых копий, в динамический. Предварительно демонтировать его необязательно. Затем дважды перезагрузите сервер и преобразуйте том-источник в динамический том.

Выгодно конечному пользователю — выгодно администратору

Приятно, что компания Microsoft выпускает новые инструменты для восстановления работоспособности настольной операционной системы и для ИТ-специалистов, и для конечных пользователей. Чем меньше резервных магнитных лент приходится загружать администратору, тем проще ему работать, и точки восстановления Vista — шаг в правильном направлении. Кроме того, благодаря VSS у пользователей появляется возможность управлять процессом восстановления файлов. Но тщательное планирование и управление — обязательное условие полной реализации преимуществ службы VSS.

Ронда Лейфилд (rhonda@minasi.com) — консультант и преподаватель

Пять советов по VSS

При реализации VSS или подготовке точек восстановления Vista рекомендуется делать следующее:

Прежде чем активизировать точки восстановления VSS, выберите место хранения теневых копий. Помните, что впоследствии переместить их нельзя.
Размещение VSS на системном или загрузочном томе — неудачное решение. Файлы операционной системы часто изменяются, поэтому число теневых копий на загрузочном томе обычно бывает большим.
Оптимальный размер кластера для VSS — 16 Кбайт.
При хранении кэша теневых копий на физическом диске, отличном от диска-источника, повышается быстродействие и отказоустойчивость.
Ни VSS, ни точки восстановления не могут заменить полноценное решение резервного копирования.

Источник

19.02.2020 — Служба теневого копирования томов (VSS), утилиты VSSADMIN и DISKSHADOW

Продолжаем цикл полезных статей по работе с инструментами резервного копирования серверов на базе Windows Server. На этот раз речь пойдёт о службе теневого копирования и утилитах по работе с ней.

Служба теневого копирования тома (англ. Volume Shadow Copy Service, VSS) — служба операционной системы Windows, позволяющая копировать файлы, с которыми в данный момент времени ведется работа, включая системные и заблокированные файлы. Служба необходима для работы программы восстановление системы и программ архивации.

Для правильного выполнения операций резервного копирования и восстановления требуется тесное взаимодействие между приложениями резервного копирования, бизнес-приложениями, для которых выполняется резервное копирование, оборудованием и программным обеспечением управления хранением. Служба теневого копирования томов (VSS), которая появилась в Windows Server 2003, упрощает взаимодействие между этими компонентами, позволяя им лучше взаимодействовать между собой.

Как работает служба теневого копирования томов

Для нормальной работы VSS требуются следующие основные компоненты:

Компонент службы VSS операционной системы Windows, который позволяет другим компонентам правильно взаимодействовать друг с другом.
Служба VSS — программное обеспечение, запрашивающее фактическое создание теневых копий. Как правило, это приложение резервного копирования такие как система архивации данных Windows Server и приложение Data Protection Manager System Center. Сторонними инициаторами запросов VSS являются почти все программное обеспечение для резервного копирования, работающее в Windows.
Модуль записи VSS — компонент, обеспечивающий согласованность данных во время резервного копирования.
Поставщик VSS — компонент, который создает и поддерживает теневые копии.

На следующей схеме показано, как служба VSS координирует работу с запрашивающими сторонами, модулями записи и поставщиками для создания теневой копии тома.

Создание теневой копии

Картинка с сайта: it.oneweb.pro

Чтобы создать теневую копию, инициатор запроса, модуль записи и поставщик выполняют следующие действия:

Инициатор запроса запрашивает у служба теневого копирования томов перечисление модулей записи, собирает метаданные модуля записи и готовится к созданию теневого копирования.
Каждый модуль записи создает XML-описание компонентов и хранилищ данных, для которых необходимо создать резервную копию, и предоставляет их для служба теневого копирования томов. Модуль записи также определяет метод восстановления, который используется для всех компонентов. В службе теневого копирования томов содержится описание модуля записи для инициатора запроса, в котором выбираются компоненты, для которых будет выполняться резервное копирование.
Служба теневого копирования томов уведомляет все модули записи о подготовке данных для создания теневой копии.
Каждый модуль записи подготавливает данные соответствующим образом. Когда данные готовы к теневому копированию, модуль записи уведомляет службу теневого копирования томов.
Служба теневого копирования томов предписывает средствам записи временно заморозить запросы на запись операций ввода-вывода приложения (запросы ввода-вывода на чтение по-прежнему возможны) в течение нескольких секунд, необходимых для создания теневой копии тома или томов. Замораживание приложения не может длиться более 60 секунд. Служба теневого копирования томов очищает буферы файловой системы, а затем замораживает файловую систему, что обеспечивает правильную запись метаданных файловой системы и запись данных, подлежащих теневому копированию, в согласованном порядке.
Служба теневого копирования томов дает команду поставщику создать теневую копию. Период создания теневой копии длится не более 10 секунд, в течении которых все запросы на запись в файловую систему остаются замороженными.
Служба теневого копирования томов освобождает запросы ввода-вывода записи файловой системы.
Служба VSS сообщает средствам записи о разморозке запросов ввода-вывода приложения. На этом этапе приложения могут возобновить запись данных на диск, на который выполняется теневое копирование.
Инициатор запроса может повторить процесс (вернитесь к шагу 1) или уведомить администратора о необходимости повторить попытку позже.
Если теневая копия создана успешно, служба теневого копирования томов возвращает сведения о расположении для теневой копии запрашивающей стороне. После того как VSS и приложения выполняют изменения, теневая копия становится доступна только для чтения.

После создания теневой копии служба VSS начинает отслеживать изменение данных на диске. VSS разбивает все данные на блоки по 16Кб каждый, и если данные в таком блоке были изменены, служба записывает в файл теневой копии этот блок целиком. Таким образом получается, что при создании следующей теневой копии данных система не копирует данные целиком, а только лишь блочные изменения. Благодаря этому система теневого копирования позволяет существенно сэкономить место на диске. Теневые копии могут храниться на том же диске, на котором хранятся данные, либо на отдельном (решение для высоконагруженных систем с большой частотой изменения данных). Все файлы теневых копий хранятся в служебном каталоге System Volume Information. Эти файлы можно отличить по имени, все они содержат в имени идентификатор службы VSS — 3808876b-c176-4e48-b7ae-04046e6cc752.

Утилита VSSADMIN

Утилита VSSADMIN предназначена для администрирования в командной строке службы теневого копирования томов. С ее помощью создавать и удалять теневые копии, управлять хранилищами теневых копий, а также производить диагностику неисправностей модулей службы теневого копирования. Для работы с утилитой VSSADMIN запускаем командную строку от имени администратора, и введем команду vssadmin /?, после чего систем выведет список поддерживаемых команд. Познакомимся с возможностями утилиты и ее командами подробнее…

ADDSHADOWSTORAGE — создание новой ассоциации хранилищ теневых копий.

AddShadowStorage /For=ForVolumeSpec /On=OnVolumeSpec /MaxSize=MaxSizeSpec — добавление нового соответствия хранилищ теневых копий между томом ForVolumeSpec и томом хранилища теневых копий, который задан параметром OnVolumeSpec. Теневые копии ForVolumeSpec будут сохраняться на томе OnVolumeSpec. Максимальный размер, который сопоставление может занимать на томе хранилища теневых копий, задается параметром MaxSizeSpec. Если для параметра MaxSizeSpec установлено значение UNBOUNDED, размер хранилища теневых копий не ограничивается. При достижении максимально возможного числа сопоставления хранилищ теневых копий отображается сообщение об ошибке. Параметр MaxSizeSpec может задаваться в байтах или в процентном отношении к размеру тома хранилища ForVolumeSpec. Если параметр MaxSizeSpec задан в байтах, его значение должно быть не меньше 320MB; допускается использование следующих суффиксов: KB, MB, GB, TB, PB и EB. Также допускаются суффиксы B, K, M, G, T, P и E.

Чтобы задать значение параметра MaxSizeSpec в процентах, используйте знак % в качестве суффикса числового значения. Если суффикс не задан, значение MaxSizeSpec задается в байтах.

Пример использования:

vssadmin Add ShadowStorage /For=C: /On=D: /MaxSize=900MB
vssadmin Add ShadowStorage /For=C: /On=D: /MaxSize=UNBOUNDED
vssadmin Add ShadowStorage /For=C: /On=C: /MaxSize=20%

CREATESHADOW — создание новой теневой копии тома.

CreateShadow /For=ForVolumeSpec [/AutoRetry=MaxRetryMinutes] — создание новой теневой копии для тома ForVolumeSpec. ForVolumeSpec должен представлять букву диска локального тома или точку подключения. Если указан параметр MaxRetryMinutes и имеется другой процесс создания теневой копии, vssadmin будет продолжать попытки создать теневую копию в течение MaxRetryMinutes минут.

Примериспользования: vssadmin Create Shadow /For=C: /AutoRetry=2

DELETESHADOWS — удаление теневых копий тома.

Delete Shadows /For=ForVolumeSpec [/Oldest] [/Quiet]

Delete Shadows /Shadow=ShadowId [/Quiet]

Delete Shadows /All

Удаление всех соответствующих теневых копий для указанного тома ForVolumeSpec. Если указан параметр /Oldest, удаляется старейшая теневая копия на томе. Если указан параметр /All, на всех томах удаляются все теневые копии, которые можно удалить. Если указан параметр /Shadow=ShadowId, удаляется теневая копия с заданным ID. Могут быть удалены только теневые копии, имеющие тип ClientAccessible.

ID теневой копии можно получить с помощью команды List Shadows. Вводить ID теневой копии необходимо в следующем формате: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}, где X представляет шестнадцатеричные знаки. Этот ID можно получить с помощью команды List Shadows.

Пример использования: vssadmin Delete Shadows /For=C: /Oldest

DELETESHADOWSTORAGE — удаление ассоциации хранилищ теневых копий тома.

DeleteShadowStorage /For=ForVolumeSpec [/On=OnVolumeSpec] [/Quiet] — удаление соответствия хранилища теневых копий между томом ForVolumeSpecи томом хранилища OnVolumeSpec. Если не указан параметр /On, будут удаленывсе соответствия хранилищ теневых копий для тома ForVolumeSpec.

Примериспользования: vssadmin Delete ShadowStorage /For=C: /On=D:

LISTPROVIDERS — список зарегистрированных поставщиков теневых копий томов.

LISTSHADOWS — список существующих теневых копий тома.

ListShadows [/For=ForVolumeSpec] [/Shadow=ShadowId|/Set=ShadowSetId] — отображение существующих теневых копий в системе. Без параметров командаотображает все теневые копии, упорядоченные по набору теневая копий.

При создании списка допускается использование комбинаций параметров. ID теневой копии можно получить с помощью команды List Shadows. Вводить ID теневой копии необходимо в следующем формате: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}, где X представляет шестнадцатеричные знаки.

Пример использования: vssadmin List Shadows /Shadow={c5946237-af12-3f23-af80-51aadb3b20d5}

LISTSHADOWSTORAGE — список соответствия для хранилищ теневых копий томов.

ListShadowStorage [/For=ForVolumeSpec|/On=OnVolumeSpec] — отображение всех соответствий хранилищ теневых копий в системе. Чтобы получить полный список соответствий для указанного тома, следует указать параметр ForVolumeSpec без параметра /On. Для перечисления всех соответствий на томе, следует указать OnVolumeSpec без параметра /For.

Примериспользования: vssadmin List ShadowStorage /On=C:

LISTVOLUMES — список томов, подходящих для создания теневых копий.

LISTWRITERS — список устройств записи теневых копий томов с имеющейся подпиской.

RESIZESHADOWSTORAGE — изменение размеров для соответствующих хранилищ теневых копий томов.

ResizeShadowStorage /For=ForVolumeSpec /On=OnVolumeSpec /MaxSize=MaxSizeSpec — изменение размеров сопоставления хранилища теневой копии тома между ForVolumeSpec и OnVolumeSpec. Изменение размеров хранилища может привести к исчезновению теневых копий. По мере удаления теневых копий размер хранилища будет уменьшаться. Если для параметра MaxSizeSpec установлено значение UNBOUNDED, размер хранилища теневых копий не ограничивается. Параметр MaxSizeSpec может задаваться в байтах или в процентном отношении к размеру тома хранилища ForVolumeSpec. Если параметр MaxSizeSpec задан в байтах, его значение должно быть не меньше 320MB; допускается использование следующих суффиксов: KB, MB, GB, TB, PB и EB. Также допускаются суффиксы B, K, M, G, T, P и E. Чтобы задать значение параметра MaxSizeSpec в процентах, используйте знак % в качестве суффикса числового значения. Если суффикс не задан, значение MaxSizeSpec задается в байтах.

Примеры использования:

vssadmin Resize ShadowStorage /For=C: /On=D: /MaxSize=900MB
vssadmin Resize ShadowStorage /For=C: /On=D: /MaxSize=UNBOUNDED
vssadmin Resize ShadowStorage /For=C: /On=C: /MaxSize=20%

REVERTSHADOW — откат тома к теневой копии.

RevertShadow /Shadow=ShadowId [/ForceDismount] [/Quiet] — Откат тома к его состоянию во время создания теневой копии. Все теневые копии этого тома, созданные после этой точки, будут удалены. Все изменения файлов и папок на этом томе, сделанные после создания этой теневой копии, будут потеряны. Отмена операции отката невозможна. После запуска операции отката она не может быть прервана или отменена. Если имеются открытые дескрипторы файлов на этом томе, операция отката завершится ошибкой, если не указан флаг ForceDismount.

Пример использования: vssadmin Revert Shadow /Shadow={c5946237-af12-3f23-af80-51aadb3b20d5} /ForceDismount

QUERYREVERTS — опрос хода выполнения операций отката.

QueryReverts [/For=VolumeName] [/All] — опрос хода выполнения операций отката. Если имя тома указано с помощью флага /For, освещается ход выполнения операции отката этого тома. Если указан флаг /All, то освещаются все выполняемые операции отката.

Примериспользования: vssadmin Query Reverts /For=E:

УТИЛИТА DISKSHADOW

Утилита командной строки DISKSHADOW это инструмент, который предоставляет функциональные возможности, предлагаемые службой теневого копирования томов (VSS). По умолчанию в Diskshadow используется интерактивный интерпретатор команд, аналогичный DiskRAID или DiskPart.

Для запуска утилиты в командной строке запущенной от имени администратора введите следующую команду, чтобы запустить интерпретатор команд – DISKSHADOW.

LISTWRITERS — выводит список всех средств записи на компьютере.

LISTSHADOWS — выводит список всех теневых копий томов на компьютере.

LISTPROVIDERS — выводит список всех поставщиков VSS на компьютере.

SET — выводит список всех текущих параметров и всех псевдонимов сценария DiskShadow, имеющихся в параметрах переменной среды.

SETCONTEXT — устанавливает контекст теневого копирования.

SETOPTION — устанавливает параметры, относящиеся к теневому копированию и автовосстановлению.

SETVERBOSE — изменяет режим подробного вывода для сценария DiskShadow.

SETMETADATA — указывает имя CAB-файла для хранения метаданных переносимых теневых копий.

SIMULATERESTORE — моделирует операцию восстановления.

LOADMETADATA — загружает документ архивных компонентов перед импортом переносимой теневой копии или выполнением операции восстановления.

IMPORT — импортирует теневые копии на основе метаданных, указанных в предыдущей команде LOAD.

WRITERVERIFY — указывает, что операция архивации или восстановления должна завершиться с ошибкой, если не включено средство записи или компонент.

WRITEREXCLUDE — исключает средство записи или компонент из архивации или восстановления.

ADD— выводит список добавленных на данный момент псевдонимов и томов.

ADDALIAS — добавляет псевдоним.

ADDVOLUME — добавляет том к набору создания теневой копии.

ADDSHADOW — Добавляет теневую копию к набору восстановления.

CREATE— создает набор теневых копий томов.

EXEC — выполняет указанный сценарий команд оболочки.

BEGINBACKUP — начинает полную архивацию.

BEGINRESTORE — начинает восстановление.

ENDBACKUP — завершает полную архивацию.

ENDRESTORE — завершает восстановление.

EXPOSE — предоставляет теневую копию.

UNEXPOSE— не предоставляет теневую копию.

REVERT — возвращает прежнее состояние теневой копии.

RESYNC— Аппаратный откат теневой копии.

BREAK — разрушает теневую копию.

MASK— скрывает от системы импортированную аппаратную теневую копию.

DELETESHADOWS — удаляет теневые копии.

RESET — сбрасывает сценарий DiskShadow в его исходное состояние.

EXIT — выполняет выход из сценария DiskShadow.

Источник