Respaldo y restauración

1. Introducción

¿Cuántas veces hemos perdido datos y nos hemos dado cuenta de que no existía ningún medio de recuperarlos? Es el riesgo que cualquier administrador corre cuando no se toma el tiempo de implementar una política de protección adecuada. En efecto, algunos creen que al establecer una replicación entre dos servidores MySQL quedan protegidos de una pérdida o corrupción de datos, pero no es así. Un fallo en las operaciones en uno de los servidores, y lo perderán todo. ¡No haga como ellos!

Del mismo modo, no se puede estar seguro de recuperar los datos mientras no se ha probado el procedimiento de restauración. Haber guardado sus datos es una buena idea, pero si el procedimiento de restauración no ha sido debidamente probado y validado, esto no servirá de gran cosa. Este capítulo tiene por objeto familiarizarnos con los conceptos inherentes al respaldo y presenta los distintos medios disponibles que nos permitirán llegar a la solución más conveniente.

Recuerde guardar los archivos de configuración. El comportamiento de la base de datos puede cambiar por completo (rendimiento, generación de los archivos binarios...) si no utilizamos después de la restauración los mismos parámetros que hemos usado para el respaldo. Esto también puede ser el caso de la configuración de los sistemas de archivos. Por ejemplo, en Linux tenemos la posibilidad de desactivar la actualización de las fechas de acceso (parámetro mtime para ext2/ext3) en los archivos de la base de datos que resultan inútiles para su correcto funcionamiento. Se trata, en la medida de lo posible, de guardar las partes de su entorno que influyen en el funcionamiento de la base de datos. De esta forma, durante la restauración evitaremos sorpresas.

La frecuencia de los respaldos, la duración de retención de los registros binarios (binlogs) y la frecuencia de sincronización de archivos de respaldo en servidores remotos deben estar en consonancia con la pérdida de datos máxima admisible (RPO, Recovery Point Objective). En efecto, si el RPO es de dos horas, no tenemos activados los registros binarios y estamos haciendo una copia de seguridad diaria, en caso de un crash que ocurra cuatro horas después del respaldo, no podremos...

1. Importación/exportación manual

MySQL permite exportar el resultado de una petición en un archivo, que se almacena en el servidor, cuando el usuario tiene el privilegio FILE. Este método es más rápido para importar/exportar el contenido de una tabla que una copia de seguridad SQL, ya que no es necesario interpretar o generar las órdenes SQL.

Para ello, tenemos el comando SELECT ... INTO OUTFILE que respeta el formato siguiente:

SELECTcol1,col2,... INTO OUTFILE 'nombre_archivo' 
FIELDS TEMINATED BYcadena1OPTIONNALY ENCLOSE BYcadena2  
LINES TERMINATED BY cadena3FROM nombre_de_tabla.
 

con:

Así, la siguiente petición exporta todos los datos de la tabla actor:

mysql> SELECT * FROM actor INTO OUTFILE '/var/tmp/actor.txt';   
Query OK, 200 rows affected (0.02 sec)
 

Cuando el comando termina, se encuentra el contenido de la tabla en el archivo /var/tmp/actor.txt, los valores se separan por tabuladores y los valores NULL se sustituyen por \N. El tamaño y el formato del archivo actor.txt permiten una operación más simple que la salida SQL que se habría obtenido con mysqldump.

En efecto, en UNIX/Linux, podemos utilizar los comandos de sistema basados en expresiones regulares para contar un número de apariciones.

shell> awk -F"\t" '/PENELOPE/ {print $2}' /var/tmp/actor.txt |uniq  
-c   
    4 PENELOPE
 

O modificar un apellido:

shell> sed -i 's/PENELOPE/JENNY/' /var/tmp/actor.txt   
shell> grep -c JENNY /var/tmp/actor.txt   
4
 

Con la salida de mysqldump, habríamos necesitado abrir el archivo de export y editarlo de forma manual, o desactivar la opción extended-insert para solo obtener inserciones unitarias y facilitar la modificación utilizando los comandos shell.

No obstante, ya no debe existir el archivo de salida, en cuyo caso el comando fracasa y el archivo...