Realice un simulacro de restauración: convierta RPO y RTO en un procedimiento de recuperación
Una tarea de copia de seguridad correcta informa de que se ha creado una copia. Un simulacro de restauración responde a la pregunta más útil: ¿puede el equipo recuperar un servicio operativo, con una pérdida de datos aceptable, dentro del tiempo que el proyecto puede tolerar?
La conclusión práctica
Defina objetivos de recuperación explícitos, restaure una copia coherente en un entorno aislado, pruebe el comportamiento importante de la aplicación y registre los resultados medidos en lugar de dar por suficiente la programación.
Separe el objetivo de pérdida de datos del objetivo de tiempo de recuperación
El objetivo de punto de recuperación, o RPO, describe el momento en el tiempo hasta el cual los datos deben poder recuperarse. El objetivo de tiempo de recuperación, o RTO, se refiere a cuánto puede tardar la recuperación antes de que la interrupción tenga un efecto inaceptable. Traslade ambos a una conversación de negocio antes de elegir el software. Un sitio web de portafolio puede tolerar una interrupción distinta a la de un servicio que acepta nuevos pedidos cada minuto.
Considere una aplicación de reservas ilustrativa cuyo propietario acepta como máximo una hora de actualizaciones perdidas y aspira a recuperar el servicio en dos horas. Una copia nocturna por sí sola no puede demostrar el objetivo de datos de una hora: un incidente cerca del final del intervalo diario podría perder trabajo mucho más reciente. Los objetivos del ejemplo pertenecen a ese proyecto; no son un compromiso de recuperación de HM Bastion.
Elija un límite de medición preciso. Registre cuándo dejó de estar disponible el servicio, cuándo se reconoció el incidente y cuándo volvió el servicio probado. Durante un simulacro planificado, distinga el tiempo dedicado a reconstruir del tiempo que también se necesitaría para detectar un incidente, obtener autorización y recuperar credenciales. Informar solo del paso de importación más rápido oculta el trabajo que retrasa la recuperación real.
Haga copia de seguridad de todo lo necesario para recrear un servicio coherente
| Componente de recuperación | Qué conservar | Omisión habitual |
|---|---|---|
| Aplicación | Identificador de versión, dependencias e instrucciones de despliegue | El código fuente existe, pero la versión requerida no se puede reconstruir |
| Base de datos | Una copia de seguridad coherente compatible más los roles o la configuración necesarios | Se da por hecho que una copia de los archivos de la base de datos en vivo se puede restaurar |
| Contenido de usuario | Cargas, documentos y permisos de almacenamiento | Las filas de la base de datos apuntan a archivos que faltan |
| Configuración privada | Secretos recuperables y acceso a sus claves de cifrado | La clave solo está disponible en el servidor fallido |
| Operaciones | Detalles de DNS, tareas programadas y requisitos de servicios externos | El sitio restaurado envía mensajes reales de forma inesperada |
Utilice un método de copia de seguridad compatible con el motor de base de datos. Los volcados lógicos de PostgreSQL proporcionan una vista coherente de la base de datos, mientras que los roles de todo el clúster requieren una consideración aparte. La copia de seguridad a nivel de archivo y el archivado continuo siguen requisitos distintos. Un volcado lógico no es intercambiable con la copia de seguridad base y el WAL archivado necesarios para la recuperación a un punto en el tiempo. Seleccione y pruebe un método documentado en lugar de combinar piezas incompatibles.
Coordine la captura de la base de datos y de los archivos subidos. Si un cliente sube un documento durante la copia, una copia de seguridad de la base de datos y un archivo de archivos mucho más antiguo pueden describir estados de la aplicación diferentes. Defina una estrategia de mantenimiento o consistencia que se adapte a la aplicación e incluya un archivo adjunto de muestra reciente en las comprobaciones de restauración. El recuento de archivos por sí solo no demuestra que los archivos correctos se correspondan con los registros restaurados.
Haga que la copia de recuperación sea independiente y accesible
Mantenga una copia de recuperación fuera de la ruta de fallo que está planificando. Otro directorio en el mismo disco no ayuda cuando ese disco se pierde. Una copia controlada por la misma credencial de aplicación comprometida también puede ser eliminada por un atacante. Elija deliberadamente el acceso al almacenamiento, la retención y cualquier control de inmutabilidad, y luego confirme su comportamiento real en lugar de confiar en la etiqueta de un producto.
Cifre las copias que contengan información sensible y mantenga la clave de recuperación disponible mediante un procedimiento controlado por separado. Autorice a las personas que necesitan restaurarlas y pruebe la recuperación utilizando los permisos que tendrán durante un incidente. Incluya el crecimiento del almacenamiento de copias de seguridad y el tiempo de transferencia en el plan. Una copia que existe técnicamente pero que el operador de recuperación no puede descargar no está lista para su uso.
Restaure en un entorno seguro y ejecute una prueba concreta
- Seleccione una copia de seguridad completada y registre su marca temporal de recuperación, tamaño y evidencia de integridad.
- Prepare un destino aislado con las versiones de software requeridas y suficiente almacenamiento temporal.
- Bloquee el correo electrónico real, las llamadas de pago, las tareas programadas y los webhooks antes de iniciar la aplicación restaurada.
- Restaure la base de datos, los archivos y la configuración privada siguiendo el procedimiento documentado.
- Compruebe el inicio de sesión, registros representativos, un archivo subido y una escritura sintética en la copia aislada.
- Registre el último punto de datos recuperado, las etapas transcurridas, los fallos y las decisiones del operador.
Para el ejemplo de reservas, busque una reserva conocida inmediatamente antes del límite de la copia de seguridad y verifique su cliente y archivo adjunto relacionados. Confirme que aparece la reserva reciente esperada y que no aparece un registro de prueba intencionadamente posterior. A continuación, cree una reserva sintética en la copia aislada. Esto prueba las relaciones y la capacidad de escritura sin contactar con un cliente real ni alterar producción.
Utilice un registro por etapas: obtención de credenciales, preparación del destino, descarga, verificación, importación, arranque de la aplicación y comprobaciones de aceptación. Suponga que la importación tarda veinte minutos pero la aprobación de acceso tarda cincuenta. La siguiente mejora es el procedimiento de acceso, no necesariamente un plan de base de datos más rápido. Conserve el resultado medido aunque no alcance el objetivo; un ensayo fallido ha identificado trabajo mientras el servicio aún está sano.
Convierta el resultado del simulacro en un registro de recuperación mantenido
Asigne un responsable a cada comprobación fallida y repita la parte afectada tras corregirla. Las subidas faltantes requieren un mejor conjunto de copias de seguridad; las extensiones no compatibles requieren un inventario de software reproducible. Repita un simulacro completo tras cambios importantes en la aplicación o el almacenamiento y con una frecuencia justificada por el proyecto. Marque la fecha de la última recuperación correcta en las notas operativas.
Lea las funciones de copia de seguridad del alojamiento por separado de su propio procedimiento de recuperación. La replicación, las instantáneas y las copias de seguridad retenidas tienen roles y límites de fallo diferentes. Confirme con el equipo las funciones y el alcance de restauración asociados al servicio que ha contratado. Un procedimiento de recuperación de aplicaciones probado sigue siendo valioso aunque la infraestructura ofrezca herramientas de recuperación adicionales.
