Checkpoint’ы (ранее Snapshots) предназначены для быстрого возвращения виртуальной машины к одному из предыдущих состояний.

“Предыдущее состояние” включает в себя содержимое vHDD, vRAM и конфигурации ВМ.

Максимальное количество Checkpoint’ов (далее CP) – 50. При попытке сделать 51й CP вы получите такую ошибку:

По-умолчанию, в Windows Server 2012R2 CP хранятся в папке %systemroot%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots

Вы можете изменить расположение из консоли Hyper-V:

Когда вы создаёте CP работающей VM, в этой папке будет создан .xml файл с конфигурацией VM и подпапка в которой будут сохранены файлы .bin и .vsv – так называемые Saved State files.

Если вы делаете CP когда VM выключена,  Saved State файлы созданы не будут.

Разностный VHD(X) будет создан в той же паке где находится “родительский” VHD(X).

Имена .xml , .bin , .vsv , .avhd(x) и подпапки будут соответствовать GUID’y Checkpoint’a.

И если имя .avhdx относительно читабельно:

То имена папок со Snapshots (обратите внимание, папки до сих пор называются по-старому) уже неочевидны:

Узнать GUID Checkpoint’a можно с помощью PowerShell (обратите внимание, снова используется старый термин Snapshots):

Get-VMSnapshot -VMName %name% | Select id,name

В процессе создания Checkpoint для включённой VM происходит следующее:

1. Виртуальная машина ставится на паузу
2. Создаётся .avhd(x) файл
3. Сохраняется резервная копия конфигурации (.xml)
4. В конфигурацию вносятся изменения (подключается .avhdx файл)
5. Виртуальная машина запускается
6. Содержимое RAM сохраняется в Saved state файлы. Если в это время ОС пытается произвести запись в блоки RAM которые ещё не были сохранены, запросы перехватываются и результаты сохраняются.
7. Checkpoint готов.

Пауза на шаги 1-5 действительно небольшая:

А вот сохранение содержимого ОЗУ в Saved state файлы и занимает основное время.

Процессы применения и удаления Checkpoint’ов я думаю интуитивно понятны, поэтому пойдём дальше.

Экспорт Checkpoint – одна из редко используемых, но действительно полезных функций.

Вы можете сделать экспорт CP, а затем импортировать его на другом хосте.

При этом имя импортированной VM будет соответствовать имени CP:

Вы можете автоматизировать создание CP запуская что-то подобное из Task Scheduler:

Get-VM %vm1%,%vm2%,%vmN% | Checkpoint-VM

Если вы хотите использовать более “говорящие” имена, воспользуйтесь возможностями SnapshotName, вот пример для ежедневных:

-SnapshotName "Daily Snapshot $((Get-Date).ToShortDateString())"

.. и ежечасных Checkpoint’ов:

-SnapshotName "Hourly Snapshot $((Get-Date).ToShortTimeString())"

Выглядит это следующим образом:

Автоматически удалять Checkpoint’ы можно вот так (в примере я удаляю те, которые старше 5 дней):

Get-VMSnapshot -VMName %vm1%,%vm2%,%vmN%| Where-Object {$_.CreationTime -lt (Get-Date).AddDays(-5) } | Remove-VMSnapshot

Вот пример командлета, который удалит Checkpoint’ы которые старше одного часа:

Get-VMSnapshot -VMName %vm1%,%vm2%,%vmN%| Where-Object {$_.CreationTime -lt (Get-Date).AddHours(-1) } | Remove-VMSnapshot

Но не всегда время создания Checkpoint’a является фактором на основе которого принимается решение об удалении.

Например, вам может понадобится удалить все Checkpoint’ы в имени которых содержится test, но оставить все остальные, не зависимо от их возраста:

Get-VMSnapshot -VMName %vm1%,%vm2%,%vmN% | Where-Object {$_.Name -like "test*" } | Remove-VMSnapshot

Давайте подведём итоги:

1. CP снижают производительность не только дисковой подсистемы VM, но и производительность хранилища – причём чем больше CP, тем больше снижается производительность;
2. Создание CP для VM в выключенном состоянии предпочтительнее, т.к. Во-первых не будет расходов места на запись RAM, а во-вторых при откате на CP “чистая” загрузка VM предпочтительнее;
3. Чем больше  VM использует RAM, тем желательнее делать ее CP в выключенном состоянии;
4. После восстановления CP сетевые соединения VM будут также сброшены, поэтому чем выше сетевая нагрузка VM, тем желательнее делать CP в выключенном состоянии;
5. Если CP создаются для не выключенных VM, их лучше разместить на том же хранилище на котором расположены .vhd(x) файлы этих VM;
6. Если VM работает в связке с другими VM (например AD DS и Exchange) то делать CP и восстанавливать нужно всю связку;
7. CP не заменяют резервные копии, кроме сценария когда CP экспортируются;
8. Начиная с Windows Server 2012 CP можно применять для контроллеров домена, за счёт использования VM-GenerationID.

Теперь, когда, как я надеюсь, вам понятна техническая сторона Checkpoint’ов разберёмся в каких случаях будем их применять, а в каких нет.

• В средах, где нужно гарантировать и SLA, и функциональность Checkpoint’ов нужно предусмотреть это на этапе проектирования хранилища.
• Для лабораторных задач и тестирования CP достаточно удобны, но не забывайте делать CP для всех “жёстко” связанных VM.
• В нормальной продуктивной среде необходимости в Checkpoint’ах быть не должно. Описание грамотного процесса управления внесением изменений в продуктивную среду выходит за рамки этой статьи, но вы можете сделать CP, экспортировать их и импортировать в изолированную тестовую среду для проверки изменений, которые  вы собираетесь вносить в продуктивную среду.

В любом случае, CP лучше делать когда VM выключены.

Официальный материал на TechNet – https://technet.microsoft.com/ru-ru/library/dn818483.aspx