605 - Migraciones y backup de volumenes Docker
Un contenedor #docker para realizar copias de seguridad y #backup de tus volumenes de forma sencilla en #linux y en otros sistemas operativos
Esto de los backup es siempre un dolor, pero es algo necesario, y que puede ahorrarte mas de un dolor de cabeza. La cuestión es que hasta el momento, tenía perfectamente resuelta la parte de realizar copias de seguridad de la base de datos, pero no tanto así de los datos. Por otro lado, de todos mis procesos de migración, todavía me quedaba pendiente uno. Así, que se ha juntado todo, la migración mas resolver el problema del backup de volumenes Docker.
Esto de las copias de seguridad y backup de los volúmenes es algo recurrente en el grupo de atareao con Linux en Telegram, sin embargo, hasta el momento no lo había abordado.
Migraciones y backup de volumenes Docker
Migraciones
Empiezo por la parte de la migración, y es que como te decía en la introduccióm, y tal y como te conté en anteriores episodios, todavía tenía pendiente una migración. Una migración que me estaba dando problemas. Todo ello ocasionado por la versión de PHP, la versión de la base de datos y la versión de los complementos.
Base de datos
Hasta el momento, esta migración la estaba intentando hacer con Duplicator, y tengo que decir que esto fue un craso error, no necesitaba para nada ningún tipo de complemento. Todo era mucho mas sencillo. Simplemente tenía que hacer un backup de todas las bases de datos y posteriormente un restore. Básicamente,
mariadb-dump --all-databases -u root -p > dump.ddbb.sqlY tarball de los archivos,
tar -cvzf backup.tar.gz /html/Una vez restaura tuve que resolver algunos problemas con la versión de MariaDB, pero no fue nada complejo. Simplemente ejecutar un par de sentencias SQL y listo.
Actualizar plugins
El siguiente problema vino de la mano de la versión de complementos y temas. Resulta que algunos de estos complementos no están actualizados a la versión 8.x de PHP. Esto me llevó bastante tiempo hasta que conseguí ir resolviendo cada uno de los problemas de incompatibilidad. Siempre, por supuesto, mirando el log y armado de mucha paciencia.
Y para terminar, quitar aquellos plugins que no se utilizan o que pienso que no se utilizan. Esto, como te puedes imaginar, ha sido cuestión de prueba y error, hasta que mas o menos, he visto que todo funciona como se espera.
El stack tecnológico
Sobre la configuración ya te conté anteriormente, en el episodio 600 sobre atareao.es ya es selfhosted.
watchtower
Respecto a WatchTower si que he hecho una modificación que es la programación de las actualizaciones que la he dejado a una hora fija,
WATCHTOWER_NOTIFICATIONS=shoutrrr
WATCHTOWER_NOTIFICATION_URL=generic://hookbridge:6969/matrix_watchtower?template=json&disabletls=yes
TZ=Europe/Madrid
WATCHTOWER_CLEANUP=true
WATCHTOWER_SCHEDULE="0 0 3 * * *"La copia de seguridad
Probablemente, esto es lo que mas tiempo me ha llevado, porque no tenía muy claro cual sería la mejor forma de hacerlo. Es mas, ahora mismo, tampoco tengo muy claro que la solución que he escogido sea la mejor. Voy a ver como se comporta en los próximos días y semanas, y en función de eso tomaré una decisión.
Todo empezó con rsync, es decir sincronizar los archivos con un directorio de copia de seguridad. Sin embargo, esto me resta versatilidad, en el sentido de que no puedo recuperar los archivos de un día concreto.
Llegados a ese punto pensé en crear un tarball de los archivos sincronizados. Esto implicaba que tendría tantas copias como días. Con lo que esto se podría convertir en algo completamente ingobernable.
Así encontré que se podían hacer tarball incrementales y diferenciales. Esto me permitía tener una gestión bastante mas interesante. Podía recuperar un único día, y el volumen de almacenamiento no se vería afectado. Pero no era tan sencillo.
Se parte de una copia completa, y a partir de ahí se van haciendo variaciones, que pueden ser incrementales, es decir, que cada día se sume lo del día anterior, o diferenciales que cada día se añada lo nuevo exclusivamente. El problema de este segundo es que no puedes recuperar un día concreto, sino que tienes que hacer toda la recuperación. O al menos yo no encontré la forma de hacerlo. Solución, los incrementales, pero siempre respecto al primer día del mes.
De esta forma tengo que restaurar el tarball del primer día del mes, y el correspondiente al día que quiera… Por otro lado, con el contenedor que he hecho, me permite establecer cuantos meses quiero guardar. En principio, he indicado que tres, que para mi son mas que suficiente. De cualquier forma, esto tiene que ser a partir de los resultados que vea.
Así, el docker-compose.yml, correspondiente a la copia de seguridad tiene un aspecto como el que te muestro a continuación,
wordpress_backup:
image: atareao/volume-backup:latest
container_name: wordpress_backup
init: true
restart: unless-stopped
networks:
- internal
volumes:
- backup_wordpress:/backup:rw
- wordpress:/var/www/html:ro
environment:
SCHEDULE: "0 2 * * *"
BACKUP_DIR: "/backup"
VOLUME: wordpress
MOUNTED_FOLDER: /var/www/html/wp-content
KEEP_MONTHS: 3
volumes:
backup_wordpress: {}
wordpress: {}Los parámetros son los siguientes,
SCHEDULEpara indicar la programación que quieres para hacer la copia de seguridadBACKUP_DIRdonde quieres guardar la copia de seguridVOLUMEel volumen donde se encuentra los datos que quieres salva guardarMOUNTED_FOLDERes el directorio que quieres salvaguardarKEEP_MONTHSlos meses que quieres guardar
Como ves el esquema es similar al de copias de seguridad para MariaDB o PostgreSQL que tengo hecho.
Indicar que yo guardo las copias de seguridad en un volumen, en lugar de un directorio. Esto lo hago así, por comodidad, así no tengo que preocuparme de permisos, y este tipo de cosas. Pero evidentemente, tu podrías montarlo directamente como un directorio y listo.
Pendiente
Llegados a este punto, todavía me queda pendiente el envío la copia de seguridad a otro servidor. Esto todavía no lo tengo implementado, pero es mi próximo objetivo.