Una base de datos tiene una réplica actualizada y, aun así, puede perder una tabla por un borrado accidental. Si ese borrado se replica, ambas copias reflejan el mismo error. Disponer de otra instancia no responde por sí solo a la pregunta de cómo volver al estado anterior.
Backup y réplica son mecanismos que pueden complementarse. La decisión debe partir del fallo que quieres cubrir, del estado al que necesitas volver y de los pasos necesarios para recuperar el servicio completo.
La réplica mantiene otra representación del estado
Una réplica recibe cambios del origen mediante el mecanismo configurado. Según su tipo y capacidades, puede utilizarse para lecturas, continuidad o promoción cuando falla el nodo principal.
Su grado de actualización depende del contrato de replicación y de su estado real. En replicación asíncrona puede haber cambios confirmados en el origen que todavía no estén disponibles en el destino. La documentación de standby de PostgreSQL explica esa diferencia y las opciones síncronas del sistema.
No supongas que cualquier réplica puede convertirse inmediatamente en principal. La promoción, las conexiones de las aplicaciones y la prevención de escrituras simultáneas en dos principales forman parte del procedimiento. Una copia disponible no es todavía un servicio recuperado.
El backup conserva material para reconstruir un estado
Una copia de seguridad guarda datos que permiten restaurar según su formato y alcance. Puede necesitar otras piezas: registros de cambios, configuración, claves de cifrado o metadatos.
En PostgreSQL, la recuperación a un punto en el tiempo utiliza un respaldo base adecuado y los segmentos WAL necesarios. La continuidad del archivo de registros es parte de la posibilidad de recuperación; conservar solo algunos archivos no garantiza poder alcanzar el punto deseado.
Distingue el respaldo de la prueba de restauración. Un proceso de copia que termina correctamente demuestra que ejecutó su contrato; todavía hay que comprobar que el material puede utilizarse y que contiene lo que necesitan los consumidores.
Compara escenarios concretos
| Incidente | Qué puede aportar una réplica | Qué puede aportar un backup |
|---|---|---|
| Caída del nodo principal | Otro nodo, si está listo para asumir el servicio | Material para reconstruir, con el tiempo que requiera |
| Borrado lógico accidental | Puede haber recibido ya el mismo borrado | Un estado anterior si está conservado y es recuperable |
| Corrupción o fallo localizado | Depende de si el problema se propagó | Una versión válida dentro de su cobertura |
| Pérdida de una ubicación | Depende de dónde resida y de sus dependencias | Depende de dónde se almacene y pueda restaurarse |
| Pérdida de acceso administrativo | Puede compartir el mismo bloqueo | Solo ayuda si el acceso a la recuperación sigue disponible |
La tabla no constituye una garantía para cualquier producto. Un sistema puede ofrecer versionado, réplicas con retraso u otras funciones, pero su comportamiento debe comprobarse en la configuración concreta.
Un borrado obliga a escoger el estado y el alcance
Imagina un borrado accidental detectado después de que se hayan registrado otras operaciones válidas. Restaurar toda la base a un momento anterior puede recuperar lo eliminado y, al mismo tiempo, descartar cambios legítimos posteriores.
El plan necesita decidir qué restaurar, dónde validarlo y cómo reconciliar esos cambios. Puede ser necesario recuperar una copia aislada, identificar el conjunto afectado y preparar una corrección controlada. Esa solución depende del motor, de los datos y del alcance del incidente.
No ejecutes una restauración general como sustituto de ese análisis. La recuperación debe conservar evidencia de las diferencias y un responsable que acepte el resultado antes de conectarlo a los consumidores.
Revisa las dependencias que comparten tus copias
Dos instancias pueden depender de la misma cuenta, red, región o sistema de claves. Identifica qué fallo común las dejaría inutilizables y qué acceso permitiría iniciar la recuperación.
Incluye los componentes que viven fuera de la base de datos. Restaurar referencias a archivos no restaura los archivos; recuperar una tabla no reconstruye automáticamente las configuraciones de una aplicación o las credenciales que necesita.
Conserva inventario y versiones de esas dependencias mediante el procedimiento autorizado. Las claves requieren un tratamiento de acceso distinto al de la documentación operativa; no deben copiarse indiscriminadamente junto a los respaldos.
Define una prueba que represente el fallo
Para una caída, ensaya el cambio de servicio y comprueba las operaciones que siguen disponibles. Para un borrado, restaura un estado anterior en un entorno aislado y reconcilia registros afectados y cambios posteriores.
Mide el tiempo hasta que el consumidor vuelve a trabajar, no solo el tiempo que tarda una herramienta en copiar archivos. Verifica también qué datos quedaron fuera del punto recuperado.
Cuando la plataforma alimenta informes, una reconstrucción puede requerir regenerar salidas derivadas mediante un backfill validado. Haz visibles esas dependencias en el plan.
Para revisar la recuperación de una plataforma de datos cloud, presenta a Nexeus Big Data los incidentes que necesitas cubrir y los consumidores afectados. Esa relación permite decidir cómo combinar copias, réplicas y procedimientos de restauración sin atribuirles garantías que todavía no se han probado.