Contoso Airlines tiene ya una plataforma que se ve y que se opera sola en buena medida. Falta la pregunta del día malo, la que nadie quiere hacerse hasta que llega: alguien borra por error el grupo de recursos equivocado, un ransomware cifra un servidor, una actualización corrompe la base de datos de reservas, o una región entera de Azure deja de responder. Ninguna de esas cosas la resuelve un panel ni una alerta. Las resuelve —o no— lo que hayas preparado antes.

Esta lección cierra el módulo con la parte menos glamurosa y más decisiva de operar en la nube. Verás la diferencia real entre copia de seguridad y recuperación ante desastres, los dos números que gobiernan todas las decisiones, Azure Backup y sus almacenes, la protección frente al borrado malicioso, qué respalda cada servicio PaaS por sí solo y qué sigue siendo tuyo, y la estrategia completa de Contoso entre West Europe y North Europe, con su plan escrito y su simulacro. Porque una plataforma que no se puede restaurar no está terminada.

1. Copia de seguridad frente a recuperación ante desastres
2. RPO y RTO: los dos números que gobiernan todo
3. Azure Backup: almacenes, directivas y cargas de trabajo
4. Redundancia, eliminación temporal e inmutabilidad frente al ransomware
5. Restaurar: máquina completa, discos y archivos sueltos
6. Qué respalda cada servicio PaaS y qué sigue siendo tuyo
7. Azure Site Recovery
8. La estrategia de recuperación de Contoso
9. El plan de recuperación escrito
10. El simulacro: un plan no probado no existe
11. Recuperar lo borrado: bloqueos, Bicep y copias de configuración
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Se confunden constantemente y resuelven problemas distintos.

La distinción tiene una consecuencia práctica que mucha gente descubre tarde: la replicación no es una copia de seguridad. Si un ransomware cifra el disco de la región primaria, la réplica geográfica replica diligentemente el disco cifrado a la secundaria en segundos. La replicación protege del fallo de infraestructura; solo una copia de seguridad inmutable y con historial protege del error y del ataque. Se necesitan las dos.

Toda la arquitectura de esta lección se deriva de dos preguntas al negocio:

• RPO (objetivo de punto de recuperación): ¿cuántos datos podemos permitirnos perder? Se mide en tiempo. Un RPO de 15 minutos significa aceptar la pérdida de los últimos 15 minutos de trabajo.
• RTO (objetivo de tiempo de recuperación): ¿cuánto podemos estar caídos? Desde que ocurre el desastre hasta que el servicio vuelve.

La conversación se tuerce siempre igual: preguntas al negocio y responde «cero y cero». Ahí es donde hay que traducirlo a dinero, porque ambos números son inversamente proporcionales al coste, y de forma muy pronunciada. Bajar el RPO de 24 horas a 1 hora es asequible; de 1 hora a cero exige replicación síncrona, que además penaliza la latencia de escritura de cada transacción. Bajar el RTO de 8 horas a 1 hora significa tener la infraestructura secundaria ya creada y pagándose. La pregunta correcta no es «¿cuánto quieres?», sino «¿cuánto cuesta una hora de parada de este sistema, y estás dispuesto a gastar menos que eso en evitarla?».

Con esa conversación hecha, Contoso fijó sus niveles:

Fíjate en la última fila y en la tercera columna de la analítica: no todo merece el mismo nivel, y decidir que un sistema tiene un RTO de 72 horas es una decisión de arquitectura tan legítima y tan deliberada como decidir que otro lo tiene de una hora. Aplicar el nivel máximo a todo es la forma más rápida de multiplicar la factura sin mejorar lo que importa.

Azure Backup es el servicio administrado de copias. No hay servidor de backup, ni agente que licenciar, ni cintas. Sus dos contenedores:

Ambos viven en rg-contoso-seguridad-pro, separados de los recursos que protegen. Eso no es cosmético: si el almacén está en el mismo grupo que la carga, un borrado accidental del grupo se lleva el dato y su copia a la vez.

Una directiva define la frecuencia y la retención en un esquema de abuelo-padre-hijo:

La directiva pol-backup-vm-diaria de Contoso: copia diaria a las 02:00, 30 puntos diarios, 12 semanales, 12 mensuales y 7 anuales. La retención larga responde a una realidad incómoda: la corrupción y el ransomware se detectan tarde, a veces semanas después, y una retención de siete días deja sin punto limpio al que volver.

