Cómo hacer copias de seguridad y actualizar Docker Compose

Qué debe contener una copia de seguridad de una pila de Docker Compose

Una copia de seguridad de una pila de Docker Compose debe contener cuatro elementos separados. Si se pierde cualquiera de ellos, la aplicación no se recuperará: el archivo de Compose, el archivo .env que está junto a él, el contenido de todos los volúmenes y un volcado de la base de datos creado con el cliente propio de la base de datos. Copiar los archivos de una base de datos mientras su contenedor está en ejecución no es una copia de seguridad. Las actualizaciones usan la misma lista y una regla adicional: haga la copia de seguridad antes de ejecutar pull, porque las migraciones de esquema están diseñadas para avanzar y la mayoría de los proyectos no ofrecen una forma de volver atrás.

Todo lo siguiente presupone que la pila ya está desplegada y que docker compose ps muestra que está en ejecución. Los ejemplos usan un directorio de proyecto en /srv/myapp, con servicios llamados app y db. Sustituya esos nombres por los suyos. Los comandos se mantienen genéricos de forma deliberada, porque las partes importantes, los volúmenes y la base de datos, funcionan igual independientemente de la aplicación.

Determine qué almacena realmente tu stack

cd /srv/myapp
docker compose ps
docker compose config --volumes
docker volume ls --filter label=com.docker.compose.project=myapp

docker compose config --volumes muestra los nombres cortos de los volúmenes con nombre declarados en el archivo. docker volume ls muestra los nombres que esos volúmenes tienen realmente en el disco. Las dos listas difieren porque Compose antepone el nombre del proyecto: un volumen escrito como db_data en el archivo existe como myapp_db_data. De forma predeterminada, el nombre del proyecto es el nombre del directorio. Por tanto, cambiar el nombre del directorio hace que el stack use un conjunto nuevo de volúmenes vacíos y deja los antiguos con todos tus datos. Todos los comandos siguientes necesitan el nombre real de docker volume ls.

Los bind mounts no aparecen en ninguna de las dos listas. En el archivo Compose, son las entradas que tienen una ruta del host a la izquierda de los dos puntos, ./config:/app/config. Son directorios normales del host, por lo que las herramientas habituales pueden acceder a ellos. Los volúmenes con nombre se almacenan en /var/lib/docker/volumes/, y docker volume inspect --format '{{.Mountpoint}}' myapp_db_data muestra la ruta exacta de uno de ellos. El tipo de almacenamiento que use tu stack determina cómo debes copiarlo. bind mounts frente a volúmenes con nombre explica la diferencia en detalle.

Ahora clasifica lo que has encontrado en dos grupos. Algunos volúmenes contienen estado que nada puede recrear: archivos subidos, claves generadas, la propia base de datos y cualquier dato que un usuario haya introducido en la aplicación. Otros contienen datos derivados, como miniaturas e índices de búsqueda, que la aplicación reconstruye por sí sola. Hacer copias de seguridad del segundo grupo consume espacio de disco y tiempo de restauración, pero no aporta nada. Un volumen de caché de Redis es el ejemplo más claro: perderlo sólo hace que la primera petición sea más lenta.

Haga una copia de seguridad del archivo compose y del archivo .env

Ambos archivos se encuentran juntos en el host y ninguno está dentro de un volumen. El .env contiene la contraseña de la base de datos, el secreto de la aplicación y cualquier token de API, por lo que es el archivo que convierte un conjunto de volúmenes en una aplicación funcional. Normalmente también aparece en .gitignore, lo que significa que un plan basado en «mi configuración está en git» excluye el único archivo más importante. Mantener los secretos en un archivo env es el patrón correcto y también impone una responsabilidad equivalente a las copias de seguridad.

sudo install -d -m 700 -o "$USER" -g "$(id -gn)" /srv/backups/myapp
cp -a compose.yaml .env /srv/backups/myapp/
chmod 600 /srv/backups/myapp/.env

Copie todos los archivos compose que use el stack, no sólo el primero. Un stack iniciado con -f compose.yaml -f compose.prod.yaml necesita que ambos archivos se restauren de la misma forma, y cómo se combinan varios archivos compose determina qué valores llegan realmente al contenedor.

