Copia de seguridad y recuperación de MySQL con mysql-zrm en Debian Sarge - Página 4

6 Verifica tus copias de seguridad

Ahora queremos comprobar la integridad de nuestro conjunto de copias de seguridad dailyrun. Podemos hacerlo así:

mysql-zrm --action verify-backup --backup-set dailyrun

La salida debería verse así:

| Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305. INFO: mysql-zrm-version INFO: Verification successful |

(Puedes ignorar la advertencia en la primera línea, no es nada serio.)

A continuación, queremos comprobar una copia de seguridad específica dentro de nuestro conjunto de copias de seguridad dailyrun. Primero ejecutamos

mysql-zrm-reporter -show restore-full-info --where backup-set=dailyrun

para averiguar qué copias de seguridad están disponibles:

| backup_set backup_date backup_level backup_directory ---------------------------------------------------------------------------------------------------------- dailyrun Tue 26 Sep 2006 07:57:47 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195747 dailyrun Tue 26 Sep 2006 07:58:08 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195808 dailyrun Tue 26 Sep 2006 07:58:31 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195831 dailyrun Tue 26 Sep 2006 08:24:04 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926202404 |

Como puedes ver, hay cuatro copias de seguridad en nuestro conjunto de copias de seguridad dailyrun. Queremos comprobar la última que está en el directorio /var/lib/mysql-zrm/dailyrun/20060926202404. Así es como podemos hacerlo:

mysql-zrm --action verify-backup --backup-set dailyrun --no-quiet --source-directory /var/lib/mysql-zrm/dailyrun/20060926202404

La salida debería verse así:

| Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305. INFO: mysql-zrm-version INFO: Verification successful |

7 Recuperación de datos

Supongamos que nuestra base de datos ha fallado y hemos perdido datos. Así es como podemos restaurar nuestros datos de nuestras copias de seguridad de MySQL. Primero ejecutamos

mysql-zrm-reporter -show restore-full-info --where backup-set=dailyrun

para averiguar qué copias de seguridad están disponibles:

| backup_set backup_date backup_level backup_directory ---------------------------------------------------------------------------------------------------------- dailyrun Tue 26 Sep 2006 07:57:47 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195747 dailyrun Tue 26 Sep 2006 07:58:08 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195808 dailyrun Tue 26 Sep 2006 07:58:31 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195831 dailyrun Tue 26 Sep 2006 08:24:04 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926202404 |

Queremos restaurar desde nuestra última copia de seguridad que está en /var/lib/mysql-zrm/dailyrun/20060926202404:

mysql-zrm --action restore --backup-set dailyrun --source-directory /var/lib/mysql-zrm/dailyrun/20060926202404

La salida se ve así:

| Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305. INFO: mysql-zrm-version INFO: Restored database from raw backup: egroupware INFO: Restored database from raw backup: mysql INFO: Restore done in 14 seconds. MySQL server has been shutdown. Please restart after verification. |

Los datos han sido restaurados, pero el servidor MySQL se ha apagado. Por lo tanto, debemos iniciarlo ahora:

/etc/init.d/mysql start

Si has hecho tus copias de seguridad en el formato lógico en lugar del formato bruto, también puedes recuperar tus datos así.

8 Múltiples políticas de copia de seguridad

Hasta ahora, teníamos una configuración global en /etc/mysql-zrm/mysql-zrm.conf que se aplicaba a todos nuestros conjuntos de copias de seguridad. Ahora supongamos que tenemos un conjunto de copias de seguridad osCommerce para nuestra base de datos osCommerce, otro conjunto de copias de seguridad vBulletin para nuestra base de datos vBulletin, etc.

No tiene sentido hacer una copia de seguridad de todas nuestras bases de datos MySQL en el conjunto de copias de seguridad osCommerce porque esa copia de seguridad solo debería contener la base de datos osCommerce, y lo mismo se aplica a nuestro conjunto de copias de seguridad vBulletin. Así es como podemos resolver este problema:

Cada conjunto de copias de seguridad tiene su propio subdirectorio en el directorio /etc/mysql-zrm, por ejemplo, el conjunto de copias de seguridad osCommerce tiene el directorio /etc/mysql-zrm/osCommerce. Ahora, cada vez que se ejecute mysql-zrm, primero verifica la configuración global en /etc/mysql-zrm/mysql-zrm.conf, y luego verifica el directorio del conjunto de copias de seguridad actual para el archivo mysql-zrm.conf cuyas configuraciones anulan las configuraciones globales en /etc/mysql-zrm/mysql-zrm.conf. Por ejemplo, si el conjunto de copias de seguridad actual es osCommerce, mysql-zrm primero leería la configuración de /etc/mysql-zrm/mysql-zrm.conf y después la configuración de /etc/mysql-zrm/osCommerce/mysql-zrm.conf.

Si solo queremos hacer una copia de seguridad de la base de datos MySQL osCommerce en el conjunto de copias de seguridad osCommerce, ponemos lo siguiente en /etc/mysql-zrm/osCommerce/mysql-zrm.conf:

vi /etc/mysql-zrm/osCommerce/mysql-zrm.conf

| databases=osCommerce |

9 Eliminación de copias de seguridad antiguas

Si no has establecido una política de retención en tu configuración de mysql-zrm, las copias de seguridad de MySQL se mantienen para siempre, lo que significa que tu disco duro se llenará con el tiempo. Puedes eliminar copias de seguridad antiguas simplemente eliminando el directorio de copias de seguridad. Por ejemplo, si tienes una copia de seguridad en /var/lib/mysql-zrm/dailyrun/20060926195831 y ya no la necesitas, puedes eliminarla así:

rm -fr /var/lib/mysql-zrm/dailyrun/20060926195831

10 Registro

mysql-zrm registra en el archivo de registro /var/log/mysql-zrm/mysql-zrm.log.