Recuperar datos es una de esas actividades que consisten en un largo periodo de marrón, coronado (a veces) por un momento de euforia.
Vamos a correr un tupido velo sobre la historia que llevó al punto de partida de nuestro marrón de hoy. Describamos, simplemente, dicho punto de partida: Hay un contenedor OpenVZ corriendo en un servidor, en el cual «se» (¿no son utilísimos los reflexivos en las empresas?) ha hecho un DROP DATABASE seguido del nombre de una base de datos. Base de datos de la que no solamente no hay copia de los datos; sino que, puestos a giñarla, tampoco la hay de la estructura.
Así a primera vista, después de los preceptivos frontomanotazos y pelotiramientos, quedaron dos cosas claras:
- Para recuperar una tabla MyISAM (las InnoDB son otra historia), se necesitan al menos su .frm (estructura) y .MYD (datos propiamente dichos). Si solo se tienen los datos, ahí están, pero usarlos es un trabajo más bien de chinos.
- Cuanto más tiempo pase y más se escriba en el volumen afectado, mucho peor.
El primer intento, que tenía posibilidades de no haber pasado ya unas horas en un hipervisor un tanto activo, fue con ext4magic. Tiene su cosa, el asunto. Si el servidor se puede parar, es más fácil. Si no, hay que trabajar haciendo una copia del journal del sistema de ficheros, en este caso un ext4:
debugfs -R "dump <8> /root/copiadeljournal" /dev/mapper/pve-data
En este caso, almacenamos la copia del journal en /root, y el sistema de ficheros conteniendo lo que deseamos recuperar está en /dev/mapper/pve-data. Un Proxmox, como habrá adivinado ya el lector avezado.
Luego, burguesamente, podemos pedir a ext4magic que nos recupere todo lo del directorio en cuestión:
./ext4magic /dev/mapper/pve-data -j /root/copiadeljournal -f private/666/var/lib/mysql/pordiosmibasededatos -a $(date -d "-5day" +%s) -b $(date -d +%s) -R
En este caso, «666» es el identificador del contenedor. No es coincidencia; es que uno es así de paranoico filtrando lo que publica.
Pero claro… Si ha pasado tiempo, dependiendo de exactamente lo que se le pida, dice que el inodo ya está siendo reutilizado, o que simplemente aquello ya no ta.
Otro intento fue con testdisk. Testdisk es un gran invento, pero en este caso hubo el mismo problema: Había pasado demasiado tiempo. Mejor dicho: Demasiadas escrituras.
¿Qué hacer, qué hacer? El datario amenazaba alternativamente con suicidarse y con homicidar al causante del desaguisado; se seguían sucediendo el tiempo y las escrituras, y no estábamos más cerca de una solución que al principio.
Llamé a mi escriptillo, un tanto gráficamente, aladesesperada.sh. Era este:
#!/bin/bash
Bloque=0
while [ $Bloque -le 157313 ]
do
echo " $Bloque "
dd if=/dev/mapper/pve-data of=/root/tmp-$Bloque bs=10M skip=$Bloque count=1 status=noxfer > /dev/null
grep -q 'cadenapeculiarquetepasas' /root/tmp-$Bloque
if [ $? -eq 0 ]; then
echo Encontrado algo
else
rm /root/tmp-$Bloque
fi
Bloque=$[$Bloque +1]
done
No me darán un premio a la elegancia, pero esto es como funciona. El numerete es simplemente el tamaño de la partición donde estamos recuperando los datos expresada en cachos de 10 megas. Luego, simplemente vamos cogiendo cachitos de 10 megas en 10 megas y, si algún cachito contiene una cadena que sabemos que está en la base de datos, la conservamos. Si no, la borramos.
Luego hice una pequeña reforma que multiplicó por varias veces la velocidad de ejecución, usando un tmpfs:
mount -t tmpfs -o size=20m tmpfs /root/tmp
Y correspondientemente:
#!/bin/bash
Bloque=0
while [ $Bloque -le 157313 ]
do
echo " $Bloque "
dd if=/dev/mapper/pve-data of=/root/tmp/tmp-$Bloque bs=10M skip=$Bloque count=1 status=noxfer > /dev/null
grep -q 'cadenapeculiarquetepasas' /root/tmp/tmp-$Bloque
if [ $? -eq 0 ]; then
mv /root/tmp/tmp-$Bloque /root/encontrado-$Bloque
else
rm /root/tmp/tmp-$Bloque
fi
Bloque=$[$Bloque +1]
done
Con esto, vino uno de esos escasos y preciados momentos de suspiro: Aparecieron los datos. Al menos, la mayoría de ellos. Hubo que hacer varios intentos, concatenar varios cachos y recortarlos a base de dd, pero al final aparecieron.
Pero hay un problema, ¿no? ¿Qué hemos dicho sobre las tablas MyISAM?
al menos su .frm (estructura) y .MYD (datos propiamente dichos)
Total. Que necesitamos recuperar del disco unos .frm, que como cadena para buscar solamente tienen unos nombres de campo… Nada peculiares. Y encima, tienen un formato tirando a complejo y ni siquiera del todo bien documentado.
Así que, para esto, echamos mano del amigo de testdisc: Photorec.
Photorec es una pequeña maravilla de recuperador de datos. No poca gente debe algo parecido al perdón divino de su falta de copias de seguridad a esta utilidad escrita y mantenida desde hace muchos años por Christophe GRENIER. Photorec busca a lo bruto y recupera un montón de formatos de ficheros; entre ellos, los frm de MyISAM.
Dicho y hecho, una ejecución rápida de Photorec en el volumen pronto encontró varios archivos de MySQL. Varios. Unos pocos… Miles. Mêrde. Y ahora, ¿qué?
Pues se coge ./aladesesperada.sh buscando por los nombres de los campos (lo cual genera «solamente» unos cientos de ficheros de a diez megas), y seguidamente… Corremos photorec sobre la concatenación de todos esos ficheros.
Eso y un poco de recortes más con dd, algo de ensayo y error, y ¡por fin!. Poner los ficheros finales en /var/lib/mysql, usuarios, permisos, arrancar el servidor (no harás todo esto con el servidor MySQL andando, ¿verdad?), y no sin quejarse un poco…
mysql> REPAIR TABLE tablon USE_FRM;
+----------------+--------+----------+----------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+----------------+--------+----------+----------------------------------------------------------------+
| basedepatos.tablon | repair | info | Found link that points at xxxxx (outside data file) at yyyyy |
[…]
| basedepatos.tablon | repair | warning | Number of rows changed from 0 to 4711 |
| basedepatos.tablon | repair | status | OK |
Como dicen, el resto es historia: Intentar recoger los cachitos que faltan, y hacer un mysqldump final y largarlo al dueño, que ya a estas alturas estaba pensando en un duelo a pistola a tres pasos.
Comentarios recientes