Una advertencia relaciona .env con los volúmenes. La imagen oficial de Postgres sólo lee POSTGRES_PASSWORD cuando inicializa un directorio de datos vacío. Cambiar ese valor posteriormente no cambia la contraseña dentro de la base de datos. Si restaura el volumen del mes pasado junto con el .env de hoy, la aplicación no puede conectarse con FATAL: password authentication failed for user "appuser", aunque ambos archivos parezcan correctos al inspeccionarlos. Mantenga el .env y los volúmenes del mismo momento juntos en la misma copia de seguridad.

Volcar la base de datos con su propio cliente

Un servidor de bases de datos escribe constantemente en sus archivos. Un tar de /var/lib/postgresql/data tomado mientras el servidor está en ejecución copia algunas páginas de antes de una escritura y otras de después, por lo que el archivo contiene una mezcla de momentos que puede no reproducirse correctamente. Una herramienta de volcado lee dentro de una sola transacción, por lo que el archivo contiene un momento coherente. Esa diferencia separa una copia de seguridad de una copia.

docker compose exec -T db sh -c \
  'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc' \
  > /srv/backups/myapp/db-$(date +%F).dump

Conserve -T. Desactiva la asignación de una TTY. Con una TTY asociada, Docker transforma el flujo de salida antes de enviarlo al shell, lo que corrompe un volcado binario. No lo sabrá hasta que falle la restauración. Las comillas simples también son importantes: impiden que el shell del host expanda $POSTGRES_USER, de modo que lo expande el shell dentro del contenedor usando los valores que el archivo compose ya define allí. -Fc escribe el formato personalizado, que comprime los datos durante el volcado y permite que pg_restore extraiga objetos más adelante.

Los roles y sus contraseñas se almacenan fuera de cualquier base de datos individual, por lo que también debe guardarlos:

docker compose exec -T db sh -c 'pg_dumpall -U "$POSTGRES_USER" --globals-only' \
  > /srv/backups/myapp/globals.sql

Después, compruebe que el archivo sea un volcado y no un mensaje de error:

ls -lh /srv/backups/myapp/
head -c 5 /srv/backups/myapp/db-$(date +%F).dump

Un volcado en formato personalizado comienza con los cinco bytes PGDMP. Un archivo de cero bytes, o uno que comience por pg_dump:, indica que el comando falló. El shell crea el archivo de salida antes de ejecutar el comando, por lo que un volcado fallido deja un archivo con un nombre y una marca de tiempo plausibles. Este es el fallo silencioso de copia de seguridad más común.

En MariaDB o MySQL cambia el cliente, pero no la estructura:

docker compose exec -T db sh -c \
  'mariadb-dump -u root -p"$MARIADB_ROOT_PASSWORD" --single-transaction --databases "$MARIADB_DATABASE"' \
  > /srv/backups/myapp/db-$(date +%F).sql

--single-transaction genera un volcado coherente de las tablas InnoDB sin bloquear las escrituras. En la imagen de MySQL, el comando es mysqldump y las variables son MYSQL_ROOT_PASSWORD y MYSQL_DATABASE. En las imágenes actuales de MariaDB, mysqldump sigue funcionando como nombre compatible de mariadb-dump. Tenga en cuenta que una contraseña proporcionada en la línea de comandos es visible en la lista de procesos del contenedor mientras se ejecuta el volcado.

SQLite requiere precauciones específicas. La base de datos es un solo archivo, pero las transacciones recientes pueden permanecer en un archivo -wal separado junto a él. Si sólo copia .db, la base de datos no incluirá sus escrituras más recientes. Si la imagen incluye el cliente, sqlite3 /data/app.db ".backup '/data/app-backup.db'" escribe una copia coherente mientras la aplicación está en ejecución. Si no lo incluye, detenga el contenedor y copie el archivo .db junto con sus archivos complementarios -wal y -shm.

Si la base de datos se ejecuta en el host en lugar de dentro de la pila, los mismos comandos se aplican sin el prefijo docker compose exec. También conviene leer ejecutar la base de datos en Docker o en el host antes de la próxima reconstrucción.

Capturar los volúmenes

Un volumen con nombre no tiene una ruta del host que deba editarse manualmente. Móntelo en un contenedor temporal y archívelo desde allí.

docker run --rm \
  -v myapp_uploads:/data:ro \
  -v /srv/backups/myapp:/backup \
  alpine:3 tar czf /backup/uploads.tar.gz -C /data .

