Как сделать snapshot vmware

Обновлено: 07.07.2024

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

В этой статье мы покажем, как создавать в среде VMWare создавать, удалять и консолидировать снапшоты из командной строки PowerCLI.

Создаем снапшот ВМ из PowerCLI

Предположим, вы уже подключились в PowerCLI к своему серверу vCenter с помощью командлета Connect-VIServer. Для создания снапшота используется командлет New–Snapshot.

New-Snapshot -vm msk-app01 -Name beforeAppUpdate

Или можно воспользоваться конвейером:

get-vm -Name msk-app01 | New-Snapshot -Name beforeAppUpdate

В списке снапшотов ВМ появится еще один.

Можно получить список имеющихся снапшотов определенной ВМ с помощью команды:

Get-VM -name msk-app01 | Get-Snapshot | Select VM,Name,Created,SizeMB | FT

Можно получить список снапшотов за определенный период. Например, нам нужно найти все ВМ со снапшотами, созданными более 30 дней назад:

Get-VM| Get-Snapshot |Where | Select-Object VM,Name,Created,SizeGB | FT

Удаление снапшота ВМ из PowerCLI

Можно удалить снапшот с помощью командлета Remove-Snapshot.

Get-VM -Name msk-app01 | Get-Snapshot | Remove-Snapshot

Появится уведомление, в котором у вас запросится подтвердить удаление всех снапшотов.

Если вы хотите удалить только один снапшот, нужно указать его имя.

Get-VM -Name msk-app01 | Get-Snapshot -name beforeAppUpdate | Remove-Snapshot

Можно одной командой удалить все снапшоты старше 30 дней у всех ВМ в vCenter:

Запуск консолидации дисков из PowerCLI

При удалении одного или всех снапшотов (DeleteAll) у виртуальной машины, они немедленно пропадают из консоли Snapshot Manager, после чего выполняется консолидация .vmdk файлов в VMFS хранилище. Если при консолидации произойдет ошибка, старые файлы снапшотов vmdk дисков могут остаться на хранилище. Вы можете выполнить консолидацию дисков с помощью командлета Consolidation:

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

Что такое snapshot

Снапшот (Snapshot - снимок) - это сохранение состояния виртуальной машины в определенной точке, необходимой именно вам, его еще называют снимком виртуальной машины. Еще можно дать вот такое определение: Snapshot VMware - это копия файла диска виртуальной машины (VMDK) в определенный момент времени. Снимки предоставляют журнал изменений для виртуального диска и используются для восстановления виртуальной машины в определенный момент времени, когда происходит сбой или системная ошибка. Снимки сами по себе не обеспечивают резервное копирование, если проще SNAPSHOT это НЕ БЭКАП.

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

Где применим снапшот

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

Как создать снапшот в VMware vSphere

Сама процедура очень простая и сейчас будет описана. Если же вы захотите ее автоматизировать, то советую почитать Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5.

сразу подчеркиваю shapshot это не замена бэкапа, запомните это

Выбираете любую виртуальную машину, щелкаете по ней правым кликом и из контекстного меню выбираете Snapshot > Take Snapshot

В следующем окне задаем имя snapshot и при желании описание в поле description. Обратите внимание на две возможные галки

В ESXI 6.5 и выше, создание снимка виртуальной машины делается подобным образом, но уже из веб-интерфейса. Вы так же выбираете нужный сервер, вызываете его контекстное меню "Snaphots - Tale Snapshot"

Описание параметров снимка

Snapshot the virtual machine's memory > данная опция нужна для того, чтобы во время снятия snapshot esxi виртуалки было состояние оперативной памяти, что при откате даст работающую виртуальную машину. Если вы ее снимите, то вернувшись из снапшота виртуальная машина будет выключена, но зато такой снапшот будет создаваться быстрее, так как нет необходимости сохранять оперативную память в файл, особенно если память большая и постоянно обновляется.
Quiesce guest file system (need VMware Tools installed) > Это процесс при котором подготавливаются данные на виртуальном диске в состояние требуемое для резервного копирования. Заморозить гостевую файловую систему (требуется установка VMware Tools и ее драйвер Sync Driver) позволяет гарантировать, что данные гостевой операционной системы останутся не поврежденными в снимке.

