Catástrofes de MySQL, y replanteando los backups

¡Qué he borrado!

Hace poco tuve que corregir tablas de MySQL estropeadas en este servidor, y el otro día volvió a pasar (no sé porqué, el uptime indicaba que no se había reiniciado la máquina recientemente).

Me puse a arreglarlo, ya que sabía cómo, pero por el camino (por estar cansado) cometí un error fundamental que empeoró las cosas y, no hay mal que por bien no venga, eso me sirvió para darme cuenta de algunas cosas respecto a las copias de seguridad que hago :D.

En primer lugar hay un tema en el que siempre insisto, pero que este domingo pasado descuidé lamentablemente:

Cuando hagas rm * siendo root, siempre indica una ruta absoluta a lo que quieres borrar.

Evidentemente borré lo que no debía, eso ya se puede deducir sin más vueltas, pero... ¿cómo de malo es lo que borré? Bueno, no sabía las implicaciones, y ahora sí las sé :).

Resulta que mis víctimas eran dos ficheros tipo #sql_2aa1_0.MYD en /tmp/, pero en realidad me cargué el contenido de /var/mysql/blackshell/. Sí, eso mismo: toda la base de datos en disco. Parece que cuando meto la pata no me ando con tonterías :S.

Pero vamos: somos administradores de sistemas, ¿no? Esto es aparentemente malo, ¿pero cómo es de malo? La experiencia en el trabajo ya me ha enseñado muchas veces que el negro tiene muchas tonalidades :D.

Justo antes de la cagada™ había ejecutado el myisamchk, y las tablas estaban corregidas, con lo que tenía un mysqld corriendo con las tablas en memoria, pero... la base de datos ya no existía en disco.

Bueno, ni tan mal. Tenemos copia de seguridad... del 26 de Abril :S, con lo que perdería unas cuantas anotaciones y algunos comentarios. Algo mal sí estaba el tema :(.

Así que el objetivo estaba claro: conseguir restaurar a disco la base de datos que tiene mysqld en memoria.

Entonces es cuando viene realmente bien saber qué son los ficheros que... me he limpiado por accidente. Sabiendo que el backend es MyISAM, tenemos por cada tabla:

• Fichero frm: se usa con otros backends, y contiene información referente al modelo de datos (la descripción de la tabla, vamos).
• Fichero MYI: es específico de MyISAM, y contiene los índices de la tabla.
• Fichero MYD: también es específico de MyISAM, y contiene los datos propiamente dichos.

La clave para resolver mi problema, teniendo todos los datos en memoria, parecía ser un mysqldump, salvo por el detalle de que sin fichero frm (el modelo de datos), la herramienta no sabe qué volcar y nos da un resultado vacío.

Tampoco funcionará un SHOW TABLES o un DESC tabla, y sospecho que si mi bitácora accediera a los campos de las consultas por nombre de columna, tampoco funcionaría :D.

La solución fue fácil:

1. Coger todos los CREATE TABLE del dump, que es mi copia de seguridad del 26/04.
2. Crear una base de datos, por ejemplo recovery, con esos CREATE TABLE.
3. Vamos a /var/mysql/recovery/ y copiamos los ficheros frm a /var/mysql/blackshell/.
4. Hacemos un mysqldump de la base de datos en memoria (que ahora sí funcionará).
5. Entonces, y solo entonces, empezamos a respirar tranquilos desde que empezara todo el problema :D.

Lo siguiente que hice fue restaurar la base de datos (tras borrar la estropeada con un DROP DATABASE), para que MySQL generara esos ficheros que yo había... eso :D.

Y para terminar añadí los ficheros frm al backup, porque mi base de datos no es tan grande y no me importa regenerar todo desde un dump, pero igual sería buena idea guardar todos los ficheros.

¡Ah!, y yo me leería: How to Repair Tables. Aunque hemos visto que la opción de leer con prisas cuando surge el problema, a veces funciona ;).