El contenedor auxiliar monta el volumen en modo de solo lectura en /data y el directorio de copias de seguridad en /backup. Después escribe el archivo de la copia en el lado del host. --rm elimina el contenedor auxiliar en cuanto termina tar. :ro es importante porque un comando tar mal escrito no puede dañar el origen. -C /data . hace que la restauración termine en la ubicación correcta: almacena cada ruta relativa a la raíz del volumen. Escriba tar czf /backup/uploads.tar.gz /data en su lugar y todas las rutas incluirán un data/ inicial. La restauración creará /data/data dentro del volumen y la aplicación verá un directorio vacío. El archivo pertenece a root porque tar se ejecutó como root dentro del contenedor. Ejecute sudo chown "$USER" /srv/backups/myapp/uploads.tar.gz si esto supone un problema y consulte cómo PUID y PGID determinan la propiedad de los archivos si la aplicación no puede leer los archivos restaurados.

Ejecútelo una vez por cada volumen con nombre. Los montajes bind no necesitan ningún contenedor: tar czf /srv/backups/myapp/config.tar.gz -C /srv/myapp/config . hace el mismo trabajo en el host.

Decida para cada volumen si la aplicación debe detenerse. Un tar ejecutado mientras la aplicación reescribe el volumen puede capturar un archivo a mitad de una escritura. En un directorio de cargas, donde los archivos se escriben una vez y después sólo se leen, el riesgo es pequeño. Para cualquier otro caso, detenga ese servicio durante la copia con docker compose stop app y después ejecute docker compose start app. stop mantiene los contenedores y los volúmenes en su sitio, que es exactamente lo que necesita aquí. Consulte la diferencia entre down y stop antes de ejecutar cualquiera de los dos comandos.

No trate un tar del volumen de la base de datos como una copia de seguridad de la base de datos. La copia exportada es la copia de seguridad. Un archivo del volumen de una base de datos detenida sólo sirve como vía rápida para reconstruirla.

Orden de las operaciones

1. Copie los archivos de Compose y el .env en el directorio de copias de seguridad.
2. Exporte la base de datos mientras siga en ejecución.
3. Detenga el contenedor de la aplicación si sus volúmenes cambian directamente.
4. Archive cada volumen con nombre y cada directorio montado mediante bind.
5. Inicie de nuevo todo lo que haya detenido y confirme el estado con docker compose ps.
6. Anote las etiquetas y los resúmenes de las imágenes que ejecuta el stack.
7. Copie todo el directorio de copias de seguridad fuera de este servidor.

El paso 7 es el que se suele dejar para después.

Saque la copia del servidor

Una copia de seguridad en el mismo disco que la pila sólo protege frente a sus propios errores. No protege frente a nada más. Un volumen averiado, un servidor eliminado o una cuenta perdida pueden afectar a las dos copias al mismo tiempo. Envíe el directorio a un almacenamiento que no esté en este VPS, con una programación y una política de retención. copias de seguridad de restic desde un VPS cubre la configuración del repositorio, los flags de retención y el comando de comprobación, por lo que no es necesario repetirlos aquí.

restic también puede leer el volcado directamente desde una tubería. Así, la base de datos en texto plano no se almacena en el disco:

docker compose exec -T db sh -c 'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc' \
  | restic backup --stdin --stdin-filename db.dump

Use la herramienta que use, configure la programación en un temporizador de systemd o en una tarea de cron, y haga que el trabajo informe de los errores en un lugar que pueda consultar. Un script de copia de seguridad cuya salida no se envía a ninguna parte puede dejar de funcionar durante seis meses sin que nadie lo descubra.

Compruebe que la copia de seguridad funciona mediante una prueba de restauración

Una copia de seguridad que nadie ha restaurado es una hipótesis. La prueba siguiente restaura los datos en una segunda pila que se ejecuta junto a la primera. La producción sigue atendiendo peticiones y nada de lo que escriba puede llegar a ella.

El mecanismo es el nombre del proyecto. Compose lo obtiene del nombre del directorio y lo asigna a todos los contenedores y volúmenes que crea. Copie la copia de seguridad en un directorio nuevo y la pila restaurada obtendrá automáticamente sus propios volúmenes.

sudo install -d -m 700 -o "$USER" -g "$(id -gn)" /srv/myapp-restore
cd /srv/myapp-restore
cp /srv/backups/myapp/compose.yaml /srv/backups/myapp/.env .

Edite el archivo compose copiado para que el puerto publicado en el host no entre en conflicto con la pila en ejecución: use 18080:8080 en lugar de 8080:8080, o cambie en el .env copiado la variable que lo establece. Después, cree los contenedores y sus volúmenes vacíos sin iniciar nada:

docker compose create
docker volume ls --filter label=com.docker.compose.project=myapp-restore

El segundo comando debería mostrar los mismos nombres de volumen que producción, con myapp-restore_ delante. Rellénelos, inicie sólo la base de datos y cargue el volcado:

docker run --rm -v myapp-restore_uploads:/data -v /srv/backups/myapp:/backup \
  alpine:3 tar xzf /backup/uploads.tar.gz -C /data
docker compose up -d db
docker compose exec -T db sh -c \
  'pg_restore -U "$POSTGRES_USER" -d "$POSTGRES_DB" --clean --if-exists' \
  < /srv/backups/myapp/db-2026-08-16.dump

--clean --if-exists elimina cada objeto antes de volver a crearlo, lo que hace que la restauración se pueda repetir. Sin esta opción, una segunda ejecución en una base de datos que ya contiene esas tablas se detiene con pg_restore: error: could not execute query: ERROR: relation "users" already exists.

Después, inicie el resto y compruébelo como lo haría un usuario:

docker compose up -d --wait
docker compose exec -T db sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "\dt"'
docker compose logs --tail=50

docker compose up -d --wait espera hasta que todos los servicios indiquen que están en ejecución o en estado saludable, y termina con un código distinto de cero si alguno nunca alcanza ese estado. Esto permite automatizar este paso. Si un servicio nunca alcanza el estado saludable, docker compose ps muestra su estado, y las comprobaciones de estado de Compose explica qué valor está leyendo esa columna. Después, abra la aplicación en el puerto alternativo e inicie sesión con una cuenta real. Escriba un registro y abra un archivo que esté en un volumen. Ese par de comprobaciones es la prueba: el volcado se restauró, el volumen se restauró y ambos datos coinciden. Una prueba que sólo confirma que se muestra la página de inicio de sesión no demuestra nada sobre sus datos.

Elimine la pila de prueba cuando haya terminado correctamente:

docker compose down -v

Este es el único lugar donde -v es la opción correcta. En el directorio de producción, el mismo comando elimina los volúmenes que intenta proteger.

Cómo actualizar una pila de Compose

Lea las notas de la versión de cada versión entre la que ejecuta y la que quiere instalar, y busque en ellas las palabras breaking y migration. Los proyectos que no admiten saltar varias versiones principales lo indican allí. Una migración que no puede ejecutarse sólo informa del problema después de haber cambiado ya parte del esquema.

Anote lo que se está ejecutando ahora, antes de cambiar nada:

docker compose images
docker image inspect --format '{{index .RepoDigests 0}}' postgres:16.4

docker compose images muestra la imagen y la etiqueta que usa cada servicio en este momento. El digest es el único valor que identifica una imagen de forma exacta, porque una etiqueta puede apuntar a otro lugar en cualquier momento.

Tome la copia de seguridad de las secciones anteriores y cópiela fuera del servidor. Hágalo también para una versión de mantenimiento. Las actualizaciones sencillas son las que se dejan de preparar.

Después, fije la versión en el archivo de Compose, porque latest no es una versión:

services:
  db:
    image: postgres:16.4

Con image: postgres:latest, docker compose pull descarga lo que esa etiqueta indique hoy y no hay forma de saber qué se estaba ejecutando ayer. Una etiqueta fijada convierte la actualización en una edición de una línea que puede revisar en git diff y revertir con otra edición. Fije la imagen de la aplicación de la misma forma y tome la versión exacta de la página de versiones del proyecto.

Descargue las imágenes y vuelva a crear los contenedores:

docker compose pull
docker compose up -d --wait

docker compose up -d compara el archivo con los contenedores en ejecución y vuelve a crear sólo los servicios cuya imagen o configuración haya cambiado. No modifica los volúmenes con nombre, por lo que el contenedor nuevo se inicia con los datos existentes. Ese es el objetivo del procedimiento y también el riesgo, porque el primer arranque de la nueva versión suele ser cuando se ejecuta la migración del esquema.

Observe el proceso:

docker compose ps
docker compose logs -f --tail=100 app

Un contenedor que ha fallado muestra Exited (1) en la columna STATUS de docker compose ps, y el motivo aparece en las últimas líneas de su registro. Los errores de migración son visibles allí y no suelen aparecer en ningún otro sitio. Cuando los registros se estabilicen, inicie sesión y use la aplicación durante un minuto.

