Una copia de seguridad es una pregunta. Una restauración la responde.

Mantenga el primer ejercicio deliberadamente pequeño

Este ejercicio crea una base de datos de notas de juguete y un archivo adjunto, captura ambos y luego los restaura en una base de datos y un directorio nuevos. Use una máquina Linux desechable con servidor PostgreSQL 17 y utilidades cliente correspondientes, Bash y GNU coreutils. No debe contener datos de producción ni tener conexión con aplicaciones de producción, correo saliente o tareas programadas. Use únicamente el archivo creado en este ejercicio.

Los comandos asumen un rol de base de datos preconfigurado, no superusuario, llamado restore_lab, con permiso para crear bases de datos de prueba, y un inicio de sesión del sistema operativo del mismo nombre que pueda autenticarse localmente. El socket de PostgreSQL es /var/run/postgresql en el puerto 5432. Haga que el administrador prepare esa cuenta en el entorno desechable; esta guía no modifica las reglas de acceso a la base de datos. Verifique el endpoint antes de crear cualquier cosa:

psql -h /var/run/postgresql -p 5432 -U restore_lab -d postgres -c '\conninfo' &&
pg_dump --version &&
pg_restore --version

Deténgase si el host, la cuenta o la versión no son los esperados. Mantenga los clientes y el servidor en la misma versión mayor para este primer simulacro. pg_dump no puede volcar un servidor más nuevo que su propia versión mayor, y un destino de restauración más antiguo no suele estar garantizado como compatible. Consulte límites de versión de pg_dump. Ejecute cada bloque por separado y deténgase ante un error. Los protectores && de los bloques pegados evitan que los comandos posteriores se ejecuten tras un fallo; nunca continúe al siguiente bloque después de que falle la creación de una base de datos o un directorio.

Cree un registro y su archivo correspondiente

Los nombres offvps_restore_source y offvps_restore_target deben estar sin usar. Una base de datos existente es motivo para detenerse y elegir un nuevo ejercicio aislado, no para eliminarla. Cree un espacio de trabajo nuevo en el sistema de archivos y la base de datos de origen:

umask 077 &&
lab=$(mktemp -d "$PWD/offvps-restore.XXXXXX") &&
mkdir "$lab/source" "$lab/source/uploads" "$lab/bundle" "$lab/restore" &&
createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_source

El espacio de trabajo nuevo evita sobrescribir un directorio existente. mktemp crea un directorio único; createdb crea una base de datos nueva a partir de la plantilla seleccionada. Guarde estos dos marcadores:

psql -X -v ON_ERROR_STOP=1 -h /var/run/postgresql -p 5432 \
  -U restore_lab -d offvps_restore_source \
  -c "CREATE TABLE notes (
        id integer PRIMARY KEY,
        body text NOT NULL,
        attachment text NOT NULL
      );
      INSERT INTO notes VALUES (1, 'restore-marker-01', 'marker.txt');" &&
printf '%s\n' 'restore-marker-01' > "$lab/source/uploads/marker.txt"

El registro indica qué archivo pertenece a la nota, y ambos contienen el mismo marcador. Esto hace visibles un adjunto faltante o una copia no coincidente. -X evita la configuración personal de inicio de psql y ON_ERROR_STOP se detiene ante un error SQL; consulte opciones de scripting de psql. No hay ninguna aplicación escribiendo en este conjunto de datos de juguete.

Capture la base de datos y los archivos como un único conjunto de recuperación

pg_dump -h /var/run/postgresql -p 5432 -U restore_lab \
  --format=custom --file="$lab/bundle/notes.dump" offvps_restore_source &&
cp -a "$lab/source/uploads" "$lab/bundle/uploads" &&
pg_restore --list "$lab/bundle/notes.dump"

El archivo en formato personalizado es leído por pg_restore; un volcado SQL simple sigue un procedimiento de restauración diferente. Listar el archivo ayuda a confirmar que las entradas esperadas de tabla y datos están presentes. Un volcado de base de datos consistente no sincroniza automáticamente las cargas externas. Para una aplicación real, use su procedimiento documentado de mantenimiento o pausa de escritura para que el árbol de archivos y la base de datos describan el mismo punto en el tiempo. El ejercicio de juguete ya está en reposo.

Registre la versión de la base de datos, la versión de la aplicación, el inicio/fin de la captura y la ruta de archivos junto al paquete. Guarde las credenciales reales por separado bajo controles de acceso adecuados. Un volcado por base de datos no captura roles globales ni tablespaces; un plan de recuperación real también debe contemplarlos. El alcance se describe en la guía de volcado SQL de PostgreSQL.

Restaure en destinos nuevos sin limpiar uno existente

createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_target &&
pg_restore -h /var/run/postgresql -p 5432 -U restore_lab \
  --dbname=offvps_restore_target --no-owner --no-acl \
  --single-transaction "$lab/bundle/notes.dump" &&
mkdir "$lab/restore/uploads" &&
cp -a "$lab/bundle/uploads/." "$lab/restore/uploads/"

La base de datos de destino se crea vacía. La restauración omite intencionadamente --clean, que podría eliminar objetos existentes. --single-transaction hace que esta restauración de base de datos pequeña se realice correctamente como una unidad o se detenga sin aplicar sus cambios parciales; no se puede combinar con trabajos paralelos. --no-owner y --no-acl simplifica la propiedad para este rol de prueba, por lo que este simulacro no valida los roles ni permisos de producción de la aplicación. Consulte pg_restore.

La copia de archivos apunta al nuevo directorio de restauración, dejando intacto el origen. GNU cp -a intenta preservar los atributos de los archivos; inspeccione la propiedad y el acceso para la cuenta que ejecutará una aplicación real. Copiar bytes no es una prueba de los permisos de la aplicación. Consulte la opción de archivo de cp.

Verifique la relación, no solo los códigos de salida

psql -X -h /var/run/postgresql -p 5432 -U restore_lab \
  -d offvps_restore_target -c "SELECT id, body, attachment FROM notes;" &&
cat "$lab/restore/uploads/marker.txt"

Los resultados esperados son una fila con ID 1, cuerpo restore-marker-01 y adjunto marker.txt, más un archivo que contiene restore-marker-01. Compruebe que el origen aún contiene su fila y archivo originales. Para su aplicación real, apunte también una instancia aislada a la base de datos restaurada y al directorio de carga, abra registros representativos, obtenga un adjunto y pruebe los permisos de inicio de sesión previstos. Mantenga contenidos los callbacks, el correo y los trabajos mientras lo hace.

Anote lo que demostró y lo que queda pendiente

Los resultados esperados anteriores son criterios del ejercicio, no resultados ya observados por OffVPS. Como el primer simulacro mantiene todos los archivos en una sola máquina, no ofrece protección frente a la pérdida de esa máquina. Un plan real necesita una copia protegida en un dominio de fallo separado, claves de descifrado utilizables, retención y una ruta de recuperación probada. Revise los nombres exactos de las bases de datos desechables y el directorio antes de la limpieza posterior; mantenga la producción fuera de ese proceso.

Repita el ejercicio tras cambios importantes y registre los fallos con el mismo cuidado que los éxitos. Un servicio de respaldo opcional no demuestra el tiempo de recuperación de su aplicación. Continúe con planificar una tarea programada cuando esté listo para automatizar la captura, manteniendo un simulacro de restauración separado.