Dos detalles operativos importantes. La copia de una VM de Azure usa instantáneas de disco, sin agente y con la máquina encendida; para bases de datos dentro de la VM hace falta consistencia de aplicación, que en Windows aporta VSS y en Linux exige scripts previos y posteriores propios. Y la copia operativa de discos y blobs conserva instantáneas locales para restaurar en segundos, complementando —no sustituyendo— la copia del almacén.

La redundancia del almacén reutiliza lo aprendido en el módulo 2 sobre Azure Storage:

Contoso usa GRS con restauración entre regiones activada en rsv-contoso-pro. Este ajuste tiene una trampa clásica: la redundancia solo se puede fijar antes de proteger el primer elemento. Después es inmutable, y cambiarla obliga a crear un almacén nuevo y volver a proteger todo, perdiendo el historial. Es una de esas decisiones que cuesta muy poco tomar bien el primer día y mucho corregir el año siguiente.

Ahora, la parte que separa una copia de seguridad real de una ilusión de seguridad. Un atacante que consigue credenciales con permisos no ataca los datos: ataca las copias, porque sabe que sin ellas el rescate se paga. Las tres defensas de Azure Backup:

• Eliminación temporal (soft delete): al borrar una copia, no desaparece; queda retenida 14 días —ampliable— y se puede recuperar. En su modalidad mejorada se puede hacer irreversible, de modo que ni un administrador puede acortar ese plazo.
• Inmutabilidad del almacén: una vez bloqueada, impide reducir la retención, borrar puntos de recuperación o desproteger un elemento conservando el dato. El bloqueo es irreversible, y ese es exactamente su valor: si se pudiera revertir, el atacante lo revertiría.
• Autorización multiusuario (MUA): las operaciones críticas —desactivar la eliminación temporal, reducir la retención, eliminar la protección con datos— requieren la aprobación de un segundo principal, protegido por un guardián de recursos que vive en otra suscripción y bajo otro administrador. La comprometida de una sola cuenta deja de bastar.

Complétalo con lo del módulo 4: RBAC estricto sobre el almacén —muy poca gente necesita el rol de colaborador de copias—, alertas sobre las operaciones de borrado en AzureActivity (07-01), y Microsoft Defender for Cloud vigilando accesos anómalos. La regla que hay que llevarse: una copia que un atacante con permisos puede borrar no es una copia.

Azure Backup ofrece tres granularidades, y elegir la adecuada cambia el RTO por completo:

La restauración de archivos individuales merece atención porque resuelve casi todas las peticiones reales —«necesito el fichero de configuración de antes del cambio»— sin tocar la máquina en producción: monta el punto de recuperación como unidad temporal, copias, y desmontas. Y la restauración entre regiones permite recuperar en North Europe a partir de la copia geográfica cuando West Europe no está disponible; sin la marca cross-region-restore-flag activada de antemano, esa puerta simplemente no existe el día que hace falta.

Este es el malentendido más caro de la nube: dar por hecho que «el servicio ya hace copias». A veces las hace, pero casi nunca cubre lo que crees.

Tres avisos concretos. En Storage, la redundancia protege del fallo de hardware y no de que alguien borre un blob: eso lo cubren el versionado y la eliminación temporal, que hay que activar explícitamente en sttarjetascontosopro. En Key Vault, sin protección contra purga un secreto eliminado puede purgarse de forma definitiva antes de que expire el plazo de eliminación temporal. Y en AKS, los manifiestos versionados permiten reconstruir la plataforma, pero no devuelven el contenido de los volúmenes persistentes.

Site Recovery replica máquinas completas —de Azure a otra región, o desde un centro de datos local hacia Azure— manteniendo un punto de recuperación consistente, y orquesta la conmutación por error.

Sus tres capacidades: replicación continua con RPO típico de segundos a pocos minutos; planes de recuperación que definen el orden de arranque por grupos, con scripts y pausas manuales entre ellos; y, la más valiosa, la conmutación por error de prueba, que levanta las máquinas en una red aislada de la región secundaria sin afectar a producción y sin interrumpir la replicación. Es lo que permite ensayar de verdad, y es la base del simulacro del apartado 10.

