El diseño de backup en AZ-305: elegir el vault correcto para cada workload, configurar redundancia del vault según el requisito de DR, y blindar los backups contra ransomware con inmutabilidad, soft delete y MUA.
Contenido
Recovery Services Vault (clásico)
Backup Vault (nuevo)
Redundancia del vault (se elige ANTES de proteger el primer ítem)
LRS (barato, solo intra-datacenter) / ZRS (zonas) / GRS (región emparejada). Con GRS + Cross-Region Restore (CRR) puedes restaurar en la región secundaria SIN esperar a que Microsoft declare desastre. Requisito "restaurar las VMs en otra región si la primaria cae" → GRS + CRR.
| Workload | Mecanismo | Nota de diseño |
|---|---|---|
| Azure VM | Backup de VM (snapshot + transferencia al vault) | App-consistent en Windows (VSS); enhanced policy para múltiples backups/día y zonas |
| SQL Server en VM | Extensión de workload en el RSV | Fulls + diferenciales + logs cada 15 min → RPO de 15 minutos |
| Azure SQL Database / MI | Backups AUTOMÁTICOS del servicio (no vault): PITR 1-35 días + LTR hasta 10 años | No usa Azure Backup — trampa habitual del examen |
| Azure Files | Snapshots orquestados por el vault | Soft delete del share como capa extra |
| Blobs | Operational (continuo, en la cuenta) o vaulted (copias al vault) | Operational = restore rápido local; vaulted = aislamiento del dato origen |
| Discos | Snapshots incrementales programados (Backup Vault) | Más rápido/barato que backup de VM completa si solo importa el disco |
| On-premises (archivos/system state) | MARS agent → RSV | Solo archivos/carpetas/system state; para Hyper-V/VMware completo → MABS/DPM |
| AKS | Backup extension → Backup Vault | Incluye recursos del cluster y PVs |
Política de backup
Gobernanza a escala
| Control | Qué evita |
|---|---|
| Soft delete (always-on disponible) | Backups borrados se retienen 14+ días recuperables — un atacante no puede destruirlos de inmediato |
| Immutable vault (lock irreversible) | NADIE puede borrar puntos de recuperación ni reducir retención antes de tiempo — WORM para backups |
| Multi-User Authorization (MUA) | Operaciones críticas (deshabilitar soft delete, reducir retención) requieren aprobación de un segundo administrador vía Resource Guard |
| Cifrado con CMK | Backups cifrados con clave del cliente en Key Vault |
| Private endpoints del vault | Tráfico de backup sin salir de la red privada |
| Alertas de seguridad | Notificación ante operaciones destructivas (borrados, cambios de política) |
Combo anti-ransomware de examen
"Un atacante con credenciales de administrador no debe poder destruir los backups" → immutable vault (locked) + soft delete always-on + MUA con Resource Guard. Las tres capas juntas.
| Requisito | Diseño |
|---|---|
| Backup de VMs restaurable en otra región | RSV con GRS + Cross-Region Restore |
| SQL Server en VM con RPO de 15 minutos | Extensión SQL en RSV (log backups cada 15 min) |
| Retener backups de SQL Database 10 años | Long-Term Retention del servicio (no Azure Backup) |
| Auto-proteger toda VM nueva | Azure Policy DINE de backup |
| Backups inmunes a admin comprometido | Immutable vault + soft delete + MUA |
| Carpetas de un servidor físico on-premises | MARS agent → RSV |
| Reducir costo de retención anual de VMs | Archive tier para recovery points antiguos |
| Backup de PostgreSQL flexible / discos / blobs / AKS | Backup Vault |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Tras un simulacro de ransomware, el CISO exige que los backups de las VMs de producción: (1) no puedan ser eliminados ni su retención reducida por ningún administrador, (2) cualquier operación crítica sobre el vault requiera aprobación de un segundo equipo, y (3) sean restaurables si la región primaria queda inoperativa. ¿Qué configuración del Recovery Services Vault diseñas?
Inicia sesión para llevar tu progreso.