Backup del sistema

Como no podía ser de otra forma, ha llegado el día, sí, ese día fatídico, que sabía que iba a llegar: fallo total del sistema :(.

Necesitaba recompilar el kernel para activar el soporte para IPSec (VPNs) y actualizando el kernel del sistema, puse el sistema de archivos en modo RW (lectura escritura) para hacer los cambios. La actualización no funcionó como debiera (ley de Murphy). Resultado: sistema de archivos corrupto, y en remoto… Soy un temerario, que se le va a hacer.

Tras una semana remontado todo el sistema, he detectado un punto débil en el sistema: a pesar de que el sistema de archivos raíz esté en modo RO (sólo lectura), no tenía copia de seguridad de las bases de datos de MySQL, ni de las bases de datos RRD de Cacti. Aunque la partición donde guardo los datos variables está en una tarjeta SD ajena al sistema de archivos raíz (y estaba intacta), se me ha metido en miedo en el cuerpo, y voy a programar un sistema de copias de seguridad mediante una tarea diaria en CRON que al menos una vez a la semana me las mande por email.

Backup de MySQL

Lo primero que vamos a hacer es crear un usuario con los permisos necesarios para leer todas las tablas de la base de datos con el fin de usarlo con el comando mysqldump. Los permisos que va a necesitar ese usuario son los de LOCK TABLES, SELECT, FILE, RELOAD, SUPER y SHOW VIEW:

Comprobamos que el usuario que acabamos de crear nos exporta correctamente todas las bases de datos con el comando:

Nos da un warning, que podemos ignorar ya que no estamos usando el Event Scheduler de MySQL (más información aquí). Si no tenemos ningún, podemos comprobar el resultado de la exportación en el fichero /tmp/backup.sql. Tengo que mencionar que la opción –add-drop-database sirve para que cuando hagamos la restauración nos elimine las bases de datos antes de crearlas, ya que si existen, nos data errores porque las tablas ya existirán. Tened cuidado si restauráis sobre un MySQL con bases de datos que queréis conservar (sobre todo la base de datos con nombre mysql, ya que contiene todas las tablas con los usuarios, permisos y demás.

Backup de Cacti

Nos interesa hacer copia de la base de datos MySQL de Cacti (que ya esta incluida en el paso anterior), de los archivos RRD con los datos históricos, de los scripts que usamos para recopilar la información (que guardamos en /etc/JDOMO (la haremos en el siguiente paso) y en las carpetas de la instalación de Cacti).

He usado el formato de salida xz ya que se generan archivos bastante mas pequeños que con el formato gz de siempre. Como veis hay dos formas de generarlos, la primera funciona en los sistemas modernos y es más compacta. La segunda funciona en los sistemas con versiones de tar más antiguas pero con el programa xz instalado.

Backup de /etc

A medida que vamos tocando configuraciones, programando tareas, instalando servicios, iremos teniendo cada vez más y más archivos sueltos que deberemos conservar en caso de un fallo y que es bastante engorroso restaurar. La mayor parte de las configuraciones están en la carpeta /etc. En mi caso, he modificado las tareas programadas con cron (que usan el archivo crontab y los directorios /etc/cron.*), los datos de localización (para castellanizar el sistema, y que se encuentran en /etc/locale y /etc/default), la configuración de motion (en /etc/motion), los scripts de inicio de varios servicios (/etc/init y /etc/init.d), la del servidor vsftpd (/etc/vsftpd.conf), las reglas de generación de nombres de dispositivos con udev (/etc/udev.d para asignar nombres fijos a un arduino, y al dispositivo RFXCOM en lugar de los tipicos /dev/ttyUSBx…), la configuración de Mosquitto (en /etc/mosquitto), pruebas de VPNs (en /etc/ipsec…). Y esto solo de lo que recuerdo ahora de memoria… Mejor hacer copia de todo /etc, ¿verdad? 🙂

 

Backup de openHAB

Como últimamente realizo muchas pruebas con openHAB, necesito que sus archivos de configuración estén en la partición de lectura/escritura /mnt/Data, fuera de /etc. Por ello haremos también una copia de seguridad de los mismos para enviarla por email.

 

Copia completa del sistema básico

Otra copia que podemos hacer y que nos será muy útil en caso de corrupción del sistema de archivos raíz o de que no arranque el sistema operativo es la copia de esos dos sistemas de ficheros: /boot y /. En el caso de mi sistema, que tengo una tarjeta eMMC con las particiones /boot y / (de sólo lectura), y una SD con los datos en /mnt/Data (de lectura/escritura).

Esta distribución de las particiones tiene una ventaja grandísima: al estar el sistema necesario para que arranque en una tarjeta y ser todo de sólo lectura, podemos hacer copia en caliente (con los sistemas de archivos montados) en la otra tarjeta, y no habrá absolutamente ningún problema si, llegado el momento, tenemos que restaurar, ya que durante la copia no se modificará nada en la tarjeta eMMC. Útil, ¿verdad?

Para hacer la copia bastaría con algo tan simple como:

Esta copia del sistema la podemos hacer una vez al mes, o hacerla solo manualmente cuando realicemos cambios o actualizaciones. Mi recomendación personal es hacerla automáticamente. De todos es conocida la ley de Murphy que dice que justo cuanto te falle el sistema, se te habrá olvidado hacer la copia de seguridad o la que tengas será demasiado antigua. Así que mejor que el sistema la haga sola y te avise cuando la haya hecho con los resultados de la misma (de nada sirve que se ejecute el script de copia de seguridad, si no hay espacio en la partición de destino, y esta fallando sin que lo sepamos…). Parecerá que soy algo paranoico, pero cuando llevas tantos años como yo manejando copias de seguridad, te ha pasado de todo :).

En este sistema, tengo una tarjeta para /boot y / de 8Gb, y una para /mnt/Data de 32Gb, por tanto podremos guardar al menos una copia de la tarjeta pequeña en la grande (las grabaciones y capturas de imágenes con motion ocupan mucho espacio, y con las pruebas que estoy haciendo últimamente de capturar una imagen por minuto y guardármela, no me sobra el espacio, jajajajaaaa). De todas formas podemos comprimir la imagen con xz, o con pxz para que ocupe muchísimo menos (en mi caso, los 8Gb los deja en menos de 2Gb).

Recopilando…

Como veis, siguiendo esta metodología podemos tener un sistema de copias de seguridad bastante fácil de mantener y de ampliar. Lo único que nos queda es crear un archivo llamado backup en el directorio /etc/cron.daily con el siguiente contenido (tal y como hemos ido explicando más arriba):

y en el directorio /etc/cron.weekly creamos el archivo backup_emmc para hacer la copia de las tarjeta eMMC en la tarjeta SD:

Les damos permiso de ejecución a los dos y reiniciamos el servicio cron, para que recargue la nueva configuración, y listo:

Como curiosidad os puedo decir que la copia comprimida de la tarjeta de 8Gb tarda una hora en realizarse, usando pxz, que utiliza varios hilos (al ser el micro de la Odroid U3 quadcore, lo aprovechamos mejor que con xz). Si tenéis un servidor FTP remoto, o SFTP (mejor, ya que usa cifrado) os podéis enviar la imagen completa a otro equipo o a la nube…

¡Espero que os haya gustado!

Comentarios

  1. Por Mihai

    Responder

    • Por José María

      Responder

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *