Una copia de seguridad que nunca se ha restaurado es una hipótesis, no una red de seguridad. En una aplicación pequeña que ejecuta PostgreSQL con volúmenes Docker, la distancia entre «hacemos copias» y «podemos recuperar el servicio» suele descubrirse en el peor momento posible. Este artículo describe un simulacro de restauración que puede ejecutarse en un portátil o en una máquina virtual de repuesto, explica las decisiones que lo sustentan y es franco sobre lo que un simulacro así no puede demostrar. Es deliberadamente acotado: una base de datos, una aplicación, volúmenes Docker y ningún modelo operativo en la nube.
Empiece por nombrar de qué se quiere recuperar
Un simulacro necesita un escenario; de lo contrario, no comprueba nada concreto. Para una pila pequeña, tres escenarios cubren la mayoría de las pérdidas realistas:
- Volumen perdido o corrupto. Falla el disco del host, se elimina el volumen por error o una migración defectuosa daña los datos y se quiere volver al estado anterior.
- Host perdido. La máquina entera desaparece y hay que reconstruir a partir de las copias y de la configuración de Compose.
- Error lógico. Alguien ejecutó una sentencia destructiva contra producción. La base de datos está sana, pero los datos son incorrectos.
El método de copia determina cuáles de estos escenarios puede superar realmente. La documentación de PostgreSQL describe tres enfoques fundamentalmente distintos para respaldar datos: volcado SQL, copia a nivel de sistema de archivos y archivado continuo, cada uno con sus propias ventajas e inconvenientes (https://www.postgresql.org/docs/17/backup.html). La documentación subraya que el procedimiento es sencillo en principio, pero que hace falta entender bien las técnicas y los supuestos subyacentes. El simulacro es la forma de contrastar esos supuestos con su propia configuración.
Antes de empezar, escriba en lenguaje llano dos objetivos: cuántos datos recientes podría tolerar perder y cuánto tiempo podría estar caído el servicio. Las fuentes no ofrecen cifras para ello, y este artículo tampoco; son decisiones de negocio. La tarea del simulacro es medir lo que su configuración actual entrega realmente, para poder compararlo con lo que usted desea.
Elija el método de copia que ejercitará el simulacro
Para una aplicación pequeña, la elección realista suele estar entre un volcado lógico con pg_dump y una configuración más avanzada de archivado continuo. El simulacro debe probar el método que usted ejecuta de verdad.
Volcados lógicos con pg_dump. Según la referencia de pg_dump, realiza copias consistentes aunque la base de datos esté en uso concurrente, y no bloquea a otros usuarios, ni lectores ni escritores (https://www.postgresql.org/docs/17/app-pgdump.html). Eso lo hace práctico para un sistema pequeño en funcionamiento. Tiene límites que conviene conocer:
- Vuelca una sola base de datos. Los roles y los espacios de tablas son objetos globales compartidos por todo el clúster, y la documentación remite a pg_dumpall para respaldarlos o para respaldar un clúster completo. Si su aplicación depende de roles concretos y solo vuelca esa base de datos, una restauración en un servidor nuevo puede fallar por propiedad o permisos. Es una de las sorpresas más habituales que destapa un simulacro.
- La salida puede ser un script o un formato de archivo. Los volcados de script en texto plano se restauran pasándolos a psql; los formatos de archivo deben restaurarse con pg_restore.
- El formato personalizado (-Fc) y el formato de directorio (-Fd) son los más flexibles: permiten seleccionar y reordenar los elementos archivados, admiten restauración en paralelo y están comprimidos por defecto. El formato de directorio es el único que admite volcados en paralelo.
Para un simulacro, suele convenir más el formato personalizado o el de directorio, porque pg_restore permite examinar un archivo y elegir qué restaurar, lo cual es útil si solo se quieren verificar primero unas pocas tablas.
Archivado continuo y recuperación en un punto en el tiempo. El índice del capítulo de la documentación incluye, dentro de este enfoque, el archivado de WAL, las copias base, la recuperación desde un archivo continuo y las líneas de tiempo (https://www.postgresql.org/docs/17/backup.html). Es el camino para recuperar a un instante justo anterior a un error lógico, pero también implica más maquinaria que configurar y, sobre todo, más maquinaria que probar. Si lo usa, su simulacro debe incluir una recuperación efectiva, no solo confirmar que los archivos de archivado se van acumulando.
Copia a nivel de sistema de archivos. Copiar los ficheros de un volumen resulta tentador con Docker, y es uno de los tres enfoques que menciona la documentación. La contrapartida es que hay que estar seguro de que la copia esté en un estado del que PostgreSQL pueda recuperarse; lea la sección sobre copias a nivel de sistema de archivos antes de confiar en una copia en bruto de un directorio de datos en funcionamiento, y haga que su simulacro demuestre que funciona en lugar de darlo por supuesto.
Construya un entorno de pruebas que no pueda tocar producción
La regla de diseño más importante de un simulacro de restauración es el aislamiento. Debe tener la certeza de que un error tipográfico no puede dirigir una restauración contra la base de datos real.
Medidas prácticas:
- Use un nombre de proyecto de Compose distinto para que los nombres de contenedores, redes y volúmenes no colisionen con producción. Los volúmenes son el mecanismo de almacenamiento que cubre la documentación de Docker para persistir los datos de los contenedores (https://docs.docker.com/engine/storage/volumes/); un proyecto de pruebas debe recibir sus propios volúmenes recién creados, en lugar de reutilizar o montar el de producción.
- No publique la base de datos de pruebas en el mismo puerto del host que producción. Mejor aún, no publique ningún puerto y ejecute los comandos de verificación dentro de la red del contenedor.
- Use credenciales claramente distintas y un nombre de host de base de datos diferente en la configuración de pruebas, de modo que una conexión mal dirigida falle de forma evidente.
- Ejecute el simulacro desde una máquina o un usuario que no tenga credenciales de producción en su entorno. La documentación de pg_dump señala que los valores de conexión por defecto pueden provenir de variables de entorno como PGDATABASE, lo que recuerda que los ajustes ambientales pueden elegir el destino en silencio.
Si su producción usa una etiqueta concreta de imagen de PostgreSQL, utilice la misma en el simulacro. Restaurar en una versión mayor distinta es otra prueba (una prueba de actualización), y mezclar ambas dificulta interpretar los fallos.
Ejecute el simulacro paso a paso
Esta es una secuencia para el camino con pg_dump. Adapte los comandos a su propio archivo de Compose; importa más la estructura que la sintaxis exacta.
1. Obtenga la copia como lo haría en un incidente real. No la tome del directorio local del host de producción si su plan real es recuperarla desde otra máquina o ubicación de almacenamiento. Si recuperarla exige una credencial o a una persona que está de vacaciones, ha encontrado un modo de fallo. 2. Inicie un contenedor PostgreSQL de pruebas vacío con un volumen nuevo y vacío. 3. Cree los roles que espera la aplicación antes de restaurar, o restaure los objetos globales si los capturó con pg_dumpall. 4. Restaure. Para un volcado en texto plano, pase el script a psql. Para archivos personalizados o de directorio, use pg_restore. La documentación de pg_dump describe ambos caminos. Lea la salida en lugar de comprobar solo el código de salida: para los formatos de archivo, la documentación indica que conviene examinar la salida en busca de advertencias, y los errores de restauración por objetos ausentes pueden pasar fácilmente inadvertidos entre el texto que se desplaza. 5. Inspeccione el archivo antes de confiar en él. La documentación señala que los volcados que no son de texto plano pueden inspeccionarse con la opción --file de pg_restore, que escribe el SQL en lugar de ejecutarlo. Es también una medida de seguridad: la documentación advierte de que restaurar un volcado hace que el destino ejecute código arbitrario elegido por los superusuarios de origen, y que las restauraciones parciales no limitan eso. Para sus propias copias de su propio servidor el riesgo es bajo, pero si una copia pudo pasar por manos no fiables, inspecciónela primero. 6. Cronometre la restauración de principio a fin, incluyendo la recuperación de la copia y la preparación de roles. Registre el número. Es su línea base medida, no una estimación. 7. Arranque la aplicación contra la base de datos de pruebas y ejercítela, en lugar de detenerse en «la base de datos arrancó».
Verifique que los datos restaurados son realmente utilizables
Una restauración que termina sin errores aún puede producir un sistema inutilizable. La verificación debe tener varias capas.
Comprobaciones estructurales. Compare la lista de tablas, índices y extensiones con la de producción. La documentación de pg_dump incluye una advertencia sobre las extensiones: al volcar extensiones seleccionadas, no hay garantía de que el resultado se restaure por sí solo en una base de datos limpia, porque las dependencias no se incluyen automáticamente. Incluso con un volcado completo, confirme que las extensiones que su aplicación necesita estén disponibles en la imagen en la que restaura.
Comprobaciones de contenido. Elija unas pocas tablas y compare recuentos de filas o marcas de tiempo de registros recientes con lo que espera. El objetivo es confirmar que la copia es tan reciente como usted cree. Una tarea nocturna que lleva semanas fallando en silencio parecerá correcta hasta que se compruebe la fila más nueva.
Objetos grandes y secuencias. Si su aplicación almacena objetos grandes, tenga en cuenta que la documentación de pg_dump dice que se incluyen por defecto, salvo cuando se especifican opciones como --schema, --table o --schema-only. Si alguien estrechó después el comando de volcado con un filtro de tablas, los objetos grandes podrían desaparecer sin avisar. Del mismo modo, los valores de las secuencias se vuelcan junto con los datos; compruebe que las nuevas inserciones tras la restauración no colisionen con claves existentes.
Comprobaciones de aplicación. Inicie sesión, cree un registro, léalo de vuelta, ejecute la herramienta de migraciones en modo de simulación o de estado. Esto detecta desajustes entre el esquema restaurado y la versión de la aplicación de su repositorio.
Modos de fallo que este tipo de simulacro tiende a exponer
Son patrones que conviene buscar. Son ayudas de razonamiento, no afirmaciones sobre ningún incidente concreto.
- Copias que existen pero no pueden recuperarse porque residen solo en el host que falló.
- Globales ausentes. El volcado de la base de datos se restaura, pero faltan roles, contraseñas o espacios de tablas, porque pg_dump cubre una sola base de datos y pg_dumpall cubre los objetos de todo el clúster.
- Herramienta equivocada para el formato. Intentar pasar un archivo en formato de archivo a psql, o esperar que pg_restore lea un script plano.
- Volcados parciales silenciosos. Opciones que limitan el alcance del volcado y producen un fichero de aspecto normal pero sin parte de los datos.
- Deriva de versiones. La imagen de pruebas difiere de la de producción, o el código de la aplicación espera un esquema más reciente que el contenido en la copia.
- Procedimiento de recuperación sin probar para el archivado continuo. Los archivos de archivado se acumulan durante meses, pero nadie ha realizado una recuperación ni ha entendido las líneas de tiempo, de modo que el primer intento ocurre durante una caída.
- Supuestos sobre los volúmenes Docker. Creer que, por estar los datos en un volumen con nombre, ya tienen copia de seguridad. Un volumen es almacenamiento persistente en el host, no una copia en otro lugar.
Una lista de comprobación realista
Úsela como plantilla de partida y adáptela.
Antes del simulacro: - Escenario por escrito, y la pérdida de datos y el tiempo de inactividad que se desea lograr. - Proyecto de Compose de pruebas con nombre, volúmenes y credenciales distintos y sin puertos compartidos. - Misma etiqueta de imagen de PostgreSQL que producción.
Durante el simulacro: - Copia recuperada por la misma ruta que usaría una recuperación real. - Roles y globales tratados de forma explícita. - Salida de la restauración leída por completo, con las advertencias anotadas. - Tiempo total transcurrido registrado. - Comprobaciones estructurales, de contenido y de aplicación completadas.
Después del simulacro: - Cada sorpresa anotada, con un responsable y una corrección. - Comandos de copia y restauración actualizados en el manual de operaciones tal como se ejecutaron. - Próxima fecha de simulacro fijada, y además activada por cambios como una actualización de PostgreSQL, una nueva extensión o un cambio en las herramientas de copia.
Límites de lo que demuestra un simulacro
Sea honesto sobre las fronteras. Un simulacro con un conjunto de datos pequeño dice poco sobre el tiempo de restauración de uno grande; el capítulo de PostgreSQL incluye una sección sobre el manejo de bases de datos grandes por una razón. Una restauración en un entorno de pruebas tampoco puede demostrar que el disco, la red o los permisos del host de producción se comportarán igual bajo una tensión real. Un simulacro superado muestra que esta copia, este día, se restauró con estos pasos. No garantiza que la copia de mañana sea buena, y por eso la comprobación de frescura del contenido y un calendario recurrente importan más que cualquier ejecución aislada.
Este artículo se apoya únicamente en la documentación de copias de seguridad y de pg_dump de PostgreSQL y en la documentación de volúmenes de Docker. No cubre el cifrado de copias, la política de retención, los servicios de bases de datos gestionados ni las obligaciones de cumplimiento normativo, y las fuentes proporcionadas no respaldan afirmaciones concretas en esos ámbitos. Trate los pasos anteriores como un marco que adaptar y valide cada comando con la documentación de sus versiones exactas de PostgreSQL y Docker.
Haga del simulacro una rutina
El valor de un simulacro de restauración se acumula cuando resulta aburrido. Automatice el entorno de pruebas para que un simulacro sea un solo comando, mantenga el manual de operaciones en el mismo repositorio que su archivo de Compose y repita el simulacro cada vez que cambie algo en la capa de datos. El primer simulacro casi con seguridad encontrará algo. Ese es el objetivo: prefiere encontrarlo en una tarde tranquila y no durante un incidente.