Contoso lo usa exclusivamente para vm-motor-disponibilidad-dev y para dos servidores locales de Barcelona. Para las cargas PaaS no aporta nada: app-contoso-reservas-pro se recupera redesplegando desde Bicep en minutos, y db-reservas tiene su propio grupo de conmutación por error. Site Recovery es la herramienta para lo que sigue siendo una máquina, y una plataforma bien migrada necesita cada vez menos.

Las piezas y la razón de cada una. El par de regiones West Europe y North Europe no es arbitrario: Azure emparejó esas regiones y eso implica actualizaciones de plataforma secuenciales entre ambas, prioridad de recuperación y replicación geográfica nativa. fg-contoso-reservas mantiene la réplica de db-reservas en North Europe y ofrece un punto de conexión de escucha estable, de modo que la aplicación no cambia su cadena de conexión al conmutar. fd-contoso-global sondea el punto de salud /salud y enruta a la región sana. El almacenamiento es GZRS, que combina redundancia de zona en la primaria con réplica geográfica.

Y la decisión que más se discutió: piloto ligero, no activo-activo. En North Europe existen los planes, las aplicaciones, las ranuras y la configuración, pero con escala mínima y sin tráfico; al conmutar, se escala y se recibe. Las alternativas y su realidad económica:

Contoso descartó el activo-activo por dos motivos, y el segundo pesó más que el primero: duplicaba la factura de producción, y exigía resolver la escritura multirregión en la base de datos, con conflictos, latencia y una complejidad que habría afectado a la fiabilidad diaria para protegerse de un evento improbable. El RTO real medido en el último simulacro fue de 1 hora y 47 minutos, de las cuales 25 minutos fueron la decisión humana de conmutar. Es un dato honesto y revelador: la parte más lenta de una recuperación no suele ser técnica.

Un plan que vive en la cabeza de Marta Ríos no es un plan: es un punto único de fallo con vacaciones. plan-recuperacion-contoso es un documento versionado en contoso-infra que responde a cinco preguntas.

Quién decide. La conmutación la declara el responsable de guardia con el director de operaciones, con criterios objetivos escritos de antemano —por ejemplo, «el punto de salud falla desde tres ubicaciones durante más de 20 minutos y Azure confirma incidencia regional»—. Decidir con criterios acordados evita la parálisis de las 3 de la mañana.

En qué orden. El orden importa porque las dependencias existen: (1) confirmar el alcance con el estado del servicio de Azure; (2) conmutar fg-contoso-reservas y verificar que la réplica acepta escrituras; (3) escalar los planes de North Europe; (4) verificar kv-contoso-pro y las identidades administradas en la región secundaria —el olvido más frecuente—; (5) redirigir fd-contoso-global; (6) validar con una compra de prueba de extremo a extremo; (7) reactivar las funciones y flujos de integración.

Cómo se comunica. Canal de incidencia, aviso a atención al pasajero con un mensaje ya redactado, página de estado pública y actualizaciones cada 30 minutos aunque no haya novedades. El silencio se interpreta siempre como que nadie está haciendo nada.

Cómo se vuelve. La vuelta es más peligrosa que la ida, porque se hace con prisa y con la sensación de que ya ha pasado lo peor. Se hace en ventana programada, nunca en caliente, tras confirmar que la región primaria está estable, resincronizar los datos en sentido inverso y verificar que no se ha perdido nada escrito durante la contingencia.

Qué se necesita a mano. Contactos, identificadores de suscripción, la ubicación de las plantillas Bicep y el acceso de emergencia. Con un matiz que se aprende por las malas: ese material no puede depender de la región caída. Contoso guarda una copia del plan fuera de Azure y una cuenta de acceso de emergencia con sus credenciales en custodia física.

Toda organización tiene un plan de recuperación. Muy pocas tienen uno que funcione, y la diferencia es exactamente si se ha ejecutado alguna vez. Contoso hace un simulacro semestral con este guion:

1. Preparación (dos semanas antes): fecha anunciada, alcance definido y criterios de éxito escritos —RTO objetivo, RPO objetivo, transacción de prueba superada—.
2. Congelación: sin despliegues durante la ventana; regla de procesamiento de alertas activa para silenciar el ruido previsto (07-01).
3. Ejecución con cronómetro, siguiendo el plan literalmente, sin improvisar y sin que nadie «arregle» por su cuenta lo que no está escrito. Si el plan está mal, tiene que fallar en el simulacro.
4. Validación: comprar un billete real de prueba, emitir su tarjeta de embarque y comprobar la telemetría en log-contoso-pro. El criterio de éxito es de negocio, no técnico.
5. Vuelta atrás controlada, cronometrada también.
6. Autopsia sin culpables en las 48 horas siguientes, con acciones concretas, responsables y fechas, que se incorporan al plan.

Lo que Contoso aprendió al hacerlo por primera vez, y que ningún documento habría revelado:

• La cadena de conexión de func-contoso-tarjetas-pro apuntaba al servidor primario por nombre, no al punto de escucha del grupo de conmutación. Las tarjetas dejaron de emitirse pese a que la base de datos estaba disponible.
• Nadie tenía permisos para escalar los planes de North Europe: la asignación RBAC se había hecho solo en el grupo de producción primaria.
• El certificado del dominio secundario había caducado tres meses antes, sin que nadie lo notara porque no se usaba.
• El primer simulacro duró 4 horas y 20 minutos; el tercero, 1 hora y 47. La mejora vino de descubrir esos tres fallos, no de comprar más infraestructura.

Queda el caso más común de todos, que no es un desastre regional sino un az group delete en la ventana equivocada. Las defensas, en orden:

• Bloqueos de recursos: CanNotDelete en todos los grupos de producción y en los almacenes. Es la medida más barata y más eficaz de esta lección. Un bloqueo ReadOnly va más allá pero interfiere con las operaciones normales, así que Contoso lo reserva para rg-contoso-red-pro.
• Suscripción eliminada: se puede reactivar dentro de un plazo limitado desde la facturación. Un grupo de recursos borrado, no: no hay papelera. Lo único que devuelve el dato es la copia de seguridad, y lo único que devuelve la infraestructura es el código.
• Bicep en contoso-infra (módulo 5): reconstruir la infraestructura completa desde las plantillas, de forma repetible y en minutos. Esta es la razón de fondo por la que la infraestructura como código no es una preferencia estética: es tu plan de recuperación de la infraestructura.

Y el punto final, el que casi nadie contempla: hay que respaldar la configuración, no solo los datos. Reglas de NSG, asignaciones RBAC, configuraciones de diagnóstico, definiciones de alertas, directivas y reglas del WAF. Si todo eso vive únicamente en el portal, restaurar los datos deja una plataforma que no funciona. En Contoso vive en Bicep, y lo que no cabe en Bicep se exporta periódicamente con un runbook de aa-contoso-operaciones (07-04) hacia stlagocontosopro. Los secretos de kv-contoso-pro merecen mención aparte: se respaldan con su propio mecanismo y solo se pueden restaurar en un almacén del mismo arrendamiento y región geográfica.

• Confundir replicación con copia de seguridad. La réplica copia también el dato corrupto o cifrado. Necesitas las dos cosas.
• Guardar el almacén junto a lo que protege. Un borrado del grupo se lleva dato y copia a la vez.
• No activar la restauración entre regiones al crear el almacén. La redundancia no se puede cambiar después.
• Retención demasiado corta. El ransomware y la corrupción se detectan semanas más tarde.
• Dar por hecho que el PaaS hace copias. Storage no protege del borrado sin versionado; AKS no respalda tus volúmenes.
• No probar la restauración. Una copia nunca restaurada es una hipótesis, no una copia.
• Consejo: bloquea con CanNotDelete todos los grupos de producción hoy mismo. Cuesta un minuto.
• Consejo: mide el RTO real con cronómetro en el simulacro y publícalo. El número medido siempre es peor que el estimado, y ese es el valor del ejercicio.
• Consejo: incluye una prueba de negocio en la validación —comprar y emitir—, no solo un ping. Los servicios pueden responder y el flujo estar roto.

Ejercicio 1. El negocio exige para db-reservas un RPO de 0 y un RTO de 5 minutos. Explica qué implica técnicamente, qué cuesta y qué contrapropuesta harías con argumentos.

Ejercicio 2. Un ransomware ha cifrado vm-motor-disponibilidad-dev y se ha detectado seis días después. Describe la recuperación paso a paso y qué medidas preventivas habrían reducido el impacto.