В итоге VMware Tools с помощью VMware Snapshot Provider запускает создание VSS snapshot внутри гостевой ОС. После чего все VSS writers (смотрим их командой "vssadmin list writers") в гостевой ОС получают запрос и подготавливают соответствующие приложения к бэкапу (происходит запись всех транзакций из памяти на диск). Когда все VSS writers заканчивают работу, они сообщают службе VMware Tools через VMware Snapshot Provider, который, в свою очередь, говорит VMware о том, что снапшот можно снять.
Таким образом все приложения резервного копирования для VMware vSphere используют следующие комбинации при отдании команды на создание снапшота VMware (заметьте, что процесс непосредственно создания снапшота целиком и полностью контролируется самой VMware)

Если делать бэкап без опции Quiesce guest file system, то могут быть большие проблемы при восстановлении контроллера домена или Exchange сервера.

Как создать снимок виртуальной машины через PowerCLI

Тут есть две конструкции, которые вы можете использовать в PowerCLI. В первом примере, мы вызываем виртуальную машину "Terminal", а далее создаем там снапшот с именем "Untill Update".

Get-vm -name "Terminal" | New-Snapshot -Name "Untill Update"

Во втором примере, мы воспользовались командлетом New-Snapshot, и обратились к виртуальному серверу, где создали снапшот с именем "Untill Update".

Структура файлов виртуальной машины при снятии Snapshot

Вот как выглядит структура файлов до снятия снапшота в VMware vSphere. Более подробно о форматах esxi файлов читайте по ссылке.

Теперь посмотрим, что изменится после снятия снимка виртуальной машины esxi 5.5. Как видите добавились файлы с форматом vmsn и добавленным в название 000001. Это и есть жесткий диск новых данных после снапшота.

Если посмотреть на эти же файлы в консоли ssh, то этот файл на самом деле состоит из четырех. У меня на скриншоте два снапшота и в сумме они занимают 8 фалов.

<name VM>-[шесть цифр]-delta.vmdk - файл данных диска отличий от базового диска
<name VM>-[шесть цифр].vmdk - заголовочный файл
<name VM>.vmsd - текстовый файл с параметрами снапшота (связи в дереве, SCSI-нода, время создания и т.п.)
<name VM>.vmsn - файл с сохраненной памятью виртуальной машины

Как можно предположить основной файл это delta, который включает в себя все отличительные данные после снапшота от основного виртуального диска. Данный виртуальный диск состоит из блоков данных хранимых в формате redo-логов (или просто дочерний диск - child disk). Он же sparse-диск, то есть диск, который использует технологию Copy-On-Write (COW) при работе с данными. Идея технологии copy-on-write — при копировании областей данных создавать реальную копию только когда ОС обращается к этим данным с целью записи. Таким образом, этот виртуальный диск содержит только измененные от родительского диска области данных (delta).

файл.vmsd. Это текстовый файл, открыв в редакторе вы увидите все отношения между родительским и дочерними дисками, а также другую интересную информацию

Хочу напомнить, что снапшоты лежат вместе с виртуальной машиной но их расположение можно поменять.

В гостевой ос

Что вы обнаружите например в событиях гостевой системы при создании снапшота без галки Snapshot the virtual machine's memory и включенной на Quiesce guest file system. Вы в просмотре событий, в журнале Приложения обнаружите ошибку VSS с кодом 12289 (Ошибка теневого копирования тома: Непредвиденная ошибка DeviceIoControl). Можете на нее забить, так как она происходит из за флоппи диска в конфигурации виртуальной машины.

так же если посмотреть через клиента VMware vSphere датастор на котором лежит виртуалка то вы обнаружите файл архив vss_manifests*.zip с конфигами с описанием всех найденных VSS writers в гостевой ОС.

если в архиве vss_manifests.zip только файл backup.xml — это означает, что снапшот по факту был сделан без использования VSS

Также стоит добавить некоторые требования к Quiesce guest file system

Поддержка Операционной системой консистентных снимков (VSS)
VSS компоненты VMware Tools установлены
Отсутствие динамических дисков внутри гостевой машины (Если внутри гостевой системы будет присутствовать хоть один динамический диск — не важно системный он или нет, то VSS задействован не будет. Снапшот будет создаваться успешно, но vss_manifests.zip будет пустым, как и логи событий внутри гостевой ОС. Это правило действует для гостевых ОСей Windows 2008 и выше)
Должна работать служба VSS в гостевой ОС

