Todos sabemos que las copias de seguridad deben programarse periodicamente. Las copias completos (una captura del estado de los datos en un momento del tiempo) puede hacerse con diferentes herramientas, en MySQL. Por ejemplo, InnoDB Hot Backup nos provee con una copia de seguridad en línea sin bloqueos de los archivos de datos de InnoDB, y con mysqldump obtenemos copias de seguridad lógicas online. En esta explicación utilizaremos mysqldump.

Supongamos que hacemos una copia de seguridad el domingo, a las 1 PM, cuando la carga es baja. El siguiente comando hace un hace una copia de seguridad completa de todas nuestras tablas InnoDB de todas las bases de datos:

shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql

Esto es una copia de seguridad en línea, sin bloqueos, que no molesta a las lecturas y escrituras de las tablas. Hemos supuesto antes que nuestras tablas son InnoDB, así que --single-transaction hace una lectura consistente y garantiza que los datos vistos por mysqldump no cambian. (Los cambios hechos por otros clientes a las tablas InnoDB no son vistas por el proceso mysqldump.) Si también tenemos otros tipos de tablas, debemos suponer que no han sido cambiadas durante la copia de seguridad. Por ejemplo, para las tablas MyISAM en la base de datos mysql, debemos suponer que no se estaban haciendo cambios administrativos a las cuentas MySQL durante la copia de seguridad.

El archivo .sql resultante producido por el comando mysqldump contiene una serie de sentencias SQL INSERT que se pueden utilizar para recargar las tablas volcadas más tarde.

Las copias de seguridad completas son necesarias, pero no son siempre convenientes. Producen ficheros muy grandes y llevan tiempo generarse. No son óptimos en el sentido de que cada copia completa sucesiva incluye todos los datos, incluidas las partes que no han cambiado desde el último. Después de realizar una copia de seguridad completa inicial, es más eficiente hacer copias incrementales. Son más pequeñas, y llevan menos tiempo de realización. A cambio, en el momento de la recuperación, no podrá restaurarlo únicamente recargando la copia completa. También deberá procesar las copias incrementales para recuperar los cambios incrementales.

Para hacer copias de seguridad incrementales, necesitamos guardar los cambios incrementales. El servidor MySQL debería ser iniciado siempre con la opción --log-bin para que almacene estos cambios en un archivo mientras actualiza los datos. Esta opción activa el registro binario, así que el servidor escribe cada sentencia SQL que actualiza datos en un archivo lllamado registro binario de MySQL. Miremos al directorio de datos de un servidor MySQL que fue iniciado con la opción --log-bin y que se ha estado ejecutando durante algunos días. Encontramos estos archivos de registro binario:

-rw-rw---- 1 guilhem  guilhem   1277324 Nov 10 23:59 gbichot2-bin.000001
-rw-rw---- 1 guilhem  guilhem         4 Nov 10 23:59 gbichot2-bin.000002
-rw-rw---- 1 guilhem  guilhem        79 Nov 11 11:06 gbichot2-bin.000003
-rw-rw---- 1 guilhem  guilhem       508 Nov 11 11:08 gbichot2-bin.000004
-rw-rw---- 1 guilhem  guilhem 220047446 Nov 12 16:47 gbichot2-bin.000005
-rw-rw---- 1 guilhem  guilhem    998412 Nov 14 10:08 gbichot2-bin.000006
-rw-rw---- 1 guilhem  guilhem       361 Nov 14 10:07 gbichot2-bin.index

Cada vez que se reinicia, el servidor MySQL crea un nuevo archivo de registro binario utilizando el siguiente número en la secuencia. Mientras el servidor se está ejecutando, podemos comunicarle manualmente que cierre el archivo de registro binario actual y comience otro nuevo, ejecutando la sentencia SQL FLUSH LOGS o con el comando mysqladmin flush-logs. mysqldump también tiene una opción para volcar los logs. El archivo .index en el directorio de datos contiene la lista de todos los archivos de registro binario de MySQL en el directorio. Este archivo se utiliza para replicación.

El registro binario de MySQL es importante para la restauración, porque son copias incrementales de datos. Si se asegura de volcar los registros cuando hace su copia de seguridad completa, entonces cualquier registro binario creado tras esa copia contiene todos los cambios hechos desde entonces. Modifiquemos el comando mysqldump previo un poco para que vuelque los registros binarios de MySQL en el momento de la copia de seguridad completa, y para que el archivo de volcado contenga el nombre del registro binario actual:

shell> mysqldump --single-transaction --flush-logs --master-data=2
           --all-databases > backup_sunday_1_PM.sql

Tras ejecutar este comando, el directorio de datos contiene un nuevo archivo de registro binario, gbichot2-bin.000007. El archivo .sql resultante contiene estas líneas:

-- Position to start replication or point-in-time recovery from
-- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;

Como el comando mysqldump ha hecho una copia de seguridad completa, estas líneas significan dos cosas:

El lunes, a las 1 PM, podemos crear una copia de seguridad incremental volcando los registros para comenzar un nuevo registro binario. Por ejemplo, ejecutando un comando mysqladmin flush-logs creamos gbichot2-bin.000008. Todos los cambios producidos entre el domingo a la 1 PM cuando se hizo la copia completa, y el lunes a la 1 PM están en el archivo gbichot2-bin.000007. Esta copia incremental es importante, así que es una buena idea copiarla a un lugar seguro. (Por ejemplo, en cinta o DVD, o copiándolo a otra máquina.) El martes a la 1 PM, ejecute otro comando mysqladmin flush-logs. Todos los cambios desde el lunes a la 1 PM hasta el martes a la 1 PM están en el archivo gbichot2-bin.000008 (que también debería ser copiado a un lugar seguro).

Los registros binarios de MySQL ocupan espacio de disco. Para ligerar espacio, púrguelos de vez en cuando. Una manera de hacerlo es borrar los registros binarios que no se necesiten, como cuando hacemos una copia de seguridad completa:

shell> mysqldump --single-transaction --flush-logs --master-data=2
           --all-databases --delete-master-logs > backup_sunday_1_PM.sql

Tenga en cuenta que: Borrar los registros binarios de MySQL con mysqldump --delete-master-logs puede ser peligroso si su servidor es un servidor maestro de replicación, porque los servidores esclavos pueden no haber procesado completamente los contenidos del registro binario.

La descripción de la sentencia PURGE MASTER LOGS explica lo que debe ser verificado antes de borrar los registros binarios de MySQL. Consulte Sección 13.6.1.1, “Sintaxis de PURGE MASTER LOGS”.