10 cosas que preguntarte sobre tus respaldos en MySQL

Baron Schwartz ha escrito 10 excelentes puntos a considerar al elegir un sistema de respaldos con MySQL. Una excelente lectura y no solo una odiosa lista más.

Me tomo la libertad de robarlo traducirlo aquí:

1. ¿Requiere apagar MySQL? si no, cual es el impacto en el servidor que ya esta corriendo? ¿bloqueo? ¿carga I/O? ¿cache?
2. ¿Cuál es la técnica utilizada para el respaldo? Es mysqldump o un producto personalizado que hace algo similar? ¿Es una copia de archivos?
3. ¿El sistema de respaldo entiende que no se puede respaldar InnoDB simplemente copiando sus archivos?
4. ¿El respaldo utiliza FLUSH TABLES, LOCK TABLES o FLUSH TABLES WITH READ LOCK? Todos ellos interrumpen el procesamiento.
5. ¿Que otros efectos tiene en MySQL? He visto sistemas que hacen un RESET MASTER, el cual inmediatamente rompe la replicación. ¿Utiliza otros comandos de FLUSH como FLUSH LOGS?
6. ¿Como garantiza que puedes realizar una recuperación point-in-time?
7. ¿Como garantiza consistencia con el log binario, log de InnoDB y replicación?
8. ¿Puedes utilizarlo para configurar nuevos esclavos de replicación? ¿Cómo?
9. ¿Verifica que el respaldo es utilizable? i.e. ¿Ejecuta una recuperación InnoDB antes de declarar un respaldo como exitoso?
10. ¿Alguien esta detrás de el con soporte, y garantía de respaldos funcionables y recuperables? ¿Qué tan fuerte es la garantía legal y cuanto seguro tienen?

Personalmente utilizo Zmanda, pero hay muchas opciones disponibles para automatizar respaldos y no confiarte solamente de tus scripts que ejecutan mysqldump.