VSS- это сервис, который всего навсего перед бэкапом заставляет базу данных записать все транзакции на диск, далее БД приостанавливает свою работу, затем создаётся теневая копия тома, на что уходит несколько секунд, Далее БД продолжает свою работу в обычном режиме, а бэкап сливается уже с теневой копии. В VMWare теневая копия не создаётся, а создаётся delta vdmk, при этом исходный vdmk становится доступным на чтение и содержит консистентные данные, что позволяет его скопировать в качестве бэкапа.

Чем плохи снапшоты

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

Плюсы снапшотов

Возможность тестирования новых настроек или обновлений с возможностью легкого отката
Резервное копирование виртуальных машин на лету без остановки

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

Минусы снапшотов

snapshot быстро растут особенно при часто обновляемых данных. Растут они блоками по 16 мб. Если у вас например приложение СУБД, которое имеет много транзакций, то оно заполонит ваш датастор очень быстро, и может получиться так что на нем кончится место и виртуальная машина может перестать работать.
Еще большой проблемой являются длинные цепочки снапшотов, сделанных на разных этапах настройки, штук так по 15 или 20. Все это вызывает торможение виртуальной машины и хранилище отжирая лишние iops. Чем больше у вас цепочка тем дольше по ней идти до последнего снимка.

Так же когда снапшот делает или удаляется хранилище испытывает дополнительную нагрузку, так как на датастор сбрасывается память и снимок
Из за снапшотов вы не сможете использовать Fault Tolerance или Storage VMotion, так как привязаны к хранилищу с вашими snapshot.
Вы не сможете расширить виртуальный диск со снапшотом
Снимки виртуальных машин с дисками в режиме RDM или гостевыми операционными системами, использующими инициатор iSCSI в гостевой системе, не поддерживаются.
Снимки не поддерживаются устройствами ввода-вывода PCI vSphere Direct Path
Если виртуальная машина имеет виртуальные жесткие диски размером более 2 ТБ, выполнение снимка может занять значительно больше времени

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

Консолидация и удаление снапшотов / Удаление snapshot vmware

И так рассмотрим процедуру удаления снапшота. Выше мы узнали, что это снимки это зло, и вот еще почему. Не совсем понятное поведение снапшота при его удалении и слиянии с основным виртуальным диском vm машины. Для удаления и слияния вам потребуется свободное место на вашем дисковом массиве VMFS, это еще более актуально когда снимков несколько. Выше я привет снапшот как это может выглядеть. Предположим у вас виртуальная машина с тремя снимками вот таких вот размеров.

Вы допустим хотите удалить все снапшоты и нажимаете "Delete All в Snapshot Manager", далее идет вот такая операция Snapshot 3 сливается со Snapshot 2, но при этом сам Snapshot 3 остается на томе VMFS

В итоге первого шага мы получаем уже 90 гб (60+30). Теперь Snapshot 2 который весит уже 50 гб сливается с Snapshot 1, при этом Snapshot 2 и 3 не удаляются пока. Из этого следует что у нас уже занято 140 гб на хранилище.

Как только результирующий Snaphot 1 в 60 гб сольется с основным виртуальным диском при этом сам виртуальный диск flat в размере не меняется, поскольку он фиксирован (изменяется только содержимое блоков). И только затем все снапшоты удаляются (все 140 ГБ).

так что видите запас нужно всегда иметь, минимум 10 процентов.

Консолидация snapshot vmware

И так consolidation или консолидация, это по сути удаление снапшота со слиянием дисков, чаще всего оставленного каким нибудь средством резервного копирования, например veeam. Процесс consolidation vm я уже описывал, там все просто, но не понятно на сколько это влияет на датастор в плане производительности.

Что влияет на время консолидации в виртуальной машине

Размер delta-дисков - очень важный параметр. Чем больше данных в дельта-диске, тем дольше их нужно применять к основному (базовому) диску.
Число снимков и их размеры. Чем их больше, тем все будет дольше идти по времени. Кроме того, при нескольких снапшотах консолидация происходит в несколько этапов, описано выше.
Производительность подсистемы хранения, включая FC-фабрику, Storage Processor хранилищ, LUN (число дисков в группе, тип RAID массива).
Тип данных в файлах снапшотов (нули или случайные данные).
Нагрузка на хост-сервер ESXi при создании снапшота.
Нагрузка виртуальной машины на подсистему хранения в процессе консолидации. Например, почтовый сервер, работающий на полную мощность, может очень долго находится в процессе консолидации снапшотов.

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