Si docker compose pull se detiene con no space left on device, la causa habitual son las capas antiguas de la imagen. Purgar las imágenes de Docker no utilizadas recupera ese espacio. Haga la limpieza después de comprobar que la actualización funciona, no antes, porque esas capas antiguas son las que necesita una reversión rápida.

Cómo volver atrás cuando la actualización falla

Hay dos casos y su coste es muy diferente. Si la nueva versión no cambió el esquema, la reversión requiere una sola línea: vuelva a poner el tag anterior en el archivo compose y ejecute docker compose up -d. El contenedor se reemplaza, los volúmenes permanecen donde están y el código anterior lee los datos que escribió.

Si la nueva versión migró el esquema, el código anterior ya no puede leerlo. Las migraciones están diseñadas para ejecutarse hacia delante y la mayoría de los proyectos no incluye ningún script de downgrade. Por eso, la versión anterior se inicia y falla en la primera consulta que accede a una columna cuyo nombre cambió o que se eliminó, con errores del tipo ERROR: column "avatar_url" does not exist. La forma de volver atrás es usar el dump que creó antes de descargar la nueva versión: vuelva a poner el tag anterior, retire el volumen de la base de datos, vuelva a crearlo vacío, restaure el dump y arranque el servicio. Sin ese dump no hay ninguna forma de volver atrás. Esa es precisamente la razón por la que la copia de seguridad se crea antes de descargar la nueva versión.

Las versiones principales de Postgres son el caso más delicado. Sorprenden porque el fallo aparece durante la actualización y no durante la reversión. El formato en disco cambia con cada versión principal. Cambie postgres:16.4 por postgres:17.2, ejecute docker compose up -d y el nuevo servidor se negará a iniciarse:

FATAL:  database files are incompatible with server
DETAIL:  The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.2.

La imagen no ejecuta pg_upgrade por usted. La ruta admitida dentro de una pila de Compose es crear el dump, reemplazar y restaurar: cree el dump mientras la versión anterior siga funcionando, docker compose down, elimine el volumen de la base de datos, establezca el nuevo tag, ejecute docker compose create para crear un directorio de datos vacío, inicie la base de datos, restaure el dump e inicie el resto de los servicios. Conserve el dump anterior hasta que la nueva versión principal haya gestionado tráfico real durante un día. Las actualizaciones menores dentro de una misma versión principal, de 16.4 a 16.9, no requieren nada de esto porque el formato es estable entre ellas y el contenedor simplemente se inicia.

¿Las instantáneas de VPS son una copia de seguridad?

Son un complemento de una copia de seguridad, y ambas fallan de maneras diferentes. Una instantánea copia todo el disco en el hipervisor, por lo que permite restaurar toda la máquina en minutos, incluidos los elementos cuya copia de seguridad olvidó hacer. Es la herramienta adecuada para una tarea concreta: una actualización rompió el servidor y quiere devolverlo al estado que tenía hace veinte minutos.

Es una herramienta poco adecuada para todo lo demás. La granularidad es la máquina completa, por lo que recuperar una tabla eliminada implica restaurar un servidor completo en algún lugar y extraer la tabla de él. La retención suele ser breve. Normalmente, las copias permanecen en la misma cuenta del proveedor que el servidor, por lo que perder la cuenta hace que el servidor y sus instantáneas desaparezcan a la vez. Además, una instantánea de una máquina en ejecución captura la base de datos durante una escritura, por lo que la base de datos realiza una recuperación tras un fallo en el primer arranque y se pierde cualquier transacción que todavía estuviera en curso.

Use ambas. La instantánea es el botón para deshacer durante una ventana de actualización. El volcado es la copia que sobrevive a la eliminación de una cuenta. cómo se diferencian las instantáneas y las copias de seguridad explica qué fallos cubre realmente cada una. Ese mismo directorio de copias de seguridad también convierte mover una pila a un VPS nuevo en una tarea rutinaria, en lugar de obligarle a reconstruirla de memoria.

Qué puede fallar y qué verá

La opción de volúmenes en down. docker compose down -v elimina los volúmenes con nombre que declara el archivo, y Compose lo confirma con una línea que contiene Volume myapp_db_data Removed. No hay forma de deshacerlo. docker compose down sin opciones los conserva. Escriba la forma larga, docker compose down --volumes, para que la opción destructiva sea una palabra que deba escribir de forma explícita.

