Transferencia en recuperación ante desastres: continuidad del negocio

La transferencia de ficheros en la recuperación ante desastres mantiene las operaciones en marcha cuando el sitio principal falla — mediante replicación entre regiones (S3 CRR, Azure GRS), infraestructura en modo de espera tibio y runbooks de conmutación por error documentados. Un sistema de ficheros preparado para DR copia continuamente los cambios a una ubicación secundaria dentro de un RPO de segundos a horas, admite la conmutación por error dentro del objetivo de RTO y ha sido probado en condiciones realistas. El camino más corto hacia un DR útil: elige una carga de trabajo, replícala a una segunda región, simula un fallo regional un sábado y mide lo que ocurre realmente.

Clasificación de cargas de trabajo por impacto en el negocio

No todo sistema de ficheros merece replicación activo-activo. Un análisis de impacto empresarial categoriza los sistemas según su tolerancia al tiempo de inactividad y a la pérdida de datos:

• Nivel 0 (misión crítica): procesamiento de pagos, sistemas clínicos. RPO <1 min, RTO <15 min.
• Nivel 1 (crítico): gestión de pedidos, aplicaciones de cara al cliente. RPO <15 min, RTO <1 hora.
• Nivel 2 (importante): herramientas internas, informes. RPO <24 horas, RTO <8 horas.
• Nivel 3 (estándar): materiales de formación, archivos. RPO <1 semana, RTO <3 días.

El Nivel 0 cuesta entre 3 y 10 veces más que el Nivel 3 de replicar. Mapea los sistemas con honestidad. La mayoría de las empresas tienen entre el 5 y el 10% de sus sistemas en el Nivel 0-1 y deberían concentrar el gasto ahí, en lugar de sobreingenieriear todo por igual.

Topologías de replicación

Tres modelos de replicación dominan para el almacenamiento de ficheros:

1. Activo-pasivo: el primario acepta escrituras, el secundario recibe la réplica. La conmutación por error requiere promoción. Usado en la mayoría de los DR regionales.
2. Activo-activo: ambas regiones aceptan escrituras, con resolución de conflictos. Mayor complejidad pero RTO casi cero. Usado en sistemas globales.
3. Basado en copia de seguridad: copia periódica al secundario. Mayor RPO pero más sencillo. Usado para el Nivel 3.

S3 Cross-Region Replication (CRR) implementa activo-pasivo con RPO inferior al minuto. Los S3 Multi-Region Access Points añaden enrutamiento de conmutación por error. Para activo-activo, DynamoDB Global Tables y CockroachDB gestionan bases de datos; para ficheros, rclone en ambas direcciones con etiquetas de resolución de conflictos es un enfoque DIY válido.

Elegir una región secundaria

El primario y el secundario deben fallar de forma independiente. Reglas generales:

• Región geográfica diferente (us-east-1 → us-west-2, no us-east-1 → us-east-2)
• Red eléctrica diferente (costa oeste frente a costa este en EE.UU., diferentes redes nacionales en Europa)
• Zonas tectónicas diferentes donde sea relevante (evitar que ambas estén en el Cinturón de Fuego)

Para cargas de trabajo con requisitos de cumplimiento, ambas regiones deben satisfacer la normativa. Los datos sujetos al RGPD deben permanecer en la UE — replica de París a Fráncfort o Dublín, no a Virginia. HIPAA requiere también un BAA en la región secundaria. Documenta la selección de regiones y el razonamiento; los auditores lo preguntarán.

Coste de la replicación entre regiones

La replicación tiene tres componentes de coste:

1. Almacenamiento: el doble del coste del primario (ambas regiones conservan una copia)
2. Transferencia de datos: AWS cobra 0,02 USD/GB para CRR entre regiones
3. Tasas de solicitud: operaciones PUT en el destino

Para 10 TB replicados mensualmente, espera unos 700 USD/mes en AWS entre Virginia y Oregón. Mitigaciones: replicar a una clase de almacenamiento más barata en el destino (S3 Glacier Instant Retrieval en lugar de Standard), filtrar la replicación por prefijo o etiqueta para excluir datos no críticos, y usar las métricas de replicación del bucket para detectar replicaciones descontroladas.

El runbook de conmutación por error

Un runbook que solo existe como idea es un runbook que falla. Un runbook listo para producción cubre:

1. Criterios de activación: qué condiciones inician la conmutación por error (página de estado de la región, comprobaciones de estado de la aplicación, latencia P99 por encima del umbral)
2. Autoridad de decisión: quién toma la decisión (típicamente VP de Ingeniería + líder de SRE, con umbrales preaprobados para activación automática)
3. Pasos: comandos exactos, en orden, con salida esperada
4. Verificación: cómo confirmar que cada paso funcionó
5. Reversión: cómo revertir si la propia conmutación por error causó problemas
6. Comunicación: actualización de la página de estado, notificación a clientes, Slack interno