Замирание stun виртуальной машины в VMware vSphere

Если вы как и я долго уже работаете с гипервизором Vmware ESXI 5.5, то наверняка обращали внимание, что бывают случаи, что виртуальная машина подвисает на какое то время, или дико тормозит, а потом работает как ни в чем не бывало. За это в vmware отвечает параметр stun или как мы выше смотрели quiescence. Когда это происходит виртуалка не может ничего делать, она чаще всего падает по Ping и недоступна, и перестает отвечать на операции ввода/вывода. Если сказать по простому то ее как будто поставили на паузу, а на уровне ввода-вывода совершаются только операции, касающиеся выполняемой задачи (например, закрытие прежнего VMDK-диска и переключение операций чтения-записи на новый диск при операциях со снапшотами).

Параметр Stun в виртуальной машины нужен, в большинстве случаев, для того, чтобы сделать ее на время изолированной от окружающего мира для выполнения значимых дисковых операций, например, консолидация. Это может занимать несколько секунд (и даже десятков), но часто это происходит на время около секунды и даже меньше, все зависит от нагрузки хранилища, у меня бывали случаи, что если виртуалка толстая и снапшот здоровый, то время stun доходило и до минуты, что сразу вызывало бурю паники, что у нас все сломалось и что вообще блин происходит, паникеры одним словом, просто не знающие как это работает.

Когда может быть заметен stun виртуальной машины

Во время выполнения процедуры приостановки виртуальной машины (suspend). Тут происходит такое подмораживание, чтобы скинуть память VM на диск, после чего перевести ее в приостановленное состояние.
Ну как все уже поняли во время создания снапшота, нужно закрыть старый диск и начать писать в новый.
Консолидация (удаление) снапшота, подробно описано выше.
При выполнении миграции с помощью vMotion. Слегка напомню данный механизм, во первых оперативная память передается от одной машины к целевой VM без подмораживания, но затем происходит такой же stun, как и при операции suspend, с тем только отличием, что маленький остаток памяти (минимальная дельта) передается не на диск, а по сети. После этого происходит операция resume уже на целевом хосте. Пользователь этого переключения, как правило, не замечает, так как время этого переключения очень жестко контролируется и чаще всего не достигает 1 секунды. Если память гостевой ОС будет меняться очень быстро, то vMotion может затянуться именно во время этого переключения (нужно передать последнюю дельту).
Горячая миграция хранилищ Storage vMotion. Здесь stun случается дважды: сначала vSphere должна поставить Mirror Driver, который будет реплицировать в синхронном режиме операции ввода-вывода на целевое хранилище. При постановке этого драйвера происходит кратковременный stun (нужно также закрыть диски). Но и при переключении работы ВМ на второе хранилище происходит stun, так как нужно удалить mirror driver, а значит снова пере открыть диски уже на целевом хранилище.

Как правильно удалить Snapshot в ESXI

У вас существует несколько методов удаления снимков:

Через веб-интерфейс
Через PowerClI
Через команды esxi cli

Как исключить диски из снимка

0. Оглавление:

1. Создание снимка состояния гостевой ОС в VMware Workstation 10

Создать снимок состояния гостевой ОС можно и тогда, когда она включена, и когда она выключена. В последнем случае гостевую ОС, естественно, нужно выбрать в списке библиотеки VMware Workstation 10.

В появившемся небольшом окошке программа предложит задать снапшоту имя и придумать ему описание. Описание – необязательное требование, оно реализовано скорее для удобства работы с гипервизором, когда скапливается масса снимков состояния гостевой ОС. В принципе, можно прямо в названии кратко описать специфику снапшота – например, «До установки такой-то программы» или «До смены таких-то системных настроек». Далее жмём кнопку «Создать снимок».

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

2. Восстановление гостевой ОС из снимка состояния в VMware Workstation 10

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

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

Определившись с нужным снимком состояния, кликаем его, чтобы восстановить гостевую ОС. Свои намерения подтверждаем, когда в появившемся окошке VMware Workstation 10 дополнительно запросит, действительно ли серьёзны наши намерения. Жмём «Да».

