Como habrás escuchado la frase una copia de seguridad no sirve si no se puede restaurar .
Hay una variedad de formas de hacer una copia de seguridad de sus archivos esenciales en un servidor en la nube. Pero lo que también es importante es que siempre tenga una copia actualizada de esos archivos en su local sistemas.
Hacer una copia de seguridad en la nube está bien. Pero una verdadera copia de seguridad es solo una copia nueva y actualizada regularmente que está disponible para usted en todo momento. ¿Por qué? ¡Porque son SUS datos!
Dos desafíos que voy a abordar en este sentido son :
- La necesidad de detener los contenedores Docker en un servidor de producción para evitar cualquier posible corrupción de datos (especialmente bases de datos) al realizar la copia de seguridad. Los archivos en los contenedores de producción en vivo se escriben continuamente.
- Detener los contenedores de Docker también genera tiempo de inactividad y no puede permitirse el lujo de hacerlo, especialmente si está en producción.
Estos problemas se pueden abordar mediante el uso de clústeres en lugar de servidores únicos. Pero aquí, me estoy centrando en servidores únicos y no en clústeres para mantener los gastos del servicio en la nube lo más bajo posible.
Seguía preguntándome cómo ocuparme de los dos desafíos anteriores. Entonces me di cuenta de que podemos hacer uso de una combinación de una nube y una solución localizada.
Por soluciones basadas en la nube, me refiero a los servicios de copia de seguridad proporcionados por proveedores de servicios en la nube como Linode, Digital Ocean y otros. En este tutorial, usaré Linode.
Por soluciones localizadas, me refiero al uso de la línea de comandos o herramientas basadas en GUI para descargar la copia de seguridad de los servidores en la nube a su sistema/escritorio local. Aquí, he usado sftp (basado en comandos).
Primero, discutiré cómo hacer la copia de seguridad y luego cómo restaurarla también.
La Nube + Procedimiento de copia de seguridad local
Veamos primero el procedimiento de copia de seguridad.
Habilite las copias de seguridad en el servidor de producción de Linode (en caso de que aún no lo haya hecho)
Si está utilizando un servidor de producción en Linode, se recomienda encarecidamente que habilite la copia de seguridad cada vez que se implemente por primera vez. Un "nanodo", como se le llama, viene con 1 GB de RAM y ofrece el siguiente plan de copia de seguridad:
Todas las demás soluciones de copia de seguridad ofrecen una función similar pero a precios más altos. Asegúrate de tenerlo habilitado.
Tomar una instantánea manual como respaldo en la nube
Introduzca una fecha para referencia futura. Aquí, lo llamo "instantánea-manual-11-05-21".
Tan pronto como haga clic en él, se le pedirá confirmación:
Cuando confirmes, encontrarás una notificación en la parte inferior derecha:
Puede monitorear el progreso en la misma página, al lado de donde dice que su servidor se está ejecutando (arriba a la izquierda):
Una vez hecho esto, notará la copia de seguridad como la cuarta en la lista.
Clonar el servidor de producción
Aunque puede clonar directamente un servidor (basado en copias de seguridad programadas anteriormente) desde el panel de Linode, le recomiendo que use copias de seguridad manuales como se explica en el paso anterior.
Por lo tanto, para continuar con la creación de un clon basado en la copia de seguridad manual más reciente que realizó, asegúrese de seguir las instrucciones a continuación:
Vaya al panel de Linode y haga clic en "Crear":
Seleccione "Linode":
Seleccione la pestaña "Copias de seguridad":
Tenga en cuenta que la instantánea que está tomando se basa en un Linode de 2 GB. Seleccione la instantánea manual que acaba de crear:
Ahora, asegúrese de seleccionar la misma especificación (Plan Linode de 2 GB) para su clon:
Una vez que haya creado el nuevo servidor basado en la copia de seguridad del servidor de producción, tendrá disponible un clon del servidor de producción.
Inicie sesión en el clon a través de ssh y detenga todos los contenedores
No debería tener problemas para iniciar sesión en el nuevo clon a través de ssh porque usa las mismas claves públicas que el servidor de producción. Solo necesita usar la nueva IP del clon. Supongo que usa ssh solo y tiene deshabilitada la autenticación basada en contraseña, ¿no es así? Lea esta guía de seguridad ssh si aún no lo ha hecho.
Una vez que haya iniciado sesión, detenga todos los contenedores cuyos datos desee respaldar. Por lo general, se movería a los directorios de aplicaciones respectivos y usaría el comando docker-compose down. En un entorno de producción típico, siempre se espera que utilice Docker Compose en lugar del docker stop convencional. comando que debe preferirse solo durante las pruebas.
Por ejemplo, si tuviera Ghost ejecutándose con su contenedor de base de datos correspondiente, primero verificaría su información respectiva:
[email protected]:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6a3aafe12434 ghost:4.4.0 "docker-entrypoint.s…" 7 days ago Up 7 days 2368/tcp ghost_ghost_2
95c560c0dbc7 jrcs/letsencrypt-nginx-proxy-companion "/bin/bash /app/entr…" 6 weeks ago Up 10 days letsencrypt-proxy-companion
6679bd4596ba jwilder/nginx-proxy "/app/docker-entrypo…" 6 weeks ago Up 10 days 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp jwilder-nginx-proxy
1770dbb5ba32 mariadb:10.5.3 "docker-entrypoint.s…" 3 months ago Up 10 days ghost_db_1
Como puede ver aquí, los nombres de los contenedores son ghost_ghost_2 y ghost_db_1 respectivamente ejecutándose bajo un proxy inverso. Detengámoslos.
[email protected]:~$ cd ghost
[email protected]:~/ghost$ docker-compose down
Stopping ghost_ghost_2 ... done
Stopping ghost_db_1 ... done
Network net is external, skipping
[email protected]:~/ghost$
En caso de que tenga más aplicaciones ejecutándose detrás de una configuración de proxy inverso nginx, use el mismo procedimiento con los respectivos nombres de directorio establecidos para las aplicaciones. Detenlos a todos uno por uno.
Copia de seguridad de volúmenes y configuraciones como archivos gzip
Ahora veamos el proceso de copia de seguridad manual.
Volúmenes con nombre de copia de seguridad
Cuando trabaje con volúmenes de Docker con nombre, tome nota de si los volúmenes se crearon manualmente o si se basaron en una configuración genérica de Docker Compose en la que se implementó la aplicación por primera vez.
Una configuración genérica en la sección de volúmenes se parece a:
volumes:
ghost:
ghostdb:
El escenario anterior es administrado por Docker Compose, y los nombres de volumen reales que necesitará para la copia de seguridad serán ghost_ghost y ghost_ghostdb .
En caso de que los volúmenes se hayan creado manualmente con docker volume create volume-name , la configuración sería similar a la siguiente y sería estrictamente ghost y ghostdb solo:
volumes:
ghost:
external: true
ghostdb:
external: true
No obstante, debe hacer una copia de seguridad de ellos en cualquier caso, y también debe verificar las rutas en los contenedores cuando se montan los volúmenes. Por ejemplo, en una configuración típica de Ghost con MariaDB, las rutas se pueden conocer mirando las subsecciones de volúmenes dentro de las definiciones de servicio. Aquí hay un extracto para mostrarle lo que quiero decir:
ghostdb:
volumes:
- ghostdb:/var/lib/mysql
La configuración anterior es parte del servicio de la base de datos y su contenedor correspondiente que se crearía una vez que se implemente.
De manera similar, para el servicio fantasma en sí, la ruta es /var/lib/ghost/content :
ghost:
volumes:
- ghost:/var/lib/ghost/content
Debe conocer estas rutas para realizar una copia de seguridad de sus volúmenes.
Usa el docker volume ls Comando para verificar dos veces los nombres de volumen presentes en el servidor clonado.
[email protected]:~/ghost$ docker volume ls
DRIVER VOLUME NAME
local ghost
local ghostdb
local nginx-with-ssl_acme
local nginx-with-ssl_certs
local nginx-with-ssl_dhparam
local nginx-with-ssl_html
local nginx-with-ssl_vhost
Entonces, puede confirmar que los volúmenes son de hecho ghost y ghostdb .
¡Es hora de respaldarlos! En el clon de producción, ahora creemos un directorio de respaldo dentro de su directorio de usuario:
mkdir ~/backup
Ahora, usaré el siguiente comando para hacer una copia de seguridad del contenido de los volúmenes dentro de un archivo tar:
docker run --rm -v ghostdb:/var/lib/mysql -v ~/backup:/backup ubuntu bash -c "cd /var/lib/mysql && tar cvzf /backup/ghostdb.tar.gz ."
En el comando anterior, con -v o --volume , monto el volumen acoplable existente en un nuevo contenedor de Ubuntu y también vinculo a montar el directorio de copia de seguridad que acabo de crear. Más tarde, me muevo al directorio de la base de datos dentro del contenedor y uso tar para archivar su contenido. --rm se usa para limpiar automáticamente el contenedor y eliminar su sistema de archivos cuando el contenedor sale (porque solo lo desea mientras se realiza el trabajo de copia de seguridad o restauración).
Fíjate en el punto al final del comando anterior antes de que finalice la comilla ("). Asegura que el archivo incluye lo que hay dentro /var/lib/ghost/content solo y sin incluir la ruta completa como subdirectorios. Este último causará problemas al restaurar el archivo a un nuevo volumen en un nuevo servidor. Por lo tanto, tenlo en cuenta.
Ahora, tengo un archivo del volumen de la base de datos MariaDB que está usando nuestro blog de Ghost. Del mismo modo, también tengo que hacer una copia de seguridad del volumen fantasma:
docker run --rm -v ghost:/var/lib/ghost/content -v ~/backup:/backup ubuntu bash -c "cd /var/lib/ghost/content && tar cvzf /backup/ghost.tar.gz ."
Recuerde que los comandos de copia de seguridad anteriores se basan en volúmenes externos que inicialmente se crearon manualmente. Para los volúmenes genéricos creados y administrados por Docker Compose, los nombres reales de los volúmenes serían ghost_ghost y ghost_ghostdb respectivamente. Por ejemplo, para ghost_ghostdb , el ghost el prefijo se refiere al nombre del directorio de su aplicación donde tiene sus archivos de configuración de Docker Compose y ghostdb se refiere al nombre del volumen que ha establecido en su configuración de Docker Compose.
Configuración de copia de seguridad con o sin montajes bind
También tenga en cuenta que debe archivar el directorio de composición de la ventana acoplable fantasma independientemente de si usa montajes de enlace o volúmenes con nombre porque sus archivos de configuración se almacenan aquí.
En caso de que esté utilizando montajes de enlace y no volúmenes de Docker con nombre, todo el directorio se archivaría, incluidos los montajes de enlace. Aquí, lo llamo ghost-docker-compose.tar.gz para evitar confusiones:
[email protected]:~/ghost$ sudo tar cvzf ~/backup/ghost-docker-compose.tar.gz .
Los volúmenes montados en enlace no necesitan una sección de volúmenes separada en un archivo de Docker Compose. Simplemente les gustaría lo siguiente cuando se defina dentro del servicio:
ghost:
volumes:
- ./ghost:/var/lib/ghost/content
De manera similar, el volumen de la base de datos montada en enlace se vería así:
ghostdb:
volumes:
- ./ghostdb:/var/lib/mysql
"./" indica el directorio montado en el enlace dentro del mismo directorio fantasma en el que acabamos de "cd". Por lo tanto, haga una copia de seguridad completa de todos los archivos en este caso (incluidos los volúmenes y los archivos de configuración).
Montaje de enlace de copia de seguridad como volúmenes con nombre
Como alternativa, también puede hacer una copia de seguridad individual de los montajes de enlace. Esto le da la opción de elegir si desea que su nuevo servidor tenga un enlace montado o una configuración de volumen con nombre en Docker. La razón es que los archivos se respaldan de la misma manera que los volúmenes con nombre que se mencionaron anteriormente. Para hacer eso, necesita "cd" en los directorios de la aplicación y la base de datos (montajes de enlace) uno por uno.
cd ~/ghost/ghost
sudo tar cvzf ~/backup/ghost.tar.gz .
cd ~/ghost/ghostdb
sudo tar cvzf ~/backup/ghostdb.tar.gz .
Tanto los montajes de enlace como los volúmenes con nombre tienen sus propias ventajas y desventajas. La pregunta sobre cuál de ellos es el más ideal varía de una aplicación a otra. Por ejemplo, los desarrolladores de Nextcloud sugieren volúmenes con nombre, mientras que los desarrolladores de Rocket.Chat sugieren montajes vinculados.
Continuando, es hora de que busques esos archivos en tu extremo.
Descargue los archivos a su sistema local usando sftp
Con sftp, puede descargar sus archivos directamente en su sistema local. Aquí estoy usando el puerto 4480 y la IP 12.3.1.4 como ejemplo. Se refiere al mismo puerto usado por ssh.
[email protected]:~$ sftp -oPort=4480 [email protected]
Connected to 12.3.1.4.
sftp> get /home/avimanyu/backup/ghost.tar.gz /home/user/Downloads
Fetching /home/avimanyu/backup/ghost.tar.gz to /home/user/Downloads/ghost.tar.gz
/home/avimanyu/backup/ghost.tar.gz 100% 233MB 6.9MB/s 00:34
sftp> get /home/avimanyu/backup/ghostdb.tar.gz /home/user/Downloads
Fetching /home/avimanyu/backup/ghostdb.tar.gz to /home/user/Downloads/ghostdb.tar.gz
/home/avimanyu/backup/ghostdb.tar.gz 100% 26MB 6.5MB/s 00:03
sftp> get /home/avimanyu/backup/ghost-docker-compose.tar.gz /home/user/Downloads
Fetching /home/avimanyu/backup/ghost-docker-compose.tar.gz to /home/user/Downloads/ghost-docker-compose.tar.gz
/home/avimanyu/backup/ghost-docker-compose.tar.gz 100% 880 6.0KB/s 00:00
sftp> exit
[email protected]:~$
Como puede ver aquí, el get comando en sftp es muchísimo más rápido que rsync o scp . Una vez la descarga está completa, se le mostrará el indicador de sftp donde puede ingresar exit y salir de la consola sftp. Los archivos descargados estarían disponibles en /home/user/Downloads .
En este punto, puede decir que ha realizado una copia de seguridad completa de su aplicación acoplable.
Pero como debo decir de nuevo, no es bueno a menos que puedas restaurarlo.
Procedimiento de restauración
Ahora que sabe cómo hacer una copia de seguridad, es hora de ver cómo restaurar desde una copia de seguridad.
Crear un nuevo servidor en la nube
Cree un nuevo servidor nuevo desde su panel de servicio en la nube. Discutí esto en nuestra sección de respaldo. En Linode, parece:
Se recomienda mantener las mismas especificaciones del servidor que las del servidor original desde el que se realizó la copia de seguridad de los archivos comprimidos (mencionado anteriormente).
Subir archivos de copia de seguridad al nuevo servidor
Suponiendo que ahora puede iniciar sesión en el nuevo servidor según la configuración de ssh guardada en su proveedor de servicios en la nube, cargue los archivos en el servidor con put de sftp comando:
[email protected]:~$ sftp -oPort=4480 [email protected]
Connected to 12.3.1.5.
sftp> put /home/user/Downloads/ghostdb.tar.gz /home/avimanyu
Uploading /home/user/Downloads/ghostdb.tar.gz to /home/avimanyu/ghostdb.tar.gz
/home/iborg/Downloads/ghostdb.tar.gz 100% 26MB 6.2MB/s 00:04
sftp> put /home/user/Downloads/ghost.tar.gz /home/avimanyu
Uploading /home/user/Downloads/ghost.tar.gz to /home/avimanyu/ghost.tar.gz
/home/iborg/Downloads/ghost.tar.gz 100% 233MB 7.2MB/s 00:32
sftp> put /home/user/Downloads/ghost-docker-compose.tar.gz /home/avimanyu
Uploading /home/user/Downloads/ghost-docker-compose.tar.gz to /home/avimanyu/ghost-docker-compose.tar.gz
/home/iborg/Downloads/ghost-docker-compose.tar.gz 100% 880 22.6KB/s 00:00
sftp> exit
[email protected]:~$
Si prefiere usar una GUI para cargar, aún puede usar FileZilla.
Restaurar configuraciones y volúmenes
Primero, restaure el directorio de composición de la ventana acoplable de su configuración de Ghost.
mkdir ghost
cd ghost
sudo tar xvf ~/backup/ghost-docker-compose.tar.gz
Como alternativa, también puede intentar restaurar la propiedad del usuario (los permisos ya se conservan) que podría ser útil al restaurar directorios montados en enlace (ya presentes en los archivos), con --same-owner :
sudo tar --same-owner -xvf ~/backup/ghost-docker-compose.tar.gz
En caso de que desee confiar en Docker Compose para administrar los nuevos volúmenes, créelos primero. Según nuestra discusión en la sección de volúmenes de copia de seguridad anterior, obviamente tendría que seguir las convenciones de nomenclatura necesarias:
docker volume create ghost_ghost
docker volume create ghost_ghostdb
Si desea configurarlos como externos dentro de su configuración de Docker Compose, los nombres deberían ser diferentes (revise los dos comandos anteriores):
docker volume create ghost
docker volume create ghostdb
Para restaurar el volumen de MariaDB para Ghost:
docker run --rm -v ghostdb:/restore -v ~/backup:/backup ubuntu bash -c "cd /restore && tar xvf /backup/ghostdb.tar.gz"
Para restaurar el propio volumen de Ghost:
docker run --rm -v ghost:/restore -v ~/backup:/backup ubuntu bash -c "cd /restore && tar xvf /backup/ghost.tar.gz"
Asegúrese de que la configuración de DNS se restablezca en función de la nueva IP
Dado que está utilizando un nuevo servidor, la IP definitivamente ha cambiado y, por lo tanto, debe revisarse para su dominio. Puede consultar estos requisitos previos de la ventana acoplable de proxy inverso nginx como referencia donde se ha discutido.
Lanzar nuevos contenedores con la configuración necesaria y los volúmenes restaurados
Ahora reinicie la configuración en el nuevo servidor:
docker-compose up -d
Si sigue todas las instrucciones anteriores con asiduidad, ahora tendrá una aplicación web Docker completamente restaurada basada en su copia de seguridad.
Destruye el Clon
Una vez que esté seguro de que ha logrado su objetivo, ya no es necesario tener el clon a menos que desee conservarlo para realizar pruebas. Entonces, si ya no lo quiere, elimine el Linode (¡COMPROBACIÓN DOBLE!):
Pensamientos finales
Ya existen muchas soluciones que hacen uso de tales métodos en partes y porciones. Pero eso exige un tiempo de inactividad porque los contenedores deben detenerse. Ese desafío se soluciona mediante el uso de copias de seguridad en la nube de clones de producción y no de los propios servidores de producción.
En lugar de usar un servidor adicional las 24 horas del día, los 7 días de la semana como un clúster para copias de seguridad sin tiempo de inactividad, solo estamos usando uno momentáneamente para garantizar lo mismo. Esto permite mejores FinOps.
Si prefiere usar una GUI para descargar o cargar sus copias de seguridad, puede usar sftp a través de FileZilla.
Dado que está realizando una copia de seguridad de los archivos en un servidor clonado y no en el propio servidor de producción, está ahorrando un valioso tiempo de actividad, además de evitar contratiempos inesperados que podría encontrar durante el proceso. Para ser honesto, puedes estar libre de cualquier preocupación y jugar con él sin ninguna tensión porque no tocas el servidor de producción;)
No puedo negar que todo el proceso es bastante completo, pero seguro que cumple con nuestro objetivo. Mirando más allá, este procedimiento también podría automatizarse por completo en el futuro, con una cuidadosa sincronización entre la nube y su sistema local.
Si tiene más sugerencias sobre la copia de seguridad y la restauración de Docker sin tiempo de inactividad, comparta sus opiniones en la sección a continuación. Cualquier otro comentario o comentario es bienvenido.