MySQL имеет репутацию плохого восстановления из-за несовместимого состояния диска, XFS, по сути, приостанавливает ввод-вывод в файловую систему, пока происходит моментальный снимок. Обычно база данных выполняет flush () после создания полной записи в журнале транзакций, которая, по сути, указывает на контрольную точку для файловой системы. В случае журналируемой файловой системы это важно, и по большей части файловая система восстановится до последней действительной записи журнала после монтирования, это не 100%, но это лучше, чем ничего. Большинство систем баз данных используют файл журнала транзакций для «отката» при восстановлении, если файлы базы данных находятся за журналами транзакций, и механизм базы данных будет выполнять откат только настолько, насколько это возможно с учетом содержимого журналов транзакций. Он не будет пытаться откатиться через частично написанную транзакцию. Проблема здесь в том, что MySQL не является лучшим в достижении этого, поэтому это может быть проблемой. Я не нашел надежного решения для этого, я хотел бы представить себе запуск зеркала, приостановка MySQL, пока вы делаете снимок, а затем возобновить синхронизацию может работать, но я не знаю, может ли зеркало MySQL справиться с тем, что зеркало частично недоступно для Некоторое время, а затем сможете наверстать упущенное без полного переотражения, и в этом случае вы можете просто выполнить mysqldump для всех баз данных, поскольку это будет иметь примерно такой же эффект для базы данных, как и запуск полного зеркала. Это еще один вариант работы, который я могу придумать - запустить mysqldump всех баз данных в резервном разделе и сделать снимок. Не дает вам выполнять резервное копирование, поэтому вы не можете делать это часто, и если вы работаете круглосуточно, mysqldump сильно загружает базу данных во время ее работы, что далеко от оптимального.
Другие движки баз данных намного лучше в этом. PostgreSQL очень хорош в восстановлении состояния диска, когда он вообще не рекомендует запускать его в журнализированной файловой системе. У вас также есть возможность архивировать журналы транзакций, чтобы вы могли выполнить откат от последней полной резервной копии до любого момента времени, когда существуют архивированные журналы. Гораздо проще сделать последовательные резервные копии с этим. Oracle позволит вам иметь несколько наборов журналов транзакций, которые переключаются между физическими дисками / разделами EBS, давая вам частые окна для создания непротиворечивого снимка и возможность указать ядру базы данных, что вы хотите сделать это, и не переворачивать пока не скажешь.
В рамках общепринятого мышления LVM имеет возможность сделать снимок всей файловой системы обычно за секунду. Я не знаю, воспользуется ли эта функция моментальным снимком EBS, хотя вы могли бы сделать это вручную. LVM немного сложнее, чем XFS, но в прошлом у меня были проблемы с XFS, из-за чего большое количество файлов находилось в одном каталоге, где ext3 был в порядке. У LVM также есть множество других преимуществ, и определенно стоит посмотреть в любом направлении.