VMware Workstation 10 проведёт перезапуск гостевой ОС.

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

3. Работа с «Диспетчером снимков состояния»

Откроется окно с визуальным представлением имеющихся снимков состояния. Здесь снимки состояния можно:

Переименовывать и вносить изменения в их описания;

Клонировать – по сути, создавать отдельную виртуальную машину VMware Workstation 10 с тем же состоянием, что и у снимка;

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

4. Предостережения при работе со снимками состояния гостевой ОС

С последней функцией «Диспетчера снимков состояния» нужно обращаться предельно аккуратно, особенно, если файл виртуальной машины размещается на системном диске. Автоматически программа может создать огромное число снапшотов, которые будут занимать много места на диске.

В случае с системным диском это может привести к снижению производительности системы и к появлению надоедливых уведомлений Windows о нехватке дискового пространства.

Так что для полноценной работы со снапшотами файл виртуальной машины лучше перенести на несистемный диск. По умолчанию программа VMware Workstation 10 размещает файл виртуальной машины в папке пользовательского профиля:
«C:\Users\Имя_Пользователя\Documents\Virtual Machines\Имя_файла».

Желательно отсюда этот файл перенести.

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

После переноса файл виртуальной машины нужно открыть для отображения и работы в главном окне VMware Workstation 10.

Смотрите также:

Ошибки в работе системы, её сбой, внедрение вирусов и шпионского ПО – всего этого и прочих неприятностей в работе с компьютером можно избежать, если обучаться и вести эксперименты со сторонним…

Для работы с виртуальными машинами на рынке десктопного софта существует, по сути, только две программы – это VMware Workstation и VirtualBox. Все остальные либо малоизвестны, либо с ограниченным функционалом, либо…

Виртуальные машины VirtualBox и VMware Workstation всем хороши для тестирования операционных систем и софта, только вот почему-то ни одна из этих программ-гипервизоров не предусматривает в нормальном юзабельном формате опцию загрузки…

Запись опубликована в рубрике VMware Workstation с метками виртуализация. Добавьте в закладки постоянную ссылку.

3 Responses to Работа со снимками (SnapShots) состояния виртуальных машин в программе VMware Workstation 10

Отличный материал. Прекрасное изложение (если только чуть затянутое). Изумительные иллюстрации (лучшие видел только в МВТУ в исполнении Юрия Этумовича Шарикяна, единственной рукой чертившего эпюры начертательной геометрии цветными мелками). Во истину, знают многие, но научить, просто и доходчиво изложить дано далеко не каждому. Был учеником лучших преподавателей, по настоящему великих легендарных учёных, то есть имеется основа для сравнения. Благодарю Наташа, особенно за трудолюбие.

Извини, не бери в голову, привычка старого ворчать по любому поводу. Восприятие очень персонализировано, просто привычка работать с материалами несколько иного приложения. Главное , что все материалы по виртуализации изумительны и восприятие их в целом, как картины и как технологии понятно и оставляет очень хорошее впечатление. Буду рекомендовать знакомым.

Про моментальные снимки (снапшоты) виртуальных машин было написано великое множество статей, где ~~чрезмерно~~ подробно описана теоретическая часть сего действа. В своей статье я сфокусируюсь на практической стороне вопроса и исключительно на платформе VMware vSphere.

Так зачем нужны «quiesced» * снапшоты, с чем их едят, и какие типичные проблемы с ними возникают? Взгляд на снапшоты будет представлен в первую очередь с точки зрения резервного копирования, но постараюсь в какой-то мере раскрыть и другие аспекты использования.

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

Использование снапшотов для резервного копирования

Снапшот включающий состояние памяти виртуальной машины
Снапшот предваряемый так называемым quiescing-ом гостевой файловой системы

Собственно, альтернативный вариант и есть наша вторая опция — quiescing. Она представляет намного больший интерес и суть её в том, чтобы подготовить гостевую операционную систему (файловую систему в первую очередь) к снятию бэкапа.

Что же представляет из себя quiescing?

Если мы будем переводить официальную статью, то получится примерно следующее:

«Это процесс приведения данных на виртуальном диске в состояние „подходящее“ для резервного копирования. Данный процесс может включать в себя операции по „сливу грязных буферов“ (flushing dirty buffers) из памяти операционной системы на диск или другие высокоуровневые операции специфичные для конкретных приложений.»

