Fundamentos de Copia de Seguridad y Restauración
La copia de seguridad y restauración es la disciplina fundamental sobre la que se asientan todas las demás capacidades de recuperación de PostgreSQL, desde deshacer un único DELETE erróneo hasta poner en marcha un clúster en otra región.
Esta página construye el modelo mental de lo que realmente captura una copia de seguridad, cómo una restauración convierte esa captura de nuevo en una instancia en ejecución, y por qué el método que elijas establece un límite estricto a lo que el trabajo de recuperación posterior puede lograr.
Resumen
- Una copia de seguridad es una representación capturada y autoconsistente del estado del clúster que un proceso de restauración puede convertir de nuevo en una instancia de PostgreSQL en ejecución.
- Por Qué Importa: Cada objetivo de recuperación posterior, desde una tabla eliminada hasta una región perdida, está limitado por lo que tus copias de seguridad capturaron realmente y la rapidez con la que se pueden reproducir.
- Conceptos Clave: copia de seguridad lógica, copia de seguridad física, punto de consistencia, registro de escritura anticipada (WAL), restauración, catálogo de copias de seguridad.
- Cuándo Usar: Cada clúster de producción necesita una estrategia de copia de seguridad implementada antes de la primera migración de esquema y antes de que llegue el primer byte de datos del cliente.
- Limitaciones / Compensaciones: Una copia de seguridad que nunca se ha restaurado es solo una hipótesis, y el método que elijas intercambia la velocidad de restauración por la granularidad de restauración.
- Temas Relacionados: recuperación a punto en el tiempo, niveles de recuperación ante desastres, archivo WAL, replicación en streaming.
Fundamentos
En su forma más simple, una copia de seguridad es una copia de datos tomada en un momento conocido que una restauración puede usar para recrear ese momento en una instancia diferente o posterior.
PostgreSQL admite dos formas fundamentalmente diferentes de hacer esa copia, y la distinción entre ellas da forma a casi todas las decisiones en esta sección de la documentación.
Una copia de seguridad lógica, producida por pg_dump o pg_dumpall, pide a la base de datos en ejecución que describa sus objetos y datos como sentencias SQL o un archivo de esa intención, de modo que la restauración reproduzca esas sentencias contra una instancia de PostgreSQL nueva, posiblemente diferente.
Una copia de seguridad física, producida por pg_basebackup o una herramienta como pgBackRest, en su lugar copia los archivos de datos reales en el disco, de modo que la restauración coloca esos archivos de nuevo y deja que la maquinaria de recuperación ante fallos propia de PostgreSQL los lleve a un estado consistente.
Dado que una copia de seguridad física es solo una copia de archivos que se están escribiendo activamente, necesita una forma de garantizar que la copia sea internamente coherente, incluso si diferentes archivos se copiaron en instantes ligeramente diferentes.
Esa garantía proviene del registro de escritura anticipada (WAL), el registro de solo anexión de PostgreSQL de cada cambio, que la instancia restaurada reproduce hacia adelante desde el momento en que comenzó la copia de seguridad hasta que la copia alcanza un estado consistente.
Una copia de seguridad lógica evita ese problema por completo al pedir a la base de datos que produzca una instantánea autoconsistente a nivel de SQL, utilizando la misma maquinaria MVCC que otorga a cualquier consulta de larga duración una vista estable de los datos.
El punto de consistencia es el momento en que una copia de seguridad se vuelve confiable: para un volcado lógico es el instante en que se tomó la instantánea, y para una copia de seguridad física es el punto después de que la reproducción de WAL ponga la copia de archivos al día hasta un estado coherente.
La restauración, en ambos casos, no es una acción única sino una canalización de localizar la copia de seguridad, verificarla, cargarla o copiarla, y luego llevar a PostgreSQL a través de los pasos de recuperación necesarios que la devuelven a un estado de servicio.
Un catálogo de copias de seguridad es simplemente el registro de qué copias de seguridad existen, cuándo se tomaron y cómo recuperarlas, y sin uno, una copia de seguridad válida almacenada es indistinguible de una corrupta.
Mecánicas e Interacciones
Las herramientas de copia de seguridad física no necesitan realmente congelar el sistema de archivos ni detener las escrituras, porque PostgreSQL expone una API de bajo nivel que delimita la operación de copia y permite que WAL llene el hueco.
-- Forma conceptual de lo que pg_basebackup y pgBackRest hacen internamente
SELECT pg_backup_start('nightly-base', fast => true);
-- ... la herramienta externa copia los archivos de datos mientras las escrituras continúan ...
SELECT pg_backup_stop(); -- devuelve la posición final de WAL necesaria para reproducirLlamar a pg_backup_start no pausa el clúster; marca la posición de WAL donde comienza la copia de seguridad para que la recuperación sepa dónde debe comenzar la reproducción, y pg_backup_stop registra dónde debe terminar la reproducción para que la copia sea consistente.
Es por eso que una copia de seguridad física es inseparable de WAL: los archivos por sí solos son una mezcla inconsistente de diferentes momentos, y solo la reproducción de los segmentos de WAL generados durante la ventana de copia los convierte en una única instantánea coherente.
Una copia de seguridad lógica no tiene un hueco equivalente que llenar, porque pg_dump abre una transacción con una instantánea de lectura repetible y lee cada objeto a través de esa misma vista congelada, por lo que nada fuera del volcado en sí necesita ser reproducido.
Esa diferencia se traslada al comportamiento de restauración: restaurar una copia de seguridad física siempre reconstruye todo el clúster tal como existía en el punto de consistencia, mientras que restaurar una copia de seguridad lógica puede dirigirse a una sola tabla, un solo esquema o toda la base de datos, porque nunca fue más que una secuencia de operaciones SQL independientes.
Las copias de seguridad también interactúan con la replicación de una manera que sorprende a los recién llegados, porque una réplica en streaming no es una copia de seguridad en absoluto, solo una copia en movimiento continuo que aplica fielmente cada error que comete el primario, incluida una tabla eliminada o una fila corrupta.
Una réplica protege contra fallos de hardware, mientras que solo una copia de seguridad independiente, tomada y retenida según su propio calendario, protege contra errores del operador o corrupción lógica, y confundir las dos es una de las brechas más comunes en un clúster de lo contrario bien administrado.
El método de copia de seguridad que elijas también determina qué herramientas de recuperación posteriores pueden hacer con él, porque la recuperación a punto en el tiempo requiere una copia de seguridad base física más un archivo WAL continuo, y no se puede construir solo a partir de un volcado lógico.
Consideraciones Avanzadas y Aplicaciones
A escala, la elección del método de copia de seguridad se convierte tanto en una compensación económica y operativa como técnica, sopesando la precisión de la restauración frente al costo de almacenamiento y la complejidad operativa.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
Lógico (pg_dump) | Selectivo, portable entre versiones y plataformas | La restauración es lenta a escala de varios terabytes | Recuperación a nivel de objeto, migración entre versiones |
| Copia de seguridad base física | Restauración rápida de clúster completo, base para PITR | Todo o nada, necesita versión principal coincidente | Recuperación de clúster completo, arranque de réplica |
| Archivo WAL continuo | Permite la recuperación a cualquier punto en el tiempo | Inútil sin una copia de seguridad base para anclarlo | Deshacer errores recientes del operador con precisión |
| Instantánea de almacenamiento/volumen | Muy rápida de tomar y restaurar | Solo consistente ante fallos, no consistente a nivel de aplicación | Recuperación rápida emparejada con WAL para corrección |
Un clúster que ejecuta extensiones pgvector 0.8+ o PostGIS 3.5+ añade otra complicación, porque una restauración física trae automáticamente los binarios y datos de la extensión juntos, mientras que una restauración lógica requiere que la instancia de destino ya tenga instaladas versiones de extensión coincidentes antes de que el volcado se cargue limpiamente.
La retención de copias de seguridad es en sí misma una decisión arquitectónica, porque mantener solo el mínimo requerido por la política no deja margen para la corrupción descubierta lentamente, mientras que mantener todo indefinidamente convierte el costo de almacenamiento en una responsabilidad ilimitada.
El cifrado y el control de acceso pertenecen al diseño de la copia de seguridad desde el principio, no como una ocurrencia tardía, porque una copia de seguridad es funcionalmente una copia completa de los datos de producción que se encuentra en una ubicación que a menudo se examina menos que la base de datos principal.
La decisión más trascendental en todo este espacio es tratar la copia de seguridad y la restauración como un solo flujo de trabajo en lugar de dos, porque una ruta de restauración no probada no es un riesgo menor que ninguna copia de seguridad, es el mismo riesgo disfrazado.
Conceptos Erróneos Comunes
- "Una réplica es una copia de seguridad." Una réplica en streaming protege contra fallos de hardware y de nodo, pero replica fielmente eliminaciones, corrupción y migraciones erróneas, por lo que no puede sustituir a una copia de seguridad retenida de forma independiente.
- "Si el trabajo de copia de seguridad se completó con éxito, la copia de seguridad funciona." Que un trabajo de copia de seguridad finalice con estado cero solo demuestra que la copia se completó, no que los datos dentro de ella estén completos, sin corrupción o que se puedan restaurar bajo presión de tiempo.
- "Las copias de seguridad lógicas y físicas son intercambiables." Protegen contra diferentes modos de fallo y admiten diferentes operaciones de recuperación, por lo que la mayoría de los sistemas de producción necesitan ambas en lugar de elegir una.
- "Copias de seguridad más frecuentes siempre significan mejor protección." La frecuencia de las copias de seguridad solo limita su punto de recuperación para ese tipo de copia de seguridad, y sin archivo WAL entre medias, la frecuencia por sí sola no puede cerrar pequeños huecos de recuperación.
- "La velocidad de restauración no importa hasta que ocurre un incidente." La velocidad de restauración es una función del volumen de datos, el hardware y las herramientas que deben medirse de antemano, porque descubrirla durante una interrupción es el peor momento para aprenderla.
Preguntas Frecuentes
¿Cuál es la diferencia real entre una copia de seguridad lógica y una física?
Una copia de seguridad lógica describe los objetos y datos de la base de datos como operaciones a nivel de SQL que una instancia de destino reproduce, mientras que una copia de seguridad física copia los archivos reales en disco que PostgreSQL lee directamente.
¿Por qué no puedo simplemente depender de mi réplica en streaming en lugar de copias de seguridad?
- Una réplica aplica cada cambio que hace el primario, incluidos los errores.
- No ofrece protección contra una tabla eliminada, una migración errónea o corrupción lógica.
- Comparte el riesgo de infraestructura con el primario con mucha más frecuencia que una copia de seguridad almacenada de forma independiente.
¿Qué hace que una copia de seguridad física sea "consistente"?
La reproducción de los segmentos de WAL generados entre pg_backup_start y pg_backup_stop convierte la copia de archivos sin procesar, tomada en instantes ligeramente diferentes entre archivos, en una única instantánea coherente.
¿Bloquea pg_dump la base de datos mientras se ejecuta?
No, pg_dump toma una instantánea de lectura repetible y lee a través de esa vista congelada, por lo que los escritores y otros lectores continúan sin interrupción durante la duración del volcado.
¿Puedo restaurar una copia de seguridad lógica en una versión anterior de PostgreSQL?
Generalmente sí para versiones razonablemente cercanas, lo cual es una de las principales fortalezas de la copia de seguridad lógica, pero siempre prueba la restauración contra la versión de destino real en lugar de asumir compatibilidad.
¿Por qué las copias de seguridad necesitan su propia política de retención separada de WAL?
La retención de WAL determina hasta dónde puede llegar PITR, mientras que la retención de copias de seguridad determina cuántos puntos de recuperación completos independientes existen, y confundir las dos deja huecos cuando se recorta alguna de ellas.
¿Es una instantánea del sistema de archivos o del volumen una copia de seguridad válida?
Solo si se combina con la reproducción de WAL para alcanzar la consistencia de la aplicación, porque una instantánea por sí sola es consistente ante fallos, lo que significa que parece que la instancia se apagó en lugar de detenerse limpiamente.
¿Qué es un "catálogo de copias de seguridad" y lo necesito?
Sí, es el registro de qué copias de seguridad existen, dónde se encuentran y cómo recuperarlas, y herramientas como pgBackRest mantienen uno automáticamente para que los operadores nunca tengan que adivinar durante un incidente.
¿Cómo afecta el ecosistema de extensiones (pgvector, PostGIS) a la elección de la copia de seguridad?
Las copias de seguridad físicas transportan los datos y binarios de la extensión juntos automáticamente, mientras que las restauraciones lógicas requieren que la instancia de destino ya tenga instaladas versiones de extensión coincidentes antes de que el volcado se cargue.
¿Por qué se considera arriesgada una copia de seguridad no probada en lugar de simplemente "no probada"?
Los modos de fallo que rompen una restauración, como un segmento WAL faltante o un archivo corrupto, son silenciosos hasta el momento en que realmente necesitas la copia de seguridad, momento en el cual no queda tiempo para descubrirlos.
¿Cambia el cifrado de las copias de seguridad la forma en que funciona la restauración?
Añade un paso de descifrado antes de que se pueda leer la copia o el volcado, por lo que las herramientas de restauración y el acceso a las claves deben planificarse y practicarse con el mismo cuidado que el proceso de copia de seguridad en sí.
¿Dónde encajan la recuperación a punto en el tiempo y la recuperación ante desastres en relación con esta página?
La recuperación a punto en el tiempo se construye sobre una copia de seguridad base física más un archivo WAL continuo, y los niveles de recuperación ante desastres describen cómo las opciones de copia de seguridad y replicación se combinan para cumplir con los objetivos de RTO y RPO definidos por el negocio.
Relacionados
- Conceptos Básicos de Copia de Seguridad - la receta concreta lógica vs. física que el modelo mental de esta página soporta
- pg_dump & pg_restore - detalles de formato y paralelismo para copias de seguridad lógicas
- Verificación de Copias de Seguridad - probar que la ruta de restauración realmente funciona
- Conceptos Básicos de PITR - cómo una copia de seguridad física más WAL se convierte en una línea de tiempo que se puede rebobinar
- Conceptos Básicos de DR - cómo la estrategia de copia de seguridad alimenta los objetivos de RPO y RTO
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, y PostGIS 3.5+.