Diseño de respaldo y recuperación ante desastres en función del RPO y el RTO

La mayoría de los programas de respaldo se juzgan el día en que se necesitan, y muchos fallan ese día por razones visibles mucho antes: un trabajo que omite un volumen sin avisar, una base de datos copiada en plena escritura, una restauración que tarda días por un enlace que nadie midió, o respaldos cifrados por el mismo atacante que cifró producción.

Esta guía parte de esas cifras, el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO), y avanza desde ahí: cuántas copias mantener, cómo hacer que una sobreviva al ransomware, cómo capturar bases de datos de forma consistente, con qué frecuencia demostrar que las restauraciones funcionan, cómo escribir runbooks y en qué se va el dinero.

Empiece por el RPO y el RTO de cada sistema

El RPO es la cantidad de datos que puede permitirse perder, medida en tiempo. Un RPO de 24 horas significa que un respaldo nocturno es aceptable. Un RPO de 15 minutos implica envío continuo de logs, replicación o snapshots muy frecuentes. El RTO es el tiempo que un sistema puede estar no disponible, medido desde el fallo hasta que los usuarios vuelven a trabajar.

Estas cifras deben venir del responsable de negocio de cada sistema, no solo de TI, y deben quedar por escrito. Los sistemas suelen dividirse en unos pocos niveles:

• Nivel 1. Sistemas de ingresos y de cara al cliente, como el procesamiento de pedidos, los pagos y las bases de datos centrales. Objetivos habituales: RPO de minutos, RTO de 1 a 4 horas.
• Nivel 2. Sistemas internos de los que las personas dependen a diario, como el ERP, los recursos compartidos de archivos, el correo electrónico y los tickets. Objetivos habituales: RPO de 1 a 4 horas, RTO de 8 a 24 horas.
• Nivel 3. Archivos, réplicas para informes, entornos de desarrollo y de pruebas. Objetivos habituales: RPO de 24 horas, RTO de varios días.
• Reconstruibles. Servidores sin estado construidos a partir de código o imágenes. Respalde la configuración y el pipeline de compilación, no los servidores en sí.

El RTO lo incluye todo: detectar el fallo, decidir la recuperación, acceder al sistema de respaldo, aprovisionar hardware, transferir datos y validar la aplicación.

La regla 3-2-1 y su extensión moderna

La regla 3-2-1 clásica indica que hay que mantener tres copias de los datos (producción más dos respaldos), en dos sistemas o medios de almacenamiento distintos, con una copia fuera de las instalaciones.

Muchos equipos aplican ahora la regla 3-2-1-1-0: una copia está fuera de línea o es inmutable, y las restauraciones se verifican con cero errores. Los términos adicionales existen porque los operadores de ransomware buscan y eliminan los respaldos accesibles antes de cifrar producción. Un respaldo que una cuenta de administrador puede eliminar es solo un objetivo más.

En la práctica, hoy "dos medios" suele significar dos sistemas de almacenamiento independientes, más que disco y cinta. Un appliance de respaldo local más almacenamiento de objetos en otra instalación cumple el requisito. Dos volúmenes en el mismo arreglo de discos no lo cumplen, y un snapshot por sí solo no es un respaldo, porque comparte hardware y credenciales con los datos que protege.

Copias inmutables y aisladas frente al ransomware

Una copia inmutable no puede modificarse ni eliminarse hasta que vence su período de retención, ni siquiera por un administrador. Las opciones habituales son el almacenamiento de objetos con bloqueos de retención de escritura única en modo de cumplimiento, los appliances de respaldo con retención reforzada y los medios desconectados físicamente.

La inmutabilidad solo sirve si los controles que la rodean están a la altura. Suponga que un atacante tiene derechos de administrador de dominio en producción y pregúntese qué sigue sin poder tocar:

• Identidad separada. La plataforma de respaldo usa sus propias cuentas, no el directorio de producción, con autenticación multifactor en cada inicio de sesión administrativo.
• Retención bloqueada. Bloqueos de retención que no pueden acortarse a posteriori, y cualquier cambio en la política de retención requiere la intervención de dos personas.
• Separación de redes. Almacenamiento de respaldo accesible solo desde los servidores de respaldo, en una red de gestión separada, sin acceso entrante desde las redes de usuarios.
• Profundidad de retención. Suficiente historial para remontarse a antes de la infección. Los atacantes suelen permanecer semanas dentro de una red, así que de 30 a 90 días es un mínimo realista para el nivel inmutable.
• Alertas ante anomalías. Alertas por picos de datos modificados, conjuntos de respaldo eliminados y cambios en la retención, que suelen ser las primeras señales visibles de un ataque.