Из данного описания о том, что с виртуальномй машиной происходит на самом деле понятнее не стало. Давайте разбираться сами.

Quiesced = ON, Memory = OFF
Quiesced = OFF, Memory = OFF

Вторую комбинацию мы рассматривать в данной статье не будем и сфокусируемся на процессе quiescing.

Зачем нужен quiescing?

Самый наглядный пример — это проблема USN rollback при восстановлении домен контроллера из бэкапа. Возникает она, если виртуализованный домен контроллер был забэкаплен без использования VSS (то есть без опции quiescing или других средств, которые обеспечивают запись транзакций на диск).

Никаких дополнительных действий и танцев с бубном производить не потребуется, если восстанавливать бэкап, сделанный с опцией quiescing. InvocationID будет корректно сброшен и вы увидите следующую запись в Event Log на загруженном после восстановления домен контроллере:

Event ID 1109: Active Directory has been restored from backup media, or has been configured to host an application partition. The invocationID attribute for this domain controller has been changed.

Поодобное корректное поведение можно наблюдать при использовании Acronis vmProtect 9. Собственно, его мы специально тестировали в рамках резервного копирования и восстановления виртуальных машин с домен контроллером внутри.

USN rollback, очевидно, не единственная возможная проблема при использовании «сырых» снапшотов и другие приложения (например Exchange/SQL — приложения в явном виде поддерживающие VSS) могут быть подвержены сбоям при восстановлении из таких снапшотов.

Как проверить, что снапшот создается корректно с использованием VSS?

Существует несколько способов определения корректности создания консистентного (до уровня приложения) снапшота:

Самый простой способ: войти в гостевую операционную систему и проверить «Просмотр Событий» (надо же было так перевести бедный Event Viewer). После создания снапшота с опциями quiesced=ON, snapshot memory=OFF (см скриншот в начале статьи) должны присутствовать события от соответствующих VSS writers в логах приложений:

Прим.: Ошибка от VSS с Event ID 12289, которую можно заметить на скриншоте, в реальности не является проблемой. Она относится к 3.5'' диску и, чтобы от нее избавиться, достаточно убрать флопик из конфигурации виртуальной машины:

Способ посложнее: использовать компонент Datastore Browser из vSphere клиента: в папке виртуальной машины на датасторе после создания quiesced снапшота должен появиться файл***vss_manifests*.zip.

Внутри файла содержится backup.xml с описанием всех найденных VSS writers в гостевой системе + метаданные по каждому райтеру в writerX.xml.

ВАЖНО: если в vss_manifests.zip содержится только backup.xml — это как правило означает, что снапшот по факту был сделан без использования VSS. Таким образом мы плавно подходим к самому интересному: исследованию проблем со снапшотами. Ниже я перечислю основные причины неработающих снапшотов. Стоит отметить, что основную опасность представляют не неработающие снапшоты (их легко детектировать), а именно те, которые VMware рапортует как успешные, в то время как данные снапшоты не являются таковыми.

Требования к окружению

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

Во-первых, убедитесь, что ваша комбинация vSphere + гостевой ОСи поддерживается для снапшотинга с консистентностью на уровне приложений по данной табличке (взята отсюда).

Данные актуальны для vSphere 5.0 и выше. Как вы можете заметить, для самых популярных на данный момент ОС (Windows 2008 и выше) стоят звездочки — в них то и зарыта главная собака, раскопками которой мы сейчас займемся.

Во-вторых, для того, чтобы quiescing реально работал, необходимо убедиться, что VSS компоненты VMware Tools действительно установлены (и естественно VMware Tools должны быть самой актуальной версии).

На старых версиях vSphere (3.5 и ранее) для quiescing использовался в том числе Legato Sync Driver, который гарантировал консистентность на уровне файловой системы, но не на уровне приложений (для чего как раз и нужны VSS компоненты). В настоящее время этот драйвер практически не используется и повсеместно заменен на VMware Snapshot Provider. Корректность установки можно проверить в гостевой операционной системе (на виртуальной машине) по наличию сервиса VMware Snapshot Provider + соответствующего COM+ компонента.

Какие могут быть косяки на данном этапе?

