Planificador de Backup y Restauracion

El Problema

Tienes backups corriendo, pero alguna vez has restaurado uno? La mayoria de equipos descubren que su estrategia de backup esta rota cuando mas la necesitan — despues de perdida de datos, ransomware o un DELETE accidental sin WHERE. Backups sin procedimientos de restauracion probados son solo almacenamiento costoso. Un plan real de recuperacion ante desastres incluye objetivos RPO, RTO, verificacion automatizada y un runbook que cualquiera en el equipo pueda seguir a las 3 AM.

El Prompt

Eres un arquitecto de recuperacion ante desastres. Diseña un plan integral de backup y restauracion para mi aplicacion.

DETALLES DE LA APLICACION:
- Datos a proteger: [ej., base de datos PostgreSQL, uploads de usuarios en S3, cache Redis, configuracion de app]
- Volumen de datos: [ej., 50GB base de datos, 200GB archivos, creciendo 5GB/mes]
- Hosting: [ej., AWS RDS, PostgreSQL autogestionado, MongoDB Atlas, VPS]
- Backups actuales: [ej., pg_dump diario, snapshots gestionados, ninguno]
- Cumplimiento: [ej., GDPR, HIPAA, SOC2, ninguno especifico]

Diseña la estrategia de backup:
1. **Definicion RPO/RTO**: Define Recovery Point Objective y Recovery Time Objective para cada tipo de dato.
2. **Metodos de backup**: Full, incremental y continuo — que usar cuando, con programacion.
3. **Estrategia de almacenamiento**: Donde almacenar backups, encriptacion, niveles de retencion.
4. **Verificacion automatizada**: Como probar automaticamente que los backups son validos y restaurables.
5. **Runbook de restauracion**: Procedimiento paso a paso para cada escenario de desastre.
6. **Escenarios de desastre**: Plan para cada uno — drop de tabla, corrupcion de BD, caida de region, ransomware.
7. **Calendario de pruebas**: Con que frecuencia practicar cada escenario de restauracion con el equipo.

Ejemplo de Salida

Objetivos RPO/RTO:
- Base de datos: RPO=1 hora (max 1 hora de perdida), RTO=30 min (restaurar en 30 min)
- Uploads de usuarios (S3): RPO=24 horas, RTO=2 horas
- Configuracion de app: RPO=0 (versionada en git), RTO=5 min (redesplegar)

Calendario de backup (PostgreSQL):
- Continuo: Archivado WAL a S3 (point-in-time recovery, RPO < 1 min)
- Diario: pg_dump completo a las 03:00 UTC → encriptado → S3 cross-region
- Semanal: Snapshot → cold storage (Glacier)
- Retencion: 7 diarios, 4 semanales, 12 mensuales

Cuando Usarlo

Usa este skill al lanzar un nuevo servicio con datos de usuario, despues de un incidente de perdida de datos, cuando el cumplimiento requiere procedimientos documentados de backup, o cuando te das cuenta que nunca has probado una restauracion.

Consejos Pro

• Prueba tus restauraciones regularmente — programa simulacros mensuales. Un backup no probado no es un backup.
• Separa las credenciales de backup de las de la aplicacion — si un atacante compromete tu app, no deberia poder eliminar tus backups.
• La recuperacion point-in-time salva carreras — el archivado WAL (PostgreSQL) te permite restaurar a cualquier segundo, no solo al ultimo snapshot.
• Regla 3-2-1 — 3 copias de datos, en 2 tipos de medios diferentes, con 1 copia fuera del sitio.