Ejercicio 3. Contoso Millas (centro-coste=CC-2077) va a producción con una base de datos PostgreSQL flexible, blobs de justificantes de canje y una Container App. Diseña su estrategia de copias y recuperación con RPO y RTO justificados, indicando qué aporta cada servicio por sí solo y qué hay que añadir.

Solución 1: un RPO de 0 exige replicación síncrona: cada transacción se confirma en las dos regiones antes de responder al usuario. Eso añade la latencia de ida y vuelta entre West Europe y North Europe a cada escritura, degradando el rendimiento de la compra en condiciones normales para protegerse de un evento que ocurre cada varios años; y fg-contoso-reservas, que es asíncrono, no lo proporciona. Un RTO de 5 minutos exige conmutación automática sin decisión humana, con la infraestructura secundaria ya escalada y funcionando —activo-activo, con el 100 % de coste adicional de la tabla del apartado 8— y con el riesgo añadido de una conmutación espuria ante un problema transitorio de red. Contrapropuesta: mantener el RPO en 5 minutos, que es lo que da la replicación asíncrona sin penalizar la operación diaria, y bajar el RTO a 30 minutos con dos medidas baratas: criterios de decisión preacordados y automatizados hasta el punto de la aprobación —los 25 minutos de deliberación medidos son el mayor sumando—, y un runbook que escale North Europe de forma automática al detectarse la condición. Argumento para el negocio: cuantificar el coste de una hora de parada y comparar con el coste anual del activo-activo; si el segundo supera al primero multiplicado por la probabilidad anual del evento, la inversión no se justifica. Y complementar con degradación elegante: una caché de solo lectura que permita consultar reservas durante la conmutación protege la experiencia del pasajero por una fracción del precio.

Solución 2: recuperación. (1) Aislar: quitar la máquina de la red con un NSG que bloquee todo, sin apagarla si se quiere preservar evidencia de memoria; no restaurar sobre la máquina comprometida. (2) Determinar la fecha de infección con la telemetría de log-contoso-pro y AzureActivity, buscando el primer indicio anómalo: seis días de detección significa que los puntos más recientes probablemente ya están cifrados. (3) Elegir un punto de recuperación anterior a esa fecha, lo que solo es posible gracias a la retención de 30 puntos diarios de pol-backup-vm-diaria. (4) Restaurar a una máquina nueva en un grupo aislado, verificar que está limpia y solo entonces reintegrarla. (5) Comprobar que el almacén no fue atacado, revisando AzureActivity en busca de intentos de borrado de puntos. (6) Rotar todas las credenciales accesibles desde esa máquina. (7) Autopsia y notificación de seguridad según proceda. Prevención: inmutabilidad del almacén y eliminación temporal irreversible, que es lo que impide que el atacante borre los puntos; autorización multiusuario para que una sola cuenta comprometida no baste; retención larga, sin la cual seis días de latencia dejarían sin punto limpio; alertas de Defender for Cloud y sobre operaciones de borrado en el almacén; y RBAC mínimo, porque el ataque a las copias requiere permisos que casi nadie debería tener.

Solución 3: por criticidad, un proyecto de fidelización no bloquea la venta de billetes, así que RPO de 1 hora y RTO de 8 horas son razonables y muy baratos de sostener; conviene escribirlo y que el negocio lo firme. PostgreSQL flexible aporta por sí solo copias automáticas: hay que ampliar la retención a 35 días, activar la redundancia geográfica de copias y exportar el esquema con cada despliegue; no hace falta réplica de lectura en otra región para ese RTO. Blobs de justificantes: la redundancia no protege del borrado, así que hay que activar versionado, eliminación temporal de blobs y contenedores, y copia operativa desde bv-contoso-pro; si los justificantes tienen valor probatorio, además una directiva de inmutabilidad temporal. Container App: no guarda estado, se reconstruye desde la imagen de acrcontosopro y la plantilla Bicep, con la precaución de conservar las imágenes etiquetadas en el registro y su propia redundancia geográfica. Transversalmente: almacén en rg-contoso-seguridad-pro, bloqueo CanNotDelete en el grupo de producción, configuración en Bicep dentro de contoso-infra, y un simulacro anual —no semestral, dado el nivel— cuyo criterio de éxito sea canjear puntos de prueba de extremo a extremo. Etiquetas: entorno, proyecto=contoso-millas, centro-coste=CC-2077 y propietario.

