Насколько я понимаю, механизм InnoDB состоит в том, что базу данных всегда можно восстановить после сбоя из-за внутренней архитектуры самого движка. То есть InnoDB может правильно восстановиться после сбоя согласованного состояния. Т.е. если питание отключено.
С другой стороны, при создании моментального снимка виртуальной машины в vSphere распространенная в Интернете мудрость гласит, что резервное копирование будет устойчивым к сбоям, но может вызвать повреждение базы данных InnoDB, если виртуальная машина не будет приостановлена. Это кажется несовместимым с вышеизложенным.
Tldr; действительно ли InnoDB может восстанавливаться после сбоя согласованного состояния, и если да, то не должно ли создание снимков виртуальной машины без стабилизации быть безопасным методом резервного копирования?
Никогда не предполагайте, что что-то всегда можно восстановить и согласовать!
Восстановление файловой системы после сбоя не обязательно означает, что ваши файлы не повреждены. Может быть потеряно (надеюсь, небольшое) количество незафиксированных записей файловой системы. В худшем случае метаданные становятся несовместимыми, и fsck возвращает файловую систему, но может потерять файлы. Это также относится к журналам вашей базы данных, что в зависимости от цели вашей точки восстановления может быть проблематичным.
Согласованность файлов - более сильное утверждение: файлы находятся в стабильном состоянии. fsck уже должен быть чистым. Несколько способов сделать это: инструменты VMware vmsync, моментальные снимки Linux LVM или fsfreeze, Windows VSS.
Даже файлы в определенный момент времени не подразумевают согласованности приложений. База данных будет иметь обновления в памяти, не записанные на диск. И новые обновления всегда происходят в работающей системе. В идеале очистить базу данных от записи на диск и приостановить дальнейшую запись до тех пор, пока не будет сделан моментальный снимок уровня хранилища.
Или, конечно, можно сделать несогласованную резервную копию и больше полагаться на журналы для восстановления. Это немного усложняет создание резервной копии для ее восстановления.
До сих пор я предполагал резервное копирование на уровне хранилища, основываясь на выбранных вами снимках состояния хранилища. При более полной оценке методов резервного копирования рассматриваются как логические дампы, так и физические необработанные файлы. MariaDB's Краткое руководство по технологиям резервного копирования сравнивает несколько реализаций каждого. Например, посмотрите, как mylvmbackup выполняет сброс и снимок, и как XtraBackup выполняет восстановление журнала повторов.
Конечно, резервное копирование без восстановления бессмысленно. Всегда делайте тест восстановления. При этом проверьте точку восстановления: какие данные были восстановлены последними?