Если сервис VMware Snapshot Provider отключен, либо совсем не установлен, то VMware при снятии снапшота с опциями quiescing = ON, snapshot memory = OFF отрапортует, что он успешен, однако по факту снапшот будет произведен без использования VSS внутри системы, то есть посредством Legato Sync драйвера.

Заметьте, что в случае Windows 2008 и выше поведение отличается — там подобных событий в логе не наблюдается, а просто сервис Volume Shadow Copy переходит в запущенное, а затем в остановленное состояние.

В-третьих, одной из типичных проблем настройки quiescing'а является параметр disk.EnableUUID=true в конфигурации .vmx виртуальной машины.

Эта настройка имеет смысл только для гостевых систем под управлением Windows 2008 и выше (для Windows 2003 настройка игнорируется). Дополнительной особенностью является тот факт, что данный параметр автоматически прописывается при создании новой виртуальной машины только начиная с vSphere 4.1. Другими словами если виртуальная машина была смигрирована с более старой версии vSphere, то настройки может и не быть.

При отсутствии параметра, или же если он выставлен в «false», поведение при создании снапшота будет аналогично предыдущему случаю: снапшот создастся успешно, но по факту VSS будет не задействован и в результате мы можем получить неконсистентный бэкап. Второй симптом отключенного параметра — это пустой backup.xml (без описания VSS райтеров) в vss_manifests.zip.

В-четвёртых, проверьте наличие динамических дисков внутри гостевой машины. Если внутри гостевой системы будет присутствовать хоть один динамический диск — не важно системный он или нет, то VSS задействован не будет. Снапшот будет создаваться успешно, но vss_manifests.zip будет пустым, как и логи событий внутри гостевой ОСи. Это правило действует для гостевых ОСей Windows 2008 и выше.

То же самое касается IDE дисков — их не должно быть в конфигурации виртуальной машины (но наличие IDE CD-ROM устройств допустимо и на снапшоты не влияет). При этом надо учитывать, что количество свободных SCSI слотов на одном SCSI контроллере должно быть равно количеству дисков. Например: если на SCSI1 уже присутствуют 8 SCSI дисков, то слотов не хватит.

В-пятых: Неработающий VSS внутри гостевой машины. Это основной пункт вызывающий тонны негодования и обращений в техподдержку VMware. Часто люди, видящие неудачный снапшот, грешат на VMware, хотя винить стоит совсем другого гиганта мысли — Microsoft. Примерно такую картину я получил при попытке создать quiesced снапшот машины после неудачной установки новой базы SQL (виртуальный .iso привод был отмонтирован в процессе установки, что очень не понравилось установщику. :-\

Данная проблема была решена банальной перезагрузкой виртуальной машины, и хотя такой метод помогает очень часто, бывают запущенные случаи, когда VSS внутри сломан чуть менее, чем полностью. В этих случаях самый простой способ выяснить, действительно ли Microsoft виноват — это запустить Windows Backup и сделать резервную копию системного состояния (Backup of System State, если кто привык к английским терминам). Windows Backup (или NTBackup) работает — то проблема на стороне VMware, не работает — косяк Microsoft.

У VMware на эту тему есть несколько официальных статей: например тут и тут. Но есть интересная особенность — для упрощения себе жизни (возможно есть и какие-нибудь другие причины) во второй статье VMware в явном виде рекомендует выставить disk.EnableUUID в «false», что означает отказ от использования VSS при создании quiesced снапшота («quiesced-то не настоящий!»). В общем случае такой метод является не решением, а только временным обходным путем, так как последствия подобного подхода могут проявить себя при восстановлении, то есть именно тогда, когда консистентность приложений является ключевой (вспомнить хотя бы тот же USN rollback).

Подводим итоги

По моему опыту, самыми частыми проблемами при создании снапшотов (их неконсистентность) являются пункты 2, 3 и 5, в то время как IDE или динамические диски встречаются гораздо реже.

Конечно же, не исключены и совершенно мистические случаи: например снапшот не создавался (VMware рапортовала невнятную ошибку) по причине того, что iSCSI LUN (датастор), на котором располагалась проблемная виртуальная машина, был подключен физически через 2 сетевые карты в режиме teaming и при этом одна работала на 100MBit, а вторая на 1Gbit.

Тему quiesced снапшотов можно копать чуть ли не вечность — чего стоит хотя бы факт того, что Windows 2008 при создании quiesced снапшота создает не одну, а две дельты на датасторе и по факту пишет в уже созданный снапшот (это, кстати, одна из корневых причин звездочек напротив данных ОСей в табличке выше); или наличие возможности отключать определенные VSS райтеры через конфигурацию vmbackup.conf на гостевой системе. Мир чудесен и удивителен, но граблей хватит на всех. Если будет желание — я с радостью напишу что-нибудь ещё на эту тему. Как обычно, комментарии привествуются, уточнения — тоже, об ошибках и опечатках — в личку, на вопросы постараюсь ответить asap.

Не забывайте подписываться на наш Хаб, у нас запланировано огромное количество статей на тему бэкапа и восстановления данных, быть может, именно наши статьи помогут вам решить определённые проблемы (а лучше — избежать их). Спасибо за внимание. :)

