Todos piensan "tengo backup", pero casi nadie lo testea. Un backup que no testeas regularmente es fantasía.
Estrategia 3-2-1: tres copias, dos medios, una offsite
Tienes base de datos en producción. Copia 1: snapshot automático diario en el mismo servidor. Copia 2: backup incremental en AWS S3. Copia 3: backup mensual en tape offsite.
Si se pierde copia 1 y 2 (raro pero posible), copia 3 sigue siendo recoverable.
- Copia local rápida: snapshots cada hora.
- Copia cloud: S3, diferente región.
- Copia offsite: tape, vault, diferente país.
Recovery Time Objective y Recovery Point Objective
RTO: cuánto tiempo puedes estar sin servicio (1 hora, 1 día)?
RPO: cuántos datos puedes perder (1 hora de cambios, 1 día)?
Basado en eso, diseñas backup: RTO corto = backup frecuente. RPO corto = replicas, no solo snapshots.
- Establece RTO y RPO según negocio.
- Usa replicación para RTO/RPO cortos.
- Usa snapshots para RTO/RPO más largos.
Testing: recupera en staging regularmente
Una vez al mes, recupera backup completo en staging y verifica que funciona. Eso te da confianza de que realmente puedes recuperar.
Sin testing, cuando necesites recuperar de verdad, descubrirás que backup está corrupto o incompleto.
- Test mensualmente en staging.
- Verifica: datos están, aplicación inicia, queries funcionan.
- Documenta tiempo de recuperación real.
Automatización: backups sin intervención humana
No corras backups a mano. Automatiza completamente: schedule, compresión, transferencia a offsite. Sin humanos en el loop, se corre 100% confiablemente.
Alerta si backup falla: email si algo salió mal.
El backup perfecto es uno que no sabes que existe porque funciona automáticamente en background y nunca falla.
Diferentes datos, diferentes estrategias
Base de datos crítica: RTO 1 hora, replicas + snapshot cada 30 min. Archivos estáticos: RTO 1 día, snapshot diario. Logs: RTO 1 semana, archive a Glacier.
Nótoda los datos necesita protección igual. Prioriza según importancia.