Ejemplo de paso de conmutación por error para una aplicación respaldada por S3: actualizar Route 53 para apuntar files.ejemplo.com desde el CloudFront del bucket primario al CloudFront del bucket secundario. Verificar con dig y una carga de prueba. Objetivo de tiempo: menos de 10 minutos.

Estrategia de DNS y enrutamiento

El DNS suele impulsar la conmutación por error. Opciones:

• Route 53 Failover routing: activo-pasivo con cambio automático basado en comprobaciones de estado
• Route 53 Latency routing: tráfico a la región sana más cercana
• CloudFront con origin failover: transparente para los clientes
• Balanceador de carga con backends multirregión: funciona pero añade complejidad

El TTL importa. Un registro DNS con un TTL de 300 segundos conmuta en 5 minutos; un TTL de 3.600 segundos tarda una hora. Establece los registros críticos para DR en TTL de 60-300 segundos, aceptando un poco más de tráfico DNS a cambio de una convergencia más rápida.

Integridad de los datos durante la conmutación por error

El retraso de la replicación significa que el secundario va ligeramente por detrás. Conmutar puede significar perder las escrituras más recientes. Documenta el RPO como la pérdida máxima esperada y ten un plan de reconciliación:

• Registrar las escrituras no confirmadas en la capa de aplicación para poder reproducirlas
• Capturar las transacciones en vuelo y reproducirlas desde los registros de eventos
• Aceptar la pérdida de forma explícita (para datos no críticos, lo más sencillo es mejor)

Para las cargas de ficheros específicamente, una carga multiparte interrumpida por la conmutación puede dejar cargas incompletas en el secundario. Configura reglas de ciclo de vida AbortIncompleteMultipartUpload en ambas regiones para limpiarlas.

Probar el DR en serio

Un plan de DR probado y uno sin probar son animales diferentes. Niveles de prueba:

• Ejercicio de mesa: recorrer el runbook verbalmente. Trimestral.
• Conmutación parcial: conmutar un subsistema (por ejemplo, solo el servicio de ficheros). Semestral.
• Conmutación regional completa: conmutar todo en una ventana de mantenimiento programada. Anual.
• Ingeniería del caos: no programada, simulada, durante horario laboral. Trimestral para sistemas de Nivel 0.

Registra todo. Qué falló. Cuánto tardó realmente cada paso. Quién no pudo acceder a la documentación cuando la necesitaba. Mejora el runbook tras cada prueba. Los equipos que hacen esto tienen conmutaciones que funcionan; los que no descubren los problemas durante incidentes reales.

Los canales de comunicación importan

Durante un incidente, la comunicación en la nube puede no estar disponible. Slack alojado en la misma región de AWS que está fallando es inútil. Prepara canales fuera de banda con antelación:

• Un espacio de trabajo secundario de Slack alojado en una región diferente
• Puente SMS a través de Twilio o Telnyx
• Una cadena de llamadas personal como último recurso
• Una página de estado pública alojada fuera de tu infraestructura principal (Atlassian Statuspage, StatusGator)

Documenta los canales en el manual físico. Practica el cambio a ellos.

Transferir ficheros de recuperación entre personas

Cuando un fallo regional bloquea el acceso a las herramientas de colaboración habituales, transferir ficheros específicos — un volcado de base de datos reciente, una exportación de configuración, un playbook de respuesta a incidentes — necesita un canal que funcione independientemente de tu infraestructura. Una herramienta compatible con dispositivos personales ayuda.

HexaTransfer funciona en cualquier navegador sin necesidad de configurar una cuenta — útil cuando el proveedor de SSO también está caído, o cuando consultores externos necesitan recibir ficheros sin ser provisionados en tu sistema. El cifrado AES-256-GCM de extremo a extremo garantiza que incluso en los momentos más estresantes frente al teclado no se filtren secretos por la red.

Revisiones post-incidente

Todo simulacro de DR y todo incidente real merece una revisión post-mortem sin culpas. Documenta:

• Cronología de los eventos
• Qué funcionó
• Qué no funcionó
• Causas raíz (técnicas y de proceso)
• Elementos de acción con responsables y fechas de entrega

Haz seguimiento de los elementos de acción hasta su cierre. Un post-mortem con 20 acciones y cero completadas es peor que ningún post-mortem — indica al equipo que las mejoras no importan. Cierra el ciclo, y el siguiente incidente irá mejor que el anterior.

La recuperación ante desastres es principalmente disciplina. Define el RPO/RTO, replica continuamente, documenta el runbook, prueba trimestralmente y comunica fuera de banda. La tecnología es la parte fácil.

Pruébalo en hexatransfer.com — gratis, sin cuenta, máximo 10 GB.