Моментальный снимок (Snapshot) – это блочная или файловая копия диска (тома/раздела) физических или виртуальных систем, выполняемая без остановки служб, включающая папки, файлы и информацию о состоянии системы на определенный момент времени. Snapshot не является резервной копией, а служит как временный источник для создания согласованных резервной копии. Применяют для объемных баз данных или файловых систем работающих в непрерывном режиме 24 на 7.

Плюсы моментальных снимков (snapshots)

Высокая производительность
Минимальное влияние на доступность данных и работу системы
Полное восстановление системы

Минусы моментальных снимков (snapshots)

Не является резервной копией
Имеет сложности при создании согласованного снимка приложений и баз данных
Выделение места на диске для временного хранения Snapshot (-а)

ПРОЦЕСС СОЗДАНИЯ МОМЕНТАЛЬНЫХ СНИМКОВ (CREATE SNAPSHOT)

В зависимости от источника хранения данных (файловая система, менеджер дисков/томов или дисковый массив) для создания моментальных снимков применяют алгоритм «Копирования при записи» (Copy-on-write) или «Перенаправления при записи» (Redirect-on-write), иногда его так же называют «Зеркальный снимок».
Упрощенно процесс создания моментальных снимков файловой системы состоит из следующих этапов:

Сбор метаданных и подготовка к созданию теневой копии (завершение транзакции и очистка кэша)
Временная остановка (заморозка) запросов на запись операций ввода-вывода в файловую систему. Перевод в состояние только чтение.
Создание и запись теневой копии в хранилище
1. На том же томе для Copy-on-write
2. На другом томе для Redirect-on-write
В процессе создания снапшота важную роль играет поставщик моментальных снимков (Snapshots Provider). В зависимости от инициатора, поставщиков делят на Hardware и Software Provider.

Snapshot Provider

Hardware Provider это утилита в составе системы хранения данных, которая выступает инициатором создания снапшота от имени поставщик оборудования. Каждый Provide моментальных снимков предназначен для определенной подсистемы. Provide действует в качестве посредника между службой теневого копирования томов и «железом», работая в связке с сетевым адаптером и контроллером хранения данных. Таким образом, нагрузка по созданию и поддержке теневой копии лежит на массиве хранения данных.

В случаи программного снимка (Software Provider) программа-инициатор на системном уровне перехватывает запросы чтение / запись для операций ввода / вывода между файловой системой и менеджером томов. В Windows роль Software Provider, как правило, выполняет встроенная системная служба VSS, в Linux системах ….

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

SNAPSHOT WINDOWS

Snapshot в системах резервного копирования

В системах Windows моментальными снимками принято считать теневые копии сделанные службой теневого копирования (Volume Shadow Copy Service - VSS). VSS по умолчанию встроена в систему Windows и отвечает за создание Snapshots на уровне файловой системы NTFS, применяя метод «Копирования при записи». VSS используется, как для физических систем, так и для виртуальных машин Hyper-V, включая файлы конфигурации виртуальных машин, состояние системы (system snapshot) и виртуальные жесткие диски (VHD). Как правило, большинство программ/систем резервного копирования используют службу VSS для создания теневых копий Windows.

SNAPSHOT LINUX

Для Linux систем единой универсальной технологии создания моментальных снимков нет, в зависимости от типа файловой системы (EXT, JFS, ReiserFS, XFS, Btrfs) используют различные модули ядра Linux или менеджер логический томов LVM.

Читайте также: