Defina la pérdida y la interrupción aceptables
Anote el último punto de recuperación aceptable y el tiempo objetivo para restaurar un servicio útil. Estos son objetivos de la aplicación, no un SLA de PrivacyNodes. Si perder una hora de datos es inaceptable, una copia diaria por sí sola no puede cumplir ese objetivo. Elija un método de copia de seguridad de base de datos coherente con su carga de trabajo y versión.
Obtenga un objetivo desechable, el artefacto de la aplicación y credenciales de recuperación autorizadas a través de un almacenamiento protegido. Confirme quién aprueba la restauración de datos de clientes y cómo el entorno de prueba impide el tráfico externo. No restaure sobre la base de datos de producción en ejecución ni sobre un directorio existente.
Inventaríe el estado completo de la aplicación
Para la API de informes, enumere PostgreSQL, las cargas, las exportaciones que no pueden reproducirse, la configuración, las referencias de claves de cifrado, el DNS y las dependencias externas. Distinga una caché desechable de una cola que contiene trabajo de clientes que necesita reconciliación. Una imagen de contenedor describe software, no todo el estado persistente.
| Registro | Su valor |
|---|---|
| Versión del artefacto y la configuración | Identificadores exactos |
| Copia de seguridad de base de datos y punto de recuperación | Archivo elegido y marca temporal |
| Instantánea de cargas y límite de consistencia | Instantánea, ruta y plan de coincidencia |
| Objetivo desechable | Entorno verificado y destino vacío |
| Credenciales y aprobador | Solo referencias protegidas |
| Inicio, finalización, pasos faltantes | Resultados observados, no estimaciones |
Comprenda qué incluye la copia de seguridad
PostgreSQL documenta los volcados lógicos, las copias de seguridad del sistema de archivos y el archivado continuo como estrategias diferentes. Un pg_dump archivo cubre una base de datos; los roles y tablespaces de todo el clúster requieren consideración aparte. Su cliente no puede volcar un servidor de versión mayor más reciente. Haga coincidir las versiones de las herramientas y la estrategia con el objetivo; copiar un directorio de datos activo no es automáticamente consistente.
Inspeccione un archivo antes de restaurarlo. Seleccionar una tabla con pg_restore no incluye automáticamente todas sus dependencias. Su --clean opción elimina objetos existentes; una restauración de una sola transacción no puede combinarse con trabajos en paralelo. Revise las opciones para la base de datos de prueba vacía identificada específicamente.
Referencia técnica: Copia de seguridad y restauración de PostgreSQL · PostgreSQL pg_dump · PostgreSQL pg_restore.
Verifique la integridad y restaure de forma independiente
Las comprobaciones del repositorio y las restauraciones funcionales responden a preguntas diferentes. El check ordinario de restic no lee todos los paquetes de datos almacenados; check --read-data añade esas lecturas y puede consumir un ancho de banda considerable. Ninguno de los dos demuestra que la instantánea contenga todo lo que la API necesita.
Seleccione una instantánea específica y un nuevo directorio de destino. Un latest sin calificar en un repositorio compartido puede seleccionar otra carga de trabajo. Una restauración puede sobrescribir archivos y una interrupción puede dejar resultados parciales. Verifique primero el destino, manteniendo intactos los archivos de producción y el repositorio original.
Referencia técnica: comprobaciones del repositorio de restic · destinos de restauración de restic.
Pruebe el comportamiento restaurado en orden de dependencias
Recrear el entorno, restaurar la base de datos y las cargas coincidentes, y luego iniciar la API con credenciales de staging. Mantenga los workers en pausa hasta que se entiendan su acumulación y sus efectos secundarios. Desactive el correo electrónico de producción, las llamadas de pago y los webhooks; use un destino de exportación de prueba y nunca consuma la cola de producción.
Use una cuenta de prueba conocida para leer un registro, abrir su carga, comprobar las restricciones de acceso y ejecutar una pequeña exportación nueva. Verifique que otra cuenta de prueba no pueda leer sus datos. Compare el punto de recuperación seleccionado con el último registro esperado. Registre el tiempo real de restauración después del simulacro; no escriba por adelantado un resultado de éxito inventado.
Resuelva la propiedad de escritura antes de una conmutación real
Durante un incidente, decida qué sistema puede aceptar escrituras y cómo se reconcilian los cambios posteriores. Dos copias escribibles pueden divergir. Un simulacro documenta esta decisión sin conmutar tráfico real. Elimine los datos desechables según sus reglas de retención cuando termine el ejercicio.
Corrija las credenciales, dependencias y pasos de validación que falten después de cada ensayo. Mantenga el runbook fuera del host original y asegúrese de que otro mantenedor autorizado pueda encontrarlo. La opción de copia de seguridad seleccionable es independiente de este proceso de aplicación; confirme el alcance y los procedimientos de restauración en los datos del servicio. Use el registro de publicación para el despliegue que sigue.
Referencias oficiales
La documentación fue revisada para este artículo. Los ejemplos son ejercicios de planificación, no comandos probados en un servidor PrivacyNodes. Consulta la documentación de tu versión instalada.