Ya distingues copia de seguridad de recuperación ante desastres, y sabes que la replicación no protege del error ni del ataque porque replica fielmente el dato corrupto. Dominas los dos números que gobiernan todas las decisiones —RPO y RTO—, la conversación con el negocio que los fija y su traducción a dinero, con la tabla de niveles de Contoso que asigna una hora de RTO a db-reservas y setenta y dos a la analítica de forma deliberada. Conoces Azure Backup, sus dos almacenes rsv-contoso-pro y bv-contoso-pro, la directiva pol-backup-vm-diaria con retención de abuelo-padre-hijo, y por qué el almacén vive separado de lo que protege. Sabes elegir la redundancia —con la trampa de que es inmutable tras la primera protección— y proteger las copias del propio atacante con eliminación temporal irreversible, inmutabilidad y autorización multiusuario, porque una copia que un atacante con permisos puede borrar no es una copia. Y sabes restaurar en las tres granularidades, incluida la de archivos sueltos que resuelve el 90 % de los casos reales.

Tienes clara la frontera del PaaS: qué respalda cada servicio por sí solo y qué sigue siendo tuyo, con los tres avisos que más caros salen —Storage no protege del borrado sin versionado, Key Vault necesita protección contra purga activada, y AKS no respalda tus volúmenes—. Sitúas Azure Site Recovery en su ámbito, lo que sigue siendo una máquina, con su conmutación por error de prueba. Y comprendes la estrategia de Contoso al completo: par de regiones West Europe y North Europe, fg-contoso-reservas, fd-contoso-global, almacenamiento GZRS y la decisión razonada de piloto ligero en lugar de activo-activo, con su coste del 15 % y su RTO medido de 1 hora y 47 minutos. Por encima de la tecnología llevas las dos piezas que de verdad deciden el resultado: el plan escrito —quién decide, en qué orden, cómo se comunica, cómo se vuelve— y el simulacro semestral, que en Contoso destapó una cadena de conexión mal apuntada, unos permisos que faltaban y un certificado caducado, tres cosas que ningún documento habría revelado. Más los bloqueos, Bicep como plan de recuperación de la infraestructura y la copia de la configuración, no solo de los datos.

Con esto se cierra el módulo 7 y merece la pena mirar atrás. Contoso Airlines entró con una plataforma distribuida que nadie sabía operar y sale con otra bien distinta: observable, porque Azure Monitor recoge métricas, registros y trazas, y las configuraciones de diagnóstico llevan todo a log-contoso-pro; investigable, porque KQL convierte la queja de un pasajero en una causa raíz en cinco consultas y la función SeguirLocalizador pone esa capacidad en manos de cualquiera; trazable de extremo a extremo, porque Application Insights correlaciona la reserva a través de los seis componentes que la atienden; automatizada, porque aa-contoso-operaciones ejecuta el trabajo repetitivo con identidad administrada, versionado y vigilancia; y ahora recuperable, con copias inmutables, un plan escrito y un simulacro que lo pone a prueba dos veces al año. La pregunta «¿qué le pasó a esta reserva?» tiene respuesta, y la pregunta «¿y si mañana desaparece todo?» también.

Queda una conversación pendiente, y es la que Nuria Peña lleva meses pidiendo. Cada decisión de estas siete lecciones ha tenido un precio: las regiones emparejadas, las réplicas, los conjuntos de escalado, el área de Log Analytics con su ingesta, el piloto ligero de North Europe, las copias con treinta días de retención. Nadie en Contoso sabe hoy, con precisión, cuánto cuesta cada pieza de la plataforma, ni qué parte de esa factura es valor y qué parte es desperdicio. El módulo 8, Gestión y optimización de costos, aborda exactamente eso: cómo se estima antes de desplegar, cómo se analiza y se presupuesta después, qué descuentos existen y cuándo compensan, qué recomienda Azure Advisor y cómo se construye una cultura FinOps que optimice sin romper nada. Y empieza por donde hay que empezar: aprendiendo a estimar el coste antes de crear el recurso, con la calculadora de precios, porque la factura más difícil de corregir es la que ya has provocado.