Copias de seguridad en la nube y recuperación ante desastres

El diseño comienza por el servicio de negocio que debe recuperarse. Trazamos los usuarios, recorridos de cliente, decisiones operativas y obligaciones legales o contractuales que dependen de él; después identificamos aplicaciones, datos, identidades, secretos, redes, certificados, configuración y proveedores. Una base de datos restaurada sin su clave, su proveedor de identidad, su cola de mensajes o una versión compatible de la aplicación no constituye un servicio recuperado. Por eso el registro separa archivos, registros, sistemas y resultados utilizables en lugar de tratarlos como una sola unidad.

El Recovery Point Objective, o RPO, expresa en tiempo la máxima pérdida de datos aceptable. El Recovery Time Objective, o RTO, es el plazo objetivo para devolver el servicio acordado después de una interrupción. Ninguno debería copiarse de la ficha de un producto. El cliente aporta la tolerancia al impacto, los cierres operativos, las alternativas manuales y la prioridad. Nosotros comprobamos si la frecuencia de copia, el retraso de replicación, el rendimiento de restauración, la toma de decisiones y las personas disponibles pueden sostener esos objetivos. Una aspiración sigue identificada como tal hasta que la arquitectura y los ensayos aportan evidencia suficiente.

Cada fallo exige una respuesta distinta. Un borrado accidental puede resolverse con una restauración granular; una corrupción requiere un punto sano anterior al problema; la caída de una región puede obligar a reconstruir infraestructura y redirigir tráfico. Ante ransomware, quizá haya que contener, conservar evidencias, sustituir credenciales y recuperar en un entorno limpio, no restaurar de inmediato sobre sistemas aún comprometidos. Cuando son relevantes, también contemplamos la indisponibilidad de un proveedor, la pérdida de claves, la ausencia de administradores y el daño al plano de control. Un único runbook genérico no cubre todos esos eventos de forma segura.

El encargo escrito fija el límite: diagnóstico, arquitectura, configuración de producto, migración, prueba de restauración, ejercicio de recuperación o una operación gestionada por separado. Enumera servicios, tenants, cargas, conjuntos de datos, ubicaciones, clases de retención, escenarios y evidencias incluidos. También señala quién puede declarar el desastre, aceptar una pérdida, activar un entorno alternativo y autorizar el retorno. Las notificaciones legales, el análisis forense, la comunicación de crisis y la continuidad de negocio que excedan la recuperación técnica necesitan responsables definidos o especialistas contratados aparte.

El inventario protegido abarca bases de datos, sistemas de archivos, máquinas virtuales, contenedores, objetos, datos SaaS, endpoints, código fuente, definiciones de infraestructura, configuración, certificados, secretos y documentación de reconstrucción. Cada elemento tiene propietario, fuente autorizada, método y horario de captura, retención, ubicación, límite criptográfico y método de restauración. Clasificamos snapshots, sincronización, replicación, archivo y backup según lo que realmente recuperan. Una segunda réplica activa puede copiar la corrupción enseguida; un archivo longevo puede conservar registros y, aun así, resultar demasiado lento para la operación.

La colocación de las copias responde a amenazas y dependencias. No deberían compartir todas la misma cuenta, credencial, región, plano de control o autoridad de borrado. Según el entorno, el diseño puede combinar copias fuera de la ubicación, offline, aisladas lógicamente o inmutables, administración separada, borrado aplazado, bloqueo de objetos, versionado y aprobación múltiple. La inmutabilidad es un control configurado con plazos y coste, no una cualidad mágica. Hay que revisar su estado efectivo, las excepciones administrativas, el vencimiento y el acceso durante una recuperación.

La administración del backup necesita un perímetro de confianza más estrecho que la operación habitual. Separamos identidades de servicio cuando es viable, restringimos acciones destructivas, protegemos claves y credenciales de recuperación, registramos cambios de política y vigilamos intentos de detener tareas o acortar la retención. El acceso de emergencia debe seguir disponible si el proveedor principal de identidad cae o queda comprometido, pero se protege fuera del mismo dominio de fallo y se ensaya de manera controlada. El proveedor cloud protege su plataforma; el cliente sigue siendo responsable de seleccionar cargas, configurar políticas e identidades y probar la recuperación dentro del modelo compartido.

La retención se liga al tiempo de detección, la necesidad de rectificar, las obligaciones de conservación y el coste. Guardar solo la copia más reciente puede mantener una corrupción no detectada; guardar todo indefinidamente puede generar problemas de privacidad, descubrimiento y gasto. Definimos puntos diarios, semanales, mensuales o por evento solo cuando existe una razón de negocio, y documentamos el borrado, el vencimiento y las retenciones legales. El cifrado cubre tránsito y reposo, pero perder la clave inutiliza una copia aparentemente sana. La custodia, rotación, depósito y recuperación de claves forman parte del diseño.

Un servicio recuperable necesita algo más que sus datos. El runbook ordena prerrequisitos, aprovisionamiento, red y DNS, identidad, claves, bases de datos, colas, almacenamiento, capas de aplicación, integraciones, procesos programados y proveedores externos. Distingue las acciones automatizables de las decisiones humanas. La infraestructura como código, la configuración versionada y las imágenes maestras pueden acelerar la reconstrucción, pero también necesitan fuentes protegidas, dependencias compatibles y un camino ensayado hasta el entorno de recuperación.

La ubicación de recuperación se decide por escenario. Un archivo puede volver en su sitio; una carga comprometida quizá necesite una sala limpia aislada; la pérdida de una sede puede exigir otra zona, región, nube o ubicación física. Antes del incidente deben existir capacidad, cuotas, imágenes, condiciones de soberanía, alcance de red, certificados, TTL de DNS, acceso del proveedor y controles de seguridad. Las estrategias fría, templada y caliente intercambian coste, pérdida y tiempo de retorno. El nombre comercial no es evidencia de aceptación: cuentan el recorrido real y una escala representativa.

