Снятие снапшота – именно с этого начинается любой бекап. До тех пор, пока мы не знаем, как сбросить все буфера на диск и привести файлы с данными в консистентное состояние, мы не бекапы делаем, а занимаемся копированием файлов с непредсказуемым содержимым внутри. Понимая важность снапшотов, все вендоры стараются дать нам если не полностью готовую функцию (типа Time Mashine в MacOS), то хотя бы набор ручек, за которые можно подёргать (вроде модуля dm-snap в ядре Linux).
Но сегодня речь пойдёт про самую распространённую ОС – Microsoft Windows, где эта задача решается с помощью Volume Shadow Copy сервиса, известного в народе под аббревиатурой VSS (Volume Snapshot Service). А нашего внимания он удостоился из-за того, что, несмотря на всю популярность своего материнского корабля, сам он окутан вуалью из тайн и мистических слухов. Давайте уже как-то разберёмся с этой штукой.
Но проблема в том, что более лучшая документация, намного правильнее отражающая происходящие процессы, несколько сложна для понимания. Microsoft вообще написал по этой теме какое-то неслыханное количество документов. Но даже когда вам как-то удаётся выстроить в голове работу этого алгоритма, вы сразу сталкиваетесь с тем, что на практике многие вещи работают совершенно не так, как описаны. Или вообще не работают. А что-то не описано совсем, хотя этому мы уже давно не удивляемся. Но не хвататься же сразу за дебагер и дизассемблер, да?
Вот поэтому и захотелось немного поговорить о том, как же на самом деле работает 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. Чисто технически туда и до этого можно было зайти, однако внутри, скорее всего, будет только гнетущая пустота.
И запоминаем самое важное: это две разные утилиты, существующие в разных контекстах. Теневая копия, сделанная в одной утилите, будет видна другой, однако статус у неё будет неоперабельный.
Как появился 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 сервису делать снапшот. Или не даёт, если приложение не смогло за установленный промежуток времени подготовить свои файлы.
- 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 пропагандирует CoW подход, то речь здесь действительно о банальном удалении нашей аллоцированной зоны, ведь все новые данные сразу пишутся на оригинальный диск. Это называется non-persistent shadow copy, и она не имеет никакого смысла без оригинального диска.
Чтобы пройти этот путь вручную, достаточно открыть консоль и набрать:
Здесь мы видим, что успешно создался снапшот со своим Shadow copy ID, и для удобства ему сразу присвоили алиас VSS_SHADOW_1. Этими данными вполне можно оперировать, если возникает такое желание. Однако не будем уходить в сторону и попробуем прочитать содержимое этого снимка. Для чего подмонтируем его в качестве диска.
Однако на такое, казалось бы, простое и законное желание мы получили не менее законный отлуп, ибо сделали non-persistent снимок, а, значит, единственное, на что он годится – это записать его поверх родного, удалив на нём всю информацию, которая появилась после создания этого снимка. Но такая история нас не устраивает, поэтому стираем всё безжалостно.
И начинаем всё заново, только теперь укажем, что нам нужна персистентная копия, чтобы мы могли использовать её как полноценный диск.
Как мы видим: Attributes: No_Auto_Release Persistent Differential. Поэтому если теперь вы сделаете expose, то снапшот примаунтится как полноценный диск, по которому можно перемещаться и копировать с него файлы. Диск, само собой, виртуальный и состоит из блоков оригинального диска, плюс блоки изменившихся данных, читая которые, мы можем видеть состояние оригинального диска на момент снапшота. Всё просто.
Только учтите, пожалуйста, такой момент, если вдруг решите, что нашли святой грааль: в таком режиме нельзя занимать данными больше 50% места на диске. Один блок свыше – и всё, диск переполнился.
Поэтому когда за дело берётся настоящее бекапное приложение вроде Veeam Backup & Replication, то речь идёт не об одной команде, а о целой россыпи предварительных запросов, в результате которых формируется огромнейшая команда (это не метафора для красного словца, а реальность), в которой учитываются состояния райтеров и приложений на целевой системе, с жестким требованием соответствия всех статусов необходимым. Словом, количество мест, где что-то может пойти не так, вырастает на порядок. Ведь нам главное – не снапшот создать, закрыв глаза на сопутствующие потери, а гарантировать консистентность данных внутри него.
Как лечить VSS
Сразу, не отходя от кассы, открою вам тайну самого лучшего метода лечения большинства проблем с VSS – перезагрузка. Понимаю, что это кощунство и кошмар наяву для всех свидетелей аптайма, но суровая правда жизни такова, то можно сколь угодно долго биться с пациентом, чтобы потом всё починилось само от перезагрузки. Да, именно так. Это тот случай, когда само сломалось и само починилось.
Другая проблема – это железо. Помните про временные рамки для райтеров? Про десять секунд на снапшот? Для многих это ограничение становится проблемой из-за того, что СХД физически не успевает сделать требуемые действия за отведённое время. Как это лечится? А вот никак. Или покупаем более мощное железо, или ищем пути снижения нагрузки, чтобы операция была проведена за выделенный промежуток времени.
Если посмотрите одно из самых популярных KB1680: VSS Timeout when backing up Exchange VM, то легко обнаружите, что первые три шага для решения всех проблем с VSS – сделайте снапшот вручную и посмотрите чтобы это заняло менее 20 секунд, перезагрузитесь и попробуйте снизить нагрузку. Вот так и живём, да.
И что же делать, если VSS падает, в ивентах ничего нет, а понять, что происходит надо? Тут я могу порекомендовать три хороших статьи:
Также в гугле можно найти массу толковых советов по поводу приведения VSS в чувства, только рекомендую не бросаться на первый попавшийся случай, а постараться найти наиболее похожий именно на вашу проблему. По коду ошибки, например. Потому что слишком много возможных комбинаций ошибок, приложений и причин их возникновения.
А на сегодня всё. Я и так хотел кратенько, но получилось больше десяти страниц текста. Поэтому самое время закругляться. Если хочется раскрытия какой-то другой темы или углубиться в детали VSS, то обязательно пишите об этом в комментариях.
Теневое копирование предназначено для создания точек восстановления и выполняется операционной системой в фоновом режиме. В Windows 10 функция включается автоматически при установке обновлений, но только тогда, когда размер системного тома превышает 128 Гб. Во всех остальных случаях служба VSS не запускается. Наши эксперты рассказывают, как настроить теневое копирование и автоматизировать процесс создания контрольных точек восстановления.
Свойства системы
Вызываем диалоговое окно «Выполнить» сочетанием клавиш «Win+R». Набираем в подсвеченном маркером поле «sysdm.cpl». Жмем клавишу Enter или обозначенную рамкой кнопку «ОК» запуская классический апплет «Свойства системы».
Переключаемся на отмеченную единицей вкладку «Защита». Текущее состояние теневого копирования для системного тома «С» приведено в указанном стрелкой окне. Жмем обозначенную двойкой кнопку вызывая диалог настройки параметров.
В открывшемся окне переносим отмеченную цифрой «1» радиокнопку в положение «Включить». Используем ползунок, указанный двойкой, чтобы определить размер дискового пространства, отводимый под хранение резервных копий. По мере его смещения в правую сторону в подсвеченной маркером позиции показывается объем выделенной области диска в процентах и его абсолютное значение в гигабайтах. Записываем заданные параметры кнопкой «Применить». Жмем «ОК» закрывая диалог настройки.
Вернувшись в основное окно апплета, видим, что текущий статус функции теневого копирования изменился на «Включено». Жмем кнопку, обозначенную цифрой «2», чтобы создать первую точку восстановления в ручном режиме.
В подсвеченном маркером поле всплывающего диалогового окна набираем название резервной копии. Жмем обведенную рамкой кнопку «Создать», запуская процедуру теневого копирования.
Получив уведомление об успешном выполнении операции закрываем его. В дальнейшем система выполняет создание точек восстановления в фоновом режиме, без вмешательства пользователя.
Командная строка
Вызываем расширенное меню «Пуск» комбинацией клавиш «Win+X». Кликаем по обозначенной рамкой строке запуская оболочку PowerShell в режиме повышенных привилегий.
В строке-приглашении набираем «Enable-Computerrestore -drive “C:”» и нажимаем Enter. Команда включает функцию «Защита системы» для диска «С».
Создаем контрольную точку в ручном режиме. Вводим команду Checkpoint-Computer -Description ‘Point_name’. Заменяем в ней «Point_name» на желаемое имя. В приведенном на скриншоте примере это «Restore point 1».
Нажимаем Enter и дожидаемся завершения операции. Ход выполнения задачи отображается в окне консоли псевдографическим прогресс-баром и процентным индикатором.
Планировщик заданий
При включенной функции «Защита системы» автоматическое создание контрольных точек происходит при установке драйверов или обновлений. Если эти действия не выполнялись в течение семи дней, Windows создает резервную копию используя расписание, заложенное в планировщике заданий. При необходимости предустановленный интервал теневого копирования можно сократить создав для него новый триггер.
Вызвав диалоговое окно «Выполнить», набираем в текстовом поле «taskschd.msc». Нажимаем виртуальную кнопку «ОК» или клавишу Enter на физической клавиатуре запуская планировщик заданий.
Заходим в библиотеку и последовательно раскрываем подсвеченные зеленым маркером директории. Выделяем мышкой конечную папку «SystemRestore». В верхней части правой половины окна планировщика отобразится содержащееся в ней задание с именем «SR». Двойным щелчком по строке с описанием раскрываем диалог редактирования параметров.
Заходим на вкладку, обозначенную единицей. Жмем кнопку «Создать» для задания нового управляющего триггера.
Переносим указанную единицей радиокнопку в показанное на скриншоте положение. При необходимости корректируем время запуска задания в подсвеченном зеленым маркером поле. Закрываем диалог создания триггера кнопкой «ОК», одновременно записывая заданные значения.
Вернувшись в основное окно, переключаемся на вкладку «Условия». Снимаем галочки в зачеркнутых крестиками позициях. Записываем измененную задачу кнопкой «ОК».
В заключение
Пошаговые инструкции, приведенные нашими экспертами, позволят вам самостоятельно запустить и настроить теневое копирование в Windows 10. Выполнить операцию вы можете в графическом интерфейсе или при помощи оболочки PowerShell.
Что такое теневые копии простыми словами.
Открываем консоль Управление дисками
Для этого кликаем правой кнопкой по Пуск и выбираем пункт Управление дисками:
В более ранних версиях Windows нажимаем Пуск – Администрирование – Управление компьютером:
В открывшемся окне раскрываем Запоминающие устройства – Управление дисками:
Включаем теневые копии
В списке дисков находим нужный и кликаем по нему правой кнопкой мыши. Выбираем Свойства.
В появившемся окне переходим на вкладку Теневые копии и нажимаем кнопку Включить:
Если появится предупреждение, прочитайте его и нажмите Да. Пройдет несколько секунд и появится первая теневая копия.
Настраиваем расписание теневых копий
В этом же окне нажимаем Параметры:
В открывшемся окне кликаем по Расписание:
Составляем новое расписание или оставляем имеющееся:
Нажимаем OK 3 раза.
Как пользоваться созданными копиями
Теневые копии создаются только для измененных файлов и по заданному расписанию.
Чтобы восстановить предыдущую версию файла, кликаем по нему правой кнопкой мыши и выбираем Свойства. В открывшемся окне переходим на вкладку Предыдущие версии и находим список всех версий файла:
* если список окажется пустым, значит либо файл не менялся с момента создания, либо еще не отрабатывало задание по созданию теневой копии.
Чтобы восстановить старую версию файла, перетащите файл из списка на рабочий стол, проверьте его корректность и замените основной файл на восстановленный или задайте ему новое имя.
Была ли полезна вам эта инструкция?
Вы здесь: Статьи о PC Как включить и настроить теневое копирование файлов в Windows 10, 8.1, 8, 7
Товарищи, добрый день. По совету товарища, решил написать несколько статей о повышении безопасности для работы компьютера и файлов, хранящихся на нём. Это, относительно, простая и небольшая статья, будет просто частью одной очень большой общей статье о том, что нужно делать и понимать, чтобы не попасться на развод каких-либо мошенников и плохих людей. Не знаю, через сколько я её напишу, так как она должна быть реально огромная, но повышать компьютерную грамотность надо.
Так, что такое теневое копирование файлов? Это система Windows, которая в автоматическом режиме создает резервные копии файлов при создании точки восстановления системы (обычно при выключении и запуске компьютера). Данную функцию обязательно включать, если вы постоянно работаете с каким-либо важным документами и хотя при восстановлении предыдущих версий документов потеряется часть данных, зачастую это лучше, чем потерять файл полностью. Кстати, эта функция по сути, является единственным способом хоть как-то защититься от вирусов-шифраторов (о них тоже будет позже). Перейдем к включению данной функции.
Жмём сочетание клавиш Win+Pause/Break и в левом боковом меню открывшегося окна, жмём по ссылке «Защита системы«.
Откроется окно свойства системы на вкладке «Защита системы». В Windows 7 интерфейс попроще (можно выбрать только галочками жесткие диски, файлы с которых будут сохраняться), в современных операционных системах доступны некоторые настройки. Выбираем жесткий диск, файлы которого будут сохраняться и жмём кнопку «Настроить«.
Идеальный вариант — это купить ещё один жесткий диск и использовать весь его объем для файлов теневого копирования. Да это дорого, особенно по нынешним ценам, но если у вас важные документы, они могут быть дороже 10к за новый жесткий диск, то почему нет. Тем более, напомню о вирусах — шифраторах:)
В общем, побороли жадность, выбрали объем и нажали ОК.
Нас вернет в окно «Свойства системы», жмём кнопку «Создать» для создания новой точки восстановления.
Указываем какое-нибудь имя и жмём ОК.
Контрольная точка создается довольно быстро и система выдаст окно о готовности, через несколько секунд.
Для демонстрации работы теневого копирования, я перед созданием точки восстановления поместил некий файл-конфиг в корень диска Е, после создания добавил в него пару строк, сохранил и снова создал точку. Теперь открыв «Свойства файла» и перейдя на вкладку «Предыдущие версии» мы можем восстановить или открыть одну из них.
Материал сайта geekteam.pro
Потеря информации при перезаписи важных файлов может быть настоящей проблемой. Особенно часто она возникает при работе с файловыми серверами, доступ к которым есть у целого коллектива. В современных версиях Windows перезапись или удаление файла можно откатить благодаря наличию теневой копии.
В теневых копиях (VSS) содержатся записи об изменениях файлов. Копии делаются автоматически каждый час — по умолчанию Windows хранит целых 64 копии файла. Использовать их можно без прав администратора, что удобно — как для пользователей, так и для самого администратора :).
Вот несколько важных особенностей теневых копий:
- По умолчанию максимальное количество хранимых снапшотов для диска — 64. При превышении этого значения служба VSS начинает циклическую перезапись теневых копий и удаляет самые ранние слепки.
- Под теневые копии система выделяет 10% емкости раздела, однако это значение можно изменить.
- Теневое копирование включается для тома целиком, и включить его для отдельной папки невозможно.
- Microsoft не рекомендует создавать снапшоты чаще, чем раз в час.
Включение теневых копий
Список теневых копий
Как видишь, включить службу легко и никаких особых настроек она не требует. Польза же от этого может быть огромной. Впрочем, помни: теневые копии — это не замена бэкапу. Не полагайся на них и не ленись бэкапить все, как обычно.
Для начала, чтобы не было заблуждений, отмечу.Теневая копия — это не Средство восстановления системы из раздела Защиты системы Windows 10 — это более нужный инструмент для тех кто «в теме».
Из ВикипедииСлужба теневого копирования тома (англ. Volume Shadow Copy Service, VSS) — служба операционной системы Windows, позволяющая копировать файлы, с которыми в данный момент времени ведётся работа, и даже с системными и заблокированными файлами. Служба необходима для работы следующих программ: восстановление системы, программ архивации (Paragon Drive Backup, Acronis True Image, Leo Backup, R Drive Image и другие). Обычно служба запускается вручную.
В серверных версиях Windows теневое копирование обычно настраивается через графический интерфейс, задается размер диска под копии, какой диск и с какой периодичностью делать. В Windows 10 такого интерфейса нет, есть лишь Средство восстановления системы.
Расскажу как сделать теневую копию в Windows 10 и как настроить ее автоматическую работу.
Для создания теневых копий в Windows 10 используется команда, которую нужно выполнять с правами Администратора:
wmic shadowcopy call create Volume=c:
После удачного завершения команды, обычно это несколько секунд, будет создана теневая копия диска С.
Проверить можно так:Мой компьютер — в свойствах диска С — Предыдущие версии
Аналогично можно делать теневые копии других дисков меняя букву диска в команде.
Тоже не сложно! Используем для этого планировщик задач.
Создаем новое задание, указываем название.
Указываем периодичность создания теневой копии.
Действие для задачи — Запустить программу
и ее аргументы
Ставим галочку открыть окно «Свойства»
Ставим галочку «Выполнить с наивысшими правами» Так как теневые копии без прав администратора создать и удалить нельзя.
Задача Автоматического создания теневых копий настроена, можно запустить ее из планировщика и проверить что копия необходимого диска создана.
Удалить все теневые копии можно командой:
wmic shadowcopy delete
Эту команду можно установить в планировщик, например раз в месяц, до создания копии, тогда все копии будут удаляться и сразу создаваться новая. Это не очень удобно, так как лучше бы стирать например 25 старых, а 5 оставлять самых свежих.
Такой функции я не нашел, нашел удаление всех, кроме последней — это делается через Очистку диска и удаление конкретных копий по их кодам. Сами теневые копии занимают не много, на серверах я обычно оставлял по пол года копий, конечно зависит от размеров дисков, от интенсивности изменения информации на них.
Теневая копия штука нужная и является хорошим дополнением к резервному копированию, однако это не замена резервной копии!
Поделиться с друзьями:
Ещё похожие заметки
- https://xakep.ru/2016/05/09/faq-windows-shadow-copy/
- https://geekteam.pro/kak-vklyuchit-i-nastroit-tenevoe-kopirovanie-faylov-v-windows-10-8-1-8-7/
- https://nemcd.com/2019/09/shadow-copy-in-windows-10/
Для начала, чтобы не было заблуждений, отмечу.
Теневая копия — это не Средство восстановления системы из раздела Защиты системы Windows 10 — это более нужный инструмент для тех кто «в теме».
Из Википедии
Служба теневого копирования тома (англ. Volume Shadow Copy Service, VSS) — служба операционной системы Windows, позволяющая копировать файлы, с которыми в данный момент времени ведётся работа, и даже с системными и заблокированными файлами. Служба необходима для работы следующих программ: восстановление системы, программ архивации (Paragon Drive Backup, Acronis True Image, Leo Backup, R Drive Image и другие). Обычно служба запускается вручную.
Проверить можно так:
Мой компьютер — в свойствах диска С — Предыдущие версии
Время создания копии.
Я обычно создаю раз в день, на рабочих серверах 2 раза в день, утром до работы и вечером после окончания дня, можно еще немного раньше обеда. В общем время на ваш выбор.
Ставим галочку «Выполнить с наивысшими правами»
Так как теневые копии без прав администратора создать и удалить нельзя.
Заранее извиняюсь за косяки – машинный перевод + подредактирование вручную. Но эту историю надо знать.
“Карпатия” была надежным работником. Это не был грандиозный трансатлантический экспресс, построенный для участия в гонке за Синей Ленточкой и оформленный в стиле Версаля. Ее прибытие в Нью-Йорк сопровождалось меньшим вниманием со стороны публики, чем у других лайнеров.
Корабль был построен фирмой C S Swan and Hunter в Wallsend и спущен на воду без особых торжеств 6 августа 1902 года. Корабль весом 13 603 брутто тонн, способный развивать скорость лишь 14 узлов, был предназначен для перевозки венгерских эмигрантов из Средиземноморья, преимущественно из портов Триест и Фьюме, в Нью-Йорк и новую жизнь в Соединенных Штатах. Эта роль была закреплена за кораблями Кунарда, Славонией и Паннонией, когда в 1904 году фирма получила контракт от правительства Венгрии на перевозку эмигрантов. Однако первый рейс “Карпатии” был совершен из Ливерпуля в Бостон в 1904 году. В ноябре того же года “Карпатия” начала свою работу в Средиземном море, перевозя эмигрантов без происшествий, а также американских туристов или возвращающихся эмигрантов восточном направлении за тариф в 5,10 фунтов стерлингов.
Лайнер «Карпатия» получил сигнал бедствия от «Титаника» в 00:20 15 апреля 1912 года. Он находился на расстоянии 58 миль, расстояние, которое абсолютно невозможно было преодолеть менее чем за четыре часа.
В ту ночь, радио оператор “Карпатии” Хэрольд Коттэм задержался на своём посту на 10 минут, прежде чем ложиться спать, и к счастью, не снял наушники, что позволило ему услышать сигнал бедствия от “Титаника”. Даже не зашнуровав ботинки обратно, он ринулся сообщить о ЧП капитану.
Если бы радист ушёл с поста в назначенное время – если бы он снял наушники – никто из пассажиров “Титаника” не остался в живых
Капитан «Карпатии» Рострон мгновенно встал с постели, когда его разбудил радист, приказал своему кораблю прийти на помощь «Титанику» и подтвердил сигнал, прежде чем полностью оделся. Капитану ещё ни разу в жизни не приходилось сталкиватся с экстренной ситуацией в море. Но в эту ночь, он решил действовать так, чтобы даже если кому-то сказали что, мол, “капитан Рострон можеть быть и компетентен, но неопытный, всего-то 42 года, всего-то 3 года управляет кораблём”, никто бы этому не поверил.
Все спасательные шлюпки «Карпатии» были готовы к развертыванию. Баки с нефтью были приспособлено для слива с борта корабля на случай, если море станет неспокойным; нефть покроет и успокоит воду возле Карпатии, если это произойдет, и спасательным шлюпкам будут безопаснее подходить к ней. Капитан приказал установить огни вдоль борта корабля, чтобы выжившие могли его лучше видеть, а вдоль его бортов установили сети и лестницы, готовые сбросить их, когда они прибудут, чтобы позволить как можно большему количеству выживших подняться на борт из смертельно холодной воды.
Я не знаю, было ли оптимизмом то, что он предусмотрел, что в воде все еще есть выжившие. Я думаю, он знал, что они никогда не успеют туда вовремя. Я думаю, он все равно это сделал, потому что, “боже, нужно надеяться”.
В «Карпатии» было три столовых, которые сразу же были превращены в сортировочный и медпункт. К каждому приставлен врач. Горячий суп, кофе и чай были приготовлены оптом в каждой столовой, а одеяла и теплая одежда собраны для раздачи. К этому времени многие пассажиры проснулись — подготовка корабля к оказанию помощи при стихийных бедствиях — дело не тихое — и все они подошли, чтобы помочь; многие пожертвовали свою одежду и одеяла.
А затем он сделал то, что можно назвать “отвлечением всей энергии от системы жизнеобеспечения”. Фанаты “Star Trek”a поймут.
Вот что касается пароходов: они работают на паре. Удивительно, да-да; но этот пар питает абсолютно всё на корабле, а прямо сейчас “Карпатии” нужна была ВСЯ энергия. Поэтому Рострон отключил горячую воду и центральное отопление, отводившее ценную энергию пара, везде, кроме столовых, которые, конечно же, использовались для приготовления горячих напитков и приема выживших. Он разбудил всех инженеров, всех кочегаров и углегрузчиков, направил весь этот пар обратно в двигатели и велел своему кораблю идти как можно быстрее.
И когда он это сделал, капитан приказал идти ещё быстрее.
Мне нужно, чтобы вы поняли, что вы просто не можете разогнать корабль намного выше его максимальной скорости. Толкать такой огромный тоннаж по воде становится все труднее с каждым дополнительным узлом, превышающим скорость, на которую он был рассчитан. Толкать корабль выше номинальной скорости не только безрассудно — им не только сложнее маневрировать, но это также создает невероятную нагрузку на двигатели. Корабли не предназначены для превышения их максимальной скорости даже на один узел. Они не могут этого сделать. Это невозможно.
Максимальная скорость «Карпатии» — в режиме «сделай или умри», «двигатели не могут выдержать это вечно» — четырнадцать узлов. Уворачиваясь от айсбергов, в темноте и на морозе, в окружении тумана, она выдержала скорость почти семнадцать с половиной.
Никто их об этом не просил. Этого не ожидалось. Они были почти в шестидесяти милях от них, и на их пути стояли айсберги. Они обязаны были ответить; они не обязаны были делать невозможное и делать это с апломбом. Никто бы не обвинил их, если им потребовалось больше времени, чтобы подтвердить серьезность проблемы. Никто бы не обвинил их в медленном и осторожном подходе. Никто, кроме самих себя.
Они чуть не нарушили законы физики, мчась галопом на север во тьму в отчаянной надежде, что если им удастся сократить время прибытия на час, полчаса, пять минут, может быть, еще для одного человека эти пять минут будут иметь значение.
Они взяли на себя риск напороться на айсберг. Они приняли риск взрыва парового котла и повреждения двигателей. В лучшем случае, это грозило остановкой судна, а в худшем – потопления. Но никто, ни один человек на борту, не бунтовал и не протестовал.
Факт: только за время подъема со спасательных шлюпок погибло три человека. Насколько нам известно, через час их могло быть больше. Каждая минута нахождения в жестокой, холодной воде, уносила жизни.
Факт: экипаж “Карпатии” изменил мировую историю.
Этот корабль и его команда получили сообщение от локации, куда они не могли надеяться добраться менее чем за четыре часа. Чуть более трех часов спустя они достигли последних известных координат Титаника.
Через полчаса после этого, в 4 часа утра, они наконец найдут первую из спасательных шлюпок. Последний выживший будет доставлен на борт до 8:30 утра. Пассажиры из Карпатии повсеместно уступали свои койки, каюты и одежду выжившим, помогая экипажу на каждом шагу и сидя с рыдающими спасателями, чтобы предложить им все, что они могли утешить.
В общей сложности 705 человек из оригинального 2208 Титаника были доставлены на “Карпатию” живыми.
Ни один другой корабль не найдет выживших.
В 00:20 15 апреля 1912 года произошло чудо.
Если бы не героизм капитана, не слаженная работа экипажа, и не единогласное соглашение на жуткий риск от всех пассажиров – вполне возможно что НИКТО из пассажиров “Титаника” бы не спасся.
Все, кто выжили – выжили ТОЛЬКО благодаря “Карпатии”.
Простенький, неприметный корабль, перевозивший бедных иммигрантов из Венгрии в США, совершил героический подвиг, и спас сотни жизней пассажиров супер-элитной “звезды Уайт Стар Лайн”.
Давайте не забывать эту часть, упоминая историю “Титаника”.
