Есть два разных снимка.
1. снимок ФАЙЛОВОЙ системы (Production Checkpoints у hyper-v)
2. снимок файловой системы и ОПЕРАТИВНОЙ памяти (standart)
Второй способ подразумевает возможность возобновления работы приложения без его перезапуска (только открытые сетевые соединения будут прерваны), первый же возобновление работы с перезапуском операционной системы и его приложений.
Для любого работающего приложения первый способ в момент восстановления равносилен нажатия reset компьютера. Для баз данных это не штатный способ работы и существует вероятность получить какой либо сбой с данными (на самом деле львиная доля усилий, из-за которых базы данных такие медленные, это попытка дать гарантии что завершенные транзакции останутся в сохранности и в опасности только незавершенные (а в идеологии транзакционных баз данных, такие транзакции могут быть отменены и приложения должны корректно это обрабатывать).
Второй же способ по сути прозрачен для приложений, единственное что напомнит о себе - это таймеры времени, но на сколько я знаю, базы данных не критичны к их резким изменениям (за исключением приложения, которое может быть написано таким образом что не ожидает резких скачков времени, но это не проблема самой базы).
Так же нужно помнить, что снапшоты оперативной памяти корректно будут работать только если оборудование не проброшено физически внутрь, т.е. виртуальная машина корректно будет восстанавливать только виртуальные диски, а какой-нибудь контроллер с диском, проброшенный внутрь, останется в последнем состоянии и не откатится назад... То же самое для внешних сетевых дисков и iscsi, их состояние так же останется последним. Так вот размещать файлы базы данных (тем более смешивать, часть на виртуальном диске а часть на сетевом) на таких дисках и делать снапшоты категорически нельзя, почти с гарантией получишь испорченную базу данных, которую даже восстановить нормально не получится.
p.s. если перед созданием снапшота сервер базы данных остановить, то проблем никаких это не создаст.
Простой
Средний
