Un plan de DR no es un documento. Es un procedimiento que alguien ya ejecutó — con tiempo medido.

Último capítulo del curso: escenarios de desastre, el drill que prueba el restore y el capstone para cerrar todo.

Sello del curso: validado con drill de restore en 85 segundos y failover de Postgres real.

Qué es un desastre

No todo incidente es un desastre. La distinción importa porque la respuesta cambia:

Escenario	Impacto	Respuesta
Pod reinicia	ninguno (HA)	automático
Nodo cae	carga redistribuye	automático
Primario de la base de datos cae	failover	automático + validación
Namespace eliminado	servicio fuera	restore de objetos
Clúster perdido	todo fuera	rebuild + restore
Región/zona perdida	todo fuera	DR site
Datos corruptos	pérdida parcial	restore lógico con PITR

Los tres últimos exigen procedimiento escrito. Los tres primeros, automatización.

RPO y RTO por capa

Capa	RPO	RTO	Mecanismo
etcd	24h	1–2h	snapshot programado
Objetos del clúster	24h	1–4h	Velero
Postgres	minutos	30–60 min	WAL + base backup
Dump lógico	24h	1h	pg_dump
Object storage	24h	horas	replicación/backup
Configuración	0	minutos	Git

Si el negocio exige RPO de 5 minutos y el backup es diario, el problema no es Kubernetes. Es el diseño.

Cuatro drills que valen la pena

1. Restore de namespace (Velero)

velero backup create drill-ns --include-namespaces portal --wait
velero restore create --from-backup drill-ns --namespace-mappings portal:drill
kubectl -n drill get all

Mide: tiempo del restore, pods listos, datos accesibles.

2. Restore lógico de la base de datos

pg_dump -Fc -h portal-postgres-rw -U portal -d portal -f /tmp/portal.dump
createdb -h portal-postgres-rw -U portal portal_drill
pg_restore -h portal-postgres-rw -U portal -d portal_drill /tmp/portal.dump
psql -h portal-postgres-rw -U portal -d portal_drill -c "select count(*) from tickets;"

Mide el tiempo y compara los conteos con producción.

3. Snapshot y restore de etcd

En un entorno descartable, restaura el snapshot y valida que la API responda con los objetos esperados. En HA, el procedimiento es quirúrgico: ten un runbook y ensaya.

4. Rebuild de un servicio desde cero

Elimina el Deployment y el Service, y reconstruye solo con Git + Helm/GitOps:

kubectl -n drill delete deploy portal-backend
argocd app sync portal-drill
kubectl -n drill rollout status deploy/portal-backend

Si esto no funciona, tu "backup" de configuración es ilusorio.

Runbook de DR: lo que debe estar escrito

1. Quién decide declarar desastre y quién ejecuta.
2. Cómo acceder al clúster/consola con credenciales que no están en el clúster.
3. Orden de recuperación: red → storage → base de datos → apps → ingress.
4. Comandos exactos, no "restaure el backup".
5. Criterio de validación por etapa.
6. Comunicación para usuarios y stakeholders.
7. Cómo registrar el incidente y el tiempo de cada etapa.

Regla: el runbook tiene que ser ejecutable por alguien cansado a las 3 a.m., sin el autor original disponible.

Lo que derriba el DR en la práctica

• Backup en el mismo storage del clúster.
• Credencial de restore solo en la cabeza de una persona.
• Snapshot que nunca fue restaurado.
• DNS/TLS con validez corta no renovado en el entorno nuevo.
• Imagen fuera del registry (build local).
• Secret que no fue incluido en el backup.
• Runbook desactualizado tras cambio de arquitectura.

Capstone

Objetivo: demostrar que puedes perder y recuperar el entorno.

Entregables:

1. Inventario: aplicaciones, dependencias, datos y propietarios.
2. Matriz RPO/RTO por servicio, acordada con el negocio.
3. Backups automatizados: etcd, Velero, base de datos, object storage.
4. Drill ejecutado con tiempos medidos y evidencia (logs, prints, conteos).
5. Runbook de DR revisado por otra persona.
6. Dashboard de SLO + panel de backups.
7. Postmortem del drill: lo que falló en el ensayo.

Criterio de aceptación: restaurar el entorno en un entorno limpio, dentro del RTO declarado, con datos verificados.

Guion del drill completo

# 1. Estado inicial
kubectl -n portal get pods,pvc
psql -h portal-postgres-rw -U portal -d portal -c "select count(*) from tickets;"

# 2. Backup
velero backup create capstone --include-namespaces portal --wait
pg_dump -Fc -h portal-postgres-rw -U portal -d portal -f /tmp/capstone.dump

# 3. Destruir (entorno de prueba)
kubectl delete namespace portal-drill --ignore-not-found
kubectl create namespace portal-drill

# 4. Restaurar
velero restore create --from-backup capstone --namespace-mappings portal:portal-drill
pg_restore -h portal-postgres-rw -U portal -d portal_drill /tmp/capstone.dump

# 5. Validar
kubectl -n portal-drill get pods
psql -h portal-postgres-rw -U portal -d portal_drill -c "select count(*) from tickets;"

Cronometra cada etapa. El número que entra en el informe es el tiempo real, no el estimado.

Errores comunes

Síntoma	Causa
Restore "ok" sin datos	backup parcial/exclusiones
PVC no recreado	storageClass ausente en el destino
App sube y no conecta	secret/DNS no restaurado
RTO superado	restore nunca medido
Backup corrupto	storage sin verificación
Runbook inútil	escrito por quien nunca ejecutó
Drill olvidado	sin calendario y propietario

Checklist final del curso

• [ ] Clúster HA con etcd, VIP y PDBs.
• [ ] Workloads con probes, resources y HPA.
• [ ] Storage, base de datos, colas, caché y búsqueda operados por operador.
• [ ] Backup por capa y restore probado.
• [ ] GitOps como fuente de verdad.
• [ ] CI/CD con imagen inmutable, SBOM y firma.
• [ ] RBAC, PSA y NetworkPolicy aplicados.
• [ ] Capacidad medida con prueba de carga.
• [ ] SLO, alertas por burn rate y on-call.
• [ ] DR con RPO/RTO y drill ejecutado.

Glosario

• RPO: pérdida máxima de datos aceptada.
• RTO: tiempo máximo de recuperación.
• drill: ensayo de recuperación.
• PITR: point-in-time recovery.
• runbook: procedimiento operacional.
• capstone: proyecto final integrador.

Cierre

Empezaste con un clúster vacío y llegas aquí con: HA, datos, observabilidad, GitOps, seguridad, capacidad medida, SLO y un plan de recuperación probado.

Lo que separa un clúster que funciona de un clúster confiable no es la herramienta. Es tener procedimiento, medir y ensayar antes de necesitar.

Vuelve al índice del curso para revisar cualquier capítulo — y mantén los drills en el calendario. Confiabilidad es práctica, no certificado.

Próximo: revisita el Capítulo 19 — Backup y restore y ejecuta el drill de nuevo. Ahora con cronómetro.