La recuperación cibernética añade una pregunta de confianza: ¿qué punto y qué componentes están suficientemente limpios? La restauración se coordina con la contención y, si se ha contratado, con respuesta a incidentes o forense. Hay que decidir el momento sano, la sustitución de credenciales, la integridad de configuración, el análisis de malware, el tratamiento de vulnerabilidades y la conexión con sistemas quizá comprometidos. Encender deprisa un servidor restaurado puede reintroducir al atacante o destruir evidencia. El plan registra su dependencia de la investigación y quién tiene autoridad para abrir el servicio.

La validación se hace a nivel de servicio. La presencia de archivos y un checksum correcto ayudan, pero los usuarios pueden seguir sin autenticarse, las transacciones no cuadrar, las colas duplicar mensajes, las integraciones conservar credenciales antiguas o las tareas ejecutarse fuera de orden. Las pruebas cubren consistencia, operaciones representativas, permisos, observabilidad, rendimiento dentro de condiciones declaradas y efectos aguas abajo. Antes de declarar disponibilidad se documentan conciliaciones manuales, intervalos perdidos, interfaces aplazadas y plataformas no compatibles.

Una tarea correcta es solo una señal. La operación debe observar cobertura de fuentes, último punto protegido, horarios incumplidos, cambios de volumen, retraso de réplica, retención e inmutabilidad, capacidad del repositorio, caducidad de claves y certificados, coherencia del catálogo, indicios de malware, antigüedad de la última restauración y entrega de alertas. Un panel verde puede ocultar una base excluida, una credencial caducada o un tenant nuevo sin protección. Por eso se contrasta la cobertura con el inventario autorizado y todo cambio material provoca revisión.

La gestión del cambio mantiene alineados recuperación y producción. Un servicio, región, esquema, clave, identidad, dependencia o modo de despliegue nuevo puede invalidar el runbook o alterar el tiempo de retorno. Versionamos políticas y definiciones cuando es práctico, revisamos modificaciones y ponemos fecha de caducidad a las excepciones. Cada propietario sigue actualizaciones, retiradas, límites de licencia y términos del proveedor. Los requisitos de recuperación se incorporan a la definición de terminado de los cambios relevantes, en vez de descubrirse durante un incidente.

El coste comprende más que gigabytes almacenados. Puede incluir software, instancias protegidas, operaciones API, snapshots, retención inmutable, recuperación, salida de datos, cómputo alternativo, reserva de capacidad, red, entornos de prueba, soporte y tiempo del equipo. Un archivo barato puede resultar lento o caro en una restauración completa; un entorno siempre templado puede costar más de lo que justifica el impacto. La propuesta separa el trabajo de NobleJackal del consumo del proveedor y deja por escrito las hipótesis de cálculo.

La responsabilidad continua queda asignada. La matriz indica quién atiende tareas fallidas, investiga huecos, aprueba políticas, gestiona capacidad, rota claves, ejecuta restauraciones, mantiene runbooks, llama a proveedores y declara o cierra una recuperación. Las horas de supervisión, los tiempos de respuesta, el margen de cambio y la escalada solo existen si se contratan por escrito. Un proyecto de diseño o implantación no incluye de manera tácita supervisión 24/7, almacenamiento ilimitado, respuesta a incidentes ni recuperación garantizada.

Las pruebas tienen niveles. Un control de integridad no sustituye una restauración; restaurar un archivo no demuestra una aplicación; restaurar una aplicación no demuestra failover regional ni recuperación cibernética. El plan declara escenario, escala, punto, entorno, participantes, reloj, condiciones de seguridad, criterios de parada y evidencia. Los ejercicios de mesa prueban decisiones y comunicación; los técnicos prueban reconstrucción, restauración, validación, enrutamiento y regreso. El failover de producción requiere autorización separada porque puede afectar a usuarios y datos reales.

El RPO observado y la duración se informan junto con sus límites de medición. El reloj puede abarcar detección, declaración, aprobación de acceso, aprovisionamiento, transferencia, restauración, replay, conciliación, validación de negocio y apertura. Se registran volumen de prueba, ancho de banda, concurrencia, límites del proveedor, estado de caché y disponibilidad de personal. No extrapolamos en silencio una muestra pequeña a todo el entorno, ni presentamos un objetivo logrado una vez como garantía permanente ante cualquier incidente futuro.

El failback también forma parte de la recuperación. El plan contempla los datos generados en el entorno secundario, conflictos, dirección de sincronización, ventana de mantenimiento, cambios de DNS o tráfico, validación y vuelta atrás. Algunos eventos exigen convertir el entorno nuevo en primario en vez de regresar al anterior. Un incidente cibernético puede requerir además conservar pruebas y reconectar por fases. El acta distingue lo probado de lo simulado y quién acepta el riesgo residual antes de volver al proceso de cambios ordinario.

La entrega incluye mapas de servicio y dependencias, registro RPO/RTO, políticas de protección, retención y claves, arquitectura, modelo de acceso, supervisión y escalada, runbooks, evidencia de pruebas, contactos de proveedores, limitaciones y fecha del siguiente ejercicio. Los secretos viajan por un canal seguro aprobado. El cierre separa lo entregado, aceptado, aplazado y excluido. Ninguna declaración promete pérdida cero, restauración garantizada, servicio ininterrumpido, inmunidad al ransomware, cumplimiento, certificación, aceptación de aseguradoras, posiciones de búsqueda, oportunidades comerciales o ingresos.