I3 10100 windows 7

Search by either entering keywords or by selecting a product.

Configure Shadow Copy on Windows Storage Server 2016

1.    Right click on the drive that you want to activate Shadow copies, then select Properties.

Картинка с сайта: buffaloamericas.com

2.    Switch to the Shadow Copies Tab, make sure the correct volume is selected, then click Enable.

3.    Click Yes in dialog prompt.

4.    Once enabled, a shadow copy of the volume will be automatically taken.

Click the Settings button to further configure the options

5.    You can adjust the size limit of the volume copies. It will delete the oldest copy if the size limit has been reached.

6.    Click Schedule to set the schedule to run the shadow copies

7.    In the Advanced Schedule Options interface, you can select it to be a Repeat task, with the frequency and running time.

Once the volume has shadow copies created, you should be able to revert Volume/Folder/File changes using the Shadow copy.

8.    At volume level, simply select the Shadow copy version you want and click Revert.

Please note that an operation system volume cannot be reverted, you will get the following error.

9.    To simulate a folder restoration, we will delete a test file from our test folder.

10.    Right-click the test File folder, and then click Restore previous versions.

11.    Click the most recent folder version for test folder and then click Open.

12.    Confirm that the deleted test file exists in the opened shadow copy window, then we can copy it back to our test folder.

Картинка с сайта: buffaloamericas.com

13.    We can also restore the entire folder to previous version.

Version restore can also be done at file level on a Shadow Copy enabled volume.
14.    Right click on the file and choose «Restore Previous Versions»

15.    Select the version you want to restore, and hit «Restore»  

Click «Restore” again in dialog prompt.

When the process completes the test file has been reverted to the previous version.

Related Videos:

Using the Buffalo TeraStation NAS with Windows Server IoT as a Central Backup Hub

Office 365 Backup with TeraStation WS IoT

TeraStation Windows Server IoT 2019 Network Storage

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

Возьмем в качестве примера файловый сервер с множеством каталогов и большим количеством пользователей, бэкап которого выполняется, допустим, ежедневно. Представим ситуацию, что пользователь в начале рабочего дня внес важные изменения в некий сверхкритичный документ, а в течении рабочего дня, случайно его модифицировал или удалил. Восстановить данный документ из резервной копии не получится, т.к. он в нее просто не попал. Настроить традиционный бэкап файлового сервера в течении рабочего дня технически затруднительно (да и сама процедура создания и восстановления из такого бэкапа может занять довольно много времени, усугубляющаяся использованием инкрементального или дифференциального бэкапа). В такой ситуации «спасти» положение может теневое копирование данных с помощью службы Volume Shadow Copy Service.

Эта статья посвящена настройке теневого копирования томов (Volume Shadow Copy) в новой серверной ОС Windows Server 2012.

Рассмотрим основные преимущества службы VSS по сравнению с классическими средствами резервного копирования данных:

• Высокая скорость создания резервных копий
• Возможность самостоятельного восстановления файлов пользователями (при наличии прав на запись в каталог)
• Возможность копирования используемых (заблокированных) пользователями файлов
• Небольшой размер копий (по информации MS около 30 Мб на 1 Гб данных)

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

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

Еще несколько особенностей VSS:

• По-умолчанию максимальное количество хранимых снапшотов для диска – 64. При превышении этого значения, служба VSS начинает циклическую перезапись теневых копий, удаляя самые ранние снапшоты.
• Под теневые копии система выделяет 10% емкости раздела, однако это значение можно изменить.
• Теневое копирование включается для тома целиком, и включить его для отдельной общей папки невозможно.
• Microsoft не рекомендует создавать снапшоты чаще, чем раз в час (однако, это всего лишь рекомендации).

Настройка теневого копирования сетевого каталога в Windows Server 2012

Попробуем настроить теневое копирование данных общей сетевой папки, расположенной на отдельном диске сервера с ОС Windows Server 2012.

Откройте оснастку «Управление компьютером» («Computer Management»), разверните блок «Служебные программы», щелкните правой кнопкой мыши по элементу Общие папки и выберите Все задачи -> Настроить теневые копии.

Картинка с сайта: winitpro.ru

Затем нужно включить теневое копирование для раздела, на котором хранятся общие сетевые папки. Для этого выберите нужный том и нажмите кнопку «Включить». В этот момент будет создана первая теневая копия раздела (снапшот).

Картинка с сайта: winitpro.ru

Далее необходимо задать максимальный размер копий и периодичность (расписание) их создания. Нажмите кнопку Параметры.

Картинка с сайта: winitpro.ru

В данном примере настроим создание теневых копий по следующей схеме: снапшоты общих папок должны создаваться ежедневно в течении рабочего дня (с 9:00 до 19:00) каждые 10 минут. Вы, естественно, основываясь на особенности бизнес-процессов компании, можете настроить собственное расписание.

Картинка с сайта: winitpro.ru

Если через некоторое время открыть свойства общей папки и перейти на вкладку «Предыдущие версии», то можно увидеть список доступных на данный момент теневых копий.

Далее у пользователя есть три варианта действия: просмотреть содержимое копии (Открыть), скопировать данные из копии в другое место (Копировать) или восстановить данные с перезаписью (Восстановить)

Картинка с сайта: winitpro.ru

При попытке восстановить содержимое копии на момент снапшота появится соответствующее предупреждение.

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

Отметим также, что функция теневого копирования в Windows 8 была заменена на функцию File History

Картинка с сайта: habr.com

Снятие снапшота — именно с этого начинается любой бекап. До тех пор, пока мы не знаем, как сбросить все буфера на диск и привести файлы с данными в консистентное состояние, мы не бекапы делаем, а занимаемся копированием файлов с непредсказуемым содержимым внутри. Понимая важность снапшотов, все вендоры стараются дать нам если не полностью готовую функцию (типа 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.

Картинка с сайта: habr.com

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

Картинка с сайта: habr.com

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

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

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

Картинка с сайта: habr.com

Технически ничего не мешает одновременно делать снимки с помощью 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, то обязательно пишите об этом в комментариях.

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

Теневое копирование — это служба, делающая копии файлов на дисках в заданные периоды времени. Она позволяет также делать копии независимо от того используется файл или нет. Благодаря этому она позволяет быстро просмотреть состояние папки на предшествующий момент времени или, при необходимости, восстановить случайно удаленные файлы независимо от их наличия в корзине. Необходимо понимать, что теневое копирование не отменяет необходимость резервного копирования, а служит лишь дополнением к нему.

Для включения этой функции достаточно выполнить следующие операции: Открыть свойства соответствующего диска и перейти на закладку “Теневые копии”.

Встать на соответствующий диск и нажать “Включить”.

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

Картинка с сайта: oblako.kz

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

Теперь у каждой папки и файла на закладке “предыдущие версии” есть информация о теневых копиях откуда можно просмотреть содержимое папки на предшествующий период или восстановить файл.

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

Так эта закладка выглядит для файла

А так для папки

На этом настройка теневого копирования томов на Windows Server 2016 окончена. В нашей базе знаний вы найдете еще множество статей посвящённых различным аспектам работы в Windows, а если вы ищете надежный виртуальный сервер под управлением Windows, обратите внимания на нашу услугу — Аренда виртуального сервера Windows.

 

Последнее обновление: 01.11.2023