Planifique la restauración tras un ransomware por separado de la restauración tras un fallo de hardware. Después de un ransomware puede ser necesario restaurar en un entorno aislado, analizar los datos, encontrar el último punto en buen estado conocido y regenerar las credenciales antes de volver a conectar nada.

Consistencia de bases de datos: lo que los respaldos de archivos hacen mal

Copiar los archivos de una base de datos en ejecución suele producir un respaldo que parece completo y falla al restaurarlo, porque las páginas se capturaron en momentos distintos. Use métodos que la base de datos entienda.

• Herramientas nativas o de respaldo en caliente. Use el método de respaldo en línea soportado por el motor de base de datos, o un agente de respaldo que se integre con él, para que la copia sea transaccionalmente consistente.
• Envío de logs para un RPO corto. Combine respaldos completos periódicos con el archivado continuo de los logs de transacciones. Esto permite la recuperación a un punto en el tiempo, incluso volver justo antes de un despliegue defectuoso o de un cambio malicioso.
• Snapshots consistentes con la aplicación. Si depende de snapshots de almacenamiento o de máquinas virtuales, ponga primero la base de datos en reposo o congélela (o use la integración de snapshots del propio motor) para que el snapshot capture un estado consistente.
• La replicación no es un respaldo. Una réplica copia fielmente en segundos las eliminaciones, la corrupción y las actualizaciones erróneas. Úsela para la disponibilidad y un RTO corto, y mantenga respaldos separados para garantizar la recuperabilidad.

Mida el tiempo de restauración de la base de datos, no solo el tiempo de respaldo. Una restauración suele incluir la reproducción de horas de logs y la reconstrucción de índices, lo que puede tardar varias veces más que el respaldo. Si una base de datos de 4 TB tiene un RTO de 2 horas, confirme si una restauración puede cumplirlo o si también necesita una réplica en espera.

Un enlace de 1 Gbps a plena carga mueve unos 125 MB por segundo, o aproximadamente 10 TB al día. En la práctica, la sobrecarga del protocolo, la rehidratación de la deduplicación y la velocidad de lectura del almacenamiento suelen limitar el throughput sostenido al 50 a 80 por ciento de la velocidad de la línea.

• Ejemplo. Restaurar 20 TB a través de 1 Gbps con un 70 por ciento de eficiencia lleva unos 2,9 días. A través de 10 Gbps lleva unas 7 horas, si el almacenamiento de ambos extremos puede seguir el ritmo.
• Primero, una copia local. Un nivel de respaldo local cerca de producción resuelve rápidamente la mayoría de las restauraciones; los niveles externo e inmutable responden a desastres y ataques.
• Restaure primero el subconjunto crítico. Diseñe de forma que los datos de Nivel 1 puedan restaurarse primero y por separado, en lugar de esperar al conjunto de datos completo.

Un calendario de pruebas de restauración que demuestre la recuperabilidad

Un respaldo que nunca se ha restaurado es una suposición. Ajuste el esfuerzo de prueba según el nivel:

• Diariamente. Verificaciones automáticas del estado de los trabajos y verificación automática de la integridad de los archivos de respaldo cuando la plataforma lo permita. Cualquier trabajo fallido u omitido abre un ticket.
• Semanalmente. Restaure una muestra aleatoria de archivos y carpetas de distintos sistemas y compárelos con sumas de verificación o con el origen.
• Mensualmente. Restaure al menos una base de datos de Nivel 1 en un entorno aislado, ejecute una verificación de consistencia y confirme que la aplicación puede leerla. Registre el tiempo transcurrido.
• Trimestralmente. Restaure una pila de aplicación de Nivel 1 completa, incluidas sus dependencias, desde el nivel externo o inmutable. Compare el tiempo de recuperación real con el RTO.
• Anualmente. Realice un ejercicio completo de recuperación ante desastres, incluido un escenario de ransomware, con las personas que realmente estarían de guardia. Incluya el proceso de toma de decisiones, no solo los pasos técnicos.

Registre cada prueba: fecha, sistema, copia de origen, volumen, tiempo transcurrido y problemas encontrados. Cuando una prueba supere su RTO, trátela como un incidente con un responsable y un plazo.

Runbooks que se pueden seguir bajo presión

Las recuperaciones suelen hacerlas quienes estén disponibles, a una hora inoportuna y bajo presión. Escriba runbooks para esa persona: específicos, numerados y probados, con los comandos, los nombres de host y las salidas esperadas.

