MySQL tiene una reputación de recuperación insuficiente de estados de disco inconsistentes, XFS esencialmente pausa IO en el sistema de archivos mientras se lleva a cabo la instantánea. Normalmente, una base de datos realiza un flush() una vez que se ha creado una entrada de registro de transacciones completa que indica esencialmente un punto de control para el sistema de archivos. En el caso de un sistema de archivos de diario, esto es importante, y en su mayor parte, el sistema de archivos se recuperará hasta la última entrada de diario válida una vez montado, esto no es 100%, pero es mejor que nada. La mayoría de los sistemas de bases de datos usan el archivo de registro de transacciones para "avanzar" en la recuperación si los archivos de la base de datos están detrás de los registros de transacciones, y el motor de base de datos solo avanzará tanto como sea posible dado el contenido de los registros de transacciones. No intentará avanzar a través de una transacción parcialmente escrita. El problema aquí es que MySQL no es el mejor para lograr eso, por lo que puede ser un problema. No he encontrado una solución sólida para esto, me imagino que ejecutar un espejo, pausar MySQL mientras haces la instantánea y luego reanudar la sincronización podría funcionar, pero no sé si el espejo de MySQL puede hacer frente a un espejo que no está parcialmente disponible para un tiempo y luego ser capaz de ponerse al día sin un re-mirror completo, en cuyo caso, también podría hacer un mysqldump de todas las bases de datos ya que tendría el mismo efecto en la base de datos que ejecutar un mirror completo. Esa es la otra opción que se ejecuta mientras se me ocurre, para ejecutar un mysqldump de todas las bases de datos a una partición de respaldo y una instantánea. No le da copias de seguridad en ejecución, por lo que no puede hacerlo a menudo, y si tiene 24 horas al día, 7 días a la semana, mysqldump pone una gran carga en la base de datos mientras se ejecuta, lejos de ser óptima.
Otro motor de base de datos es mucho mejor en esto. PostgreSQL es muy bueno para recuperarse de un estado de disco incosistente hasta el punto de que no recomiendan ejecutarlo en un sistema de archivos en conjunto. También tiene la opción de archivar los registros de transacciones para que pueda avanzar desde la última copia de seguridad completa hasta cualquier punto en el que existan los registros archivados. Mucho más fácil hacer copias de seguridad consistentes con esto. Oracle le permitirá tener múltiples conjuntos de registros de transacciones que cambian entre discos físicos/particiones EBS, lo que le brinda ventanas frecuentes para tomar una instantánea consistente y la capacidad de indicar al motor de la base de datos que desea hacer esto, y no voltear de vuelta hasta que lo diga.
A lo largo de la línea de pensamiento diario, LVM tiene la capacidad de capturar instantáneamente todo el sistema de archivos en menos de un segundo. No sé si la funcionalidad de instantáneas de EBS se aprovechará de esto, aunque podría hacerlo manualmente. LVM es un poco más complicado que XFS, pero he tenido problemas con XFS en el pasado creando gran cantidad de archivos en un solo directorio donde ext3 estaba bien. LVM también tiene otros beneficios, y definitivamente vale la pena considerarlos de cualquier manera.
-1 . No responde la pregunta. – talonx