Un volcado sin la cadena mágica. pg_restore: error: did not find magic string in file header indica que el archivo no es un archivo comprimido. La causa habitual es que falte -T en docker compose exec, porque, con un TTY conectado, el flujo se traduce de camino al shell y el volcado binario llega dañado. Genere de nuevo el volcado con -T y compruebe los primeros cinco bytes con head -c 5.

Una contraseña que no cambia. FATAL: password authentication failed for user "appuser" después de una restauración indica que .env y el directorio de datos proceden de momentos diferentes. La imagen establece esa contraseña sólo cuando crea un directorio de datos vacío, por lo que editar .env después no cambia nada dentro de la base de datos. Restaure el .env correspondiente o cambie la contraseña dentro de la base de datos con ALTER USER.

Un segundo volumen vacío. Docker crea un volumen bajo demanda, por lo que docker run -v myapp_upload:/data, si falta s, escribe en un volumen nuevo y vacío, y devuelve un resultado correcto. docker volume ls muestra entonces ambos nombres; uno de ellos no contiene nada. Copie los nombres de volumen desde docker volume ls en lugar de escribirlos de memoria.

Una restauración dirigida a producción. Ejecutar los comandos de restauración en /srv/myapp en lugar de /srv/myapp-restore sobrescribe los datos activos con la copia de seguridad, y los comandos son idénticos en ambos lugares. Compruebe pwd antes de cada comando de restauración y mantenga la prueba en su propio directorio.

FAQ

¿docker compose down elimina mis datos?

No. docker compose down elimina los contenedores y la red predeterminada, pero no modifica los volúmenes con nombre ni los montajes bind. docker compose down -v elimina los volúmenes con nombre que declara el archivo, y esa operación es permanente. Los montajes bind son directorios del host, por lo que Compose nunca los elimina. Si quiere detener los servicios durante una copia de seguridad sin modificar nada más, use docker compose stop.

¿Puedo copiar el directorio de datos de Postgres en lugar de ejecutar pg_dump?

Sólo con el contenedor detenido. Mientras el servidor está en ejecución, sus archivos cambian y la copia puede contener una mezcla de estados que no se pueda restaurar correctamente. Una copia a nivel de archivo también está vinculada a una versión mayor concreta de Postgres, por lo que no se iniciará con otra versión. Detenga el contenedor, archive el volumen, vuelva a iniciarlo y considere el resultado una vía rápida de reconstrucción, no su única copia de seguridad. El volcado es la copia portable y la que debe restaurar.

¿Cómo actualizo Postgres a una nueva versión mayor en Compose?

Cambiar el tag no es suficiente. El nuevo servidor se niega a iniciarse con el directorio de datos antiguo y registra The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.2. Ejecute pg_dump mientras la versión antigua siga en ejecución. Después, ejecute docker compose down, elimine el volumen de la base de datos, establezca el nuevo tag, ejecute docker compose create para crear un volumen vacío y nuevo, inicie la base de datos y restaure el volcado en ella. Conserve el volcado antiguo hasta que la nueva versión haya gestionado tráfico real.

¿Con qué frecuencia deben ejecutarse las copias de seguridad y cuánto tiempo debo conservarlas?

Adapte el intervalo a la cantidad de trabajo que esté dispuesto a rehacer. Una copia nocturna es adecuada para una pila personal o de un equipo pequeño, junto con otra copia manual inmediatamente antes de cualquier actualización. Para la retención, conserve suficiente historial para cubrir daños que no haya detectado de inmediato. Una tabla dañada que se detecta el viernes no se soluciona con la copia del jueves por la noche. restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune es una política inicial razonable. Sea cual sea el calendario, restaure una copia una vez por trimestre. Hasta que lo haya hecho, no tiene copias de seguridad: tiene archivos.

¿Tengo que detener toda la pila para hacer una copia de seguridad?

Normalmente no. El volcado de la base de datos es coherente mientras el servidor está en ejecución, por lo que la base de datos no necesita tiempo de inactividad. La cuestión real son los volúmenes. Si la aplicación sólo añade archivos, como en un directorio de cargas, un archivado en caliente es suficientemente seguro. Si reescribe archivos en el mismo lugar, detenga ese servicio durante el tiempo que dure la copia con docker compose stop app y vuelva a iniciarlo después. Detener la aplicación mientras la base de datos sigue en ejecución suele ser la ventana segura más corta que puede establecer.