• Activación y autoridad. Qué condiciones inician la recuperación, quién puede declarar un desastre y a quién hay que informar.
• Contactos. Responsables, proveedores y prestadores de servicios, con números de teléfono que no dependan de que el correo electrónico funcione.
• Acceso. Cómo llegar a la plataforma de respaldo y al entorno de recuperación si el directorio principal, la VPN o el gestor de contraseñas no están disponibles. Guarde las credenciales de emergencia en un proceso de acceso de emergencia (break-glass) sellado y auditado.
• Orden de recuperación. La secuencia de sistemas según sus dependencias: red y DNS, identidad, bases de datos y, por último, aplicaciones.
• Procedimientos paso a paso. Pasos exactos para cada sistema, con el tiempo previsto para cada uno y cómo verificar que se ha completado con éxito.
• Validación y entrega. Cómo confirma el responsable del negocio que el sistema es utilizable y que los datos están suficientemente actualizados, y cómo se reanudan las operaciones normales y los respaldos.

Guarde los runbooks en un lugar que sobreviva al desastre que describen: una copia impresa, una copia cifrada fuera de línea y una copia fuera del entorno de producción.

Compromisos de costo y cómo decidirlos

Cada reducción del RPO o del RTO cuesta dinero, y la curva es empinada en el extremo bajo. Pasar de un RPO de 24 horas a 1 hora cuesta principalmente trabajos más frecuentes y almacenamiento de logs. Acercarse a cero suele implicar replicación continua y un entorno en standby, lo que aproximadamente duplica la infraestructura de esos sistemas.

• Volumen de almacenamiento. La profundidad de retención multiplica el almacenamiento. La deduplicación y la compresión ayudan considerablemente en los respaldos de archivos y de máquinas virtuales, y menos con datos ya comprimidos o cifrados.
• Nivel inmutable. La retención bloqueada implica pagar el período completo, incluso por datos que le gustaría eliminar antes. Dimensiónelo con criterio.
• Egreso y transferencia. Algunos servicios de almacenamiento cobran por los datos leídos o transferidos, lo que encarece las restauraciones grandes y las pruebas frecuentes. Incluya en su estimación los costos de restauración, no solo los de almacenamiento.
• Cómputo en standby. Un standby en caliente cumple RTO cortos, pero cuesta casi tanto como un segundo entorno de producción. Un diseño pilot light replica los datos y aprovisiona el cómputo durante la recuperación: más barato, pero más lento.
• Personas y tiempo de pruebas. Las pruebas de restauración y el mantenimiento de los runbooks consumen horas de personal cada mes. Presupuéstelas, porque sin ellas el resto del gasto no está demostrado.

Una regla de decisión sencilla: para cada nivel, compare la pérdida anual esperada con los objetivos actuales con el costo anual del diseño que cumple objetivos más estrictos. Si la mejora cuesta menos que la pérdida que evita, hágala. Si no, documente el riesgo aceptado y obtenga la aprobación del responsable del negocio.

Lista de verificación de respaldo y recuperación

• Cada sistema: RPO, RTO, nivel y responsable por escrito.
• Dependencias mapeadas; el orden de recuperación las sigue.
• Tres copias por sistema en alcance, en 2 o más sistemas de almacenamiento independientes, una fuera de las instalaciones.
• Al menos una copia inmutable o fuera de línea, retención de 30 días o más para datos críticos.
• Administración de respaldos con cuentas separadas y MFA. Los cambios de retención requieren dos personas.
• Respaldos en una red aislada, inaccesible desde las redes de usuarios.
• Respaldos de bases de datos consistentes y adaptados al motor, con archivado de logs cuando el RPO es inferior a unas pocas horas.
• Throughput de restauración medido; la mayor restauración Tier 1 cabe en su RTO.
• Programados y registrados: control diario de trabajos, restauraciones semanales de archivos, mensuales de bases de datos, trimestrales de aplicaciones y ejercicio completo anual.
• Runbooks numerados, probados, fuera de línea y revisados tras pruebas o grandes cambios.
• Alertas: trabajos fallidos, respaldos eliminados, cambios de retención, picos de cambio de datos.
• Costos: almacenamiento, transferencia, cómputo en standby, tiempo del personal. Los responsables aprueban los riesgos aceptados.

Próximos pasos

Empiece por completar el RPO, el RTO y el responsable de sus diez sistemas más importantes, y luego haga una restauración cronometrada del más grande.

Si está creando o trasladando destinos de backup, Vonahost ofrece servidores dedicados con NVMe local o almacenamiento en bloque en red de hasta 1 PB en la región que usted elija, y su nube gestionada incluye backups. Cada propuesta indica configuración, ubicación, responsabilidades y precio mensual en dólares estadounidenses, de modo que queda claro qué partes del plan de recuperación opera usted y cuáles el proveedor.