1.

Fundamentos Críticos: Las Métricas que Gobiernan

Todo
En un entorno cloud, una "copia de seguridad" es un concepto obsoleto si se mira de forma
aislada. Hablamos de continuidad del negocio y resiliencia operativa. Para diseñar
cualquier estrategia, primero debemos entender las dos métricas que dicta el negocio, no la
tecnología:
●​ RPO (Recovery Point Objective / Objetivo de Punto de Recuperación): ¿Cuánta
pérdida de datos es tolerable? Se mide en tiempo (ej., 15 minutos, 4 horas, 24 horas). Un
RPO de 1 hora significa que, tras un desastre, la recuperación usará un backup que tiene
como máximo 1 hora de antigüedad. Todo el trabajo realizado en esa última hora se
perderá. Esta métrica define la frecuencia de nuestros backups.
●​ RTO (Recovery Time Objective / Objetivo de Tiempo de Recuperación): ¿Cuánto
tiempo de inactividad es tolerable? Esto define la rapidez con la que debemos restaurar
el servicio. Un RTO de 30 minutos significa que desde el momento del fallo hasta que el
sistema está 100% operativo de nuevo, no pueden pasar más de 30 minutos. Esta
métrica define la tecnología y la estrategia de nuestra recuperación.
¡Error Común! No Confundir Backup, Snapshot y Réplica
Es vital dominar esta distinción:

Tipo Propósito Almacenamiento Vulnerabilidad

Principal Típico Clave

Backup Recuperación ante Ubicación Lento para

desastres (borrado, separada, a restaurar (alto
corrupción, menudo inmutable RTO).
ransomware). y en otra región.
Retención a largo
plazo.

Snapshot Recuperaciones Misma No protege contra

operativas rápidas infraestructura que fallos de la
(ej., "deshacer" un el original. infraestructura o
mal despliegue). desastres de
región.

Réplica Alta Disponibilidad Sincronizada en Si los datos se

(High Availability) y tiempo real (o casi) corrompen en el
failover casi en otra zona o origen, la
instantáneo. región. corrupción se
 replica
instantáneamente.
No es un backup.

2. Tipos de Backup: La Estrategia detrás de la Copia

La distinción entre "automático" y "manual" se refiere al disparador de la tarea, no al tipo de
backup en sí. Los tipos fundamentales que determinan nuestra estrategia de almacenamiento
y restauración son:
●​ Backup Completo (Full): Copia absolutamente todos los datos seleccionados.
○​ Ventaja: Restauración más rápida y sencilla (solo se necesita un set de datos).
○​ Desventaja: Consume mucho tiempo, ancho de banda y almacenamiento. Inviable
para hacerlo con alta frecuencia.
●​ Backup Incremental (Incremental): Copia solo los datos que han cambiado desde el
último backup, sea este completo o incremental.
○​ Ventaja: Muy rápido y consume mínimo almacenamiento. Ideal para RPOs bajos.
○​ Desventaja: La restauración es lenta y compleja. Requiere el último backup
completo más TODOS los incrementales subsecuentes en orden. Un fallo en la
cadena invalida toda la restauración.
●​ Backup Diferencial (Differential): Copia los datos que han cambiado desde el último
backup completo.
○​ Ventaja: Un buen equilibrio. Más rápido que un completo y la restauración solo
necesita el último completo y el último diferencial.
○​ Desventaja: Crece en tamaño con cada ejecución hasta el siguiente backup
completo.
Estrategia Profesional (Ejemplo): Una base de datos crítica podría usar una
combinación: un Full semanal (Domingo AM), un Diferencial diario (cada noche),
y backups de logs de transacciones Incrementales cada 15 minutos para permitir
Point-in-Time Recovery (PITR).

3. Automatización Inteligente: Más Allá del "Cron

Job"
En la nube, la automatización es mucho más que programar una tarea. Debemos pensar en un
sistema de protección de datos autónomo:
●​ Consistencia de la Aplicación: Un backup "Crash-Consistent" simplemente copia los
bloques del disco como estén, es como quitarle el cable de alimentación a un PC. Un
backup "Application-Consistent" se asegura, a través de agentes (como VSS en
Windows o hooks en BBDD), de que las transacciones en memoria se escriban en el
disco antes de hacer la copia. Es vital para bases de datos y aplicaciones
 transaccionales.
●​ Inmutabilidad (WORM - Write Once, Read Many): Esta es nuestra mejor defensa
contra el ransomware. Un backup inmutable (como los que se guardan en buckets de
S3/GCS con Object Lock) no puede ser modificado ni eliminado por nadie —ni siquiera
por la cuenta root— durante un período de retención definido.
●​ Orquestación con IaC (Infrastructure as Code): Las políticas de backup no deben
configurarse manualmente en la consola. Deben ser definidas como código (Terraform,
CloudFormation, Bicep) junto a la infraestructura que protegen. Esto garantiza
consistencia, control de versiones, auditoría y despliegue automático de la protección
para nuevos recursos.
●​ Políticas de Ciclo de Vida (Lifecycle Policies): La automatización también gestiona los
costes. Una política puede mover automáticamente backups diarios de un
almacenamiento "caliente" (acceso rápido y caro) a uno "frío" (como AWS Glacier Deep
Archive) después de 30 días, y eliminarlos automáticamente después de 7 años para
cumplir con normativas.

4. La Regla de Oro de la Resiliencia: 3-2-1-1-0

Olviden la vieja regla "3-2-1". El estándar moderno para protegerse contra amenazas actuales
es el 3-2-1-1-0:
●​ 3: Mantén al menos tres copias de tus datos (la original de producción + 2 backups).
●​ 2: Almacena las copias en dos tipos de medios diferentes (Ej: Object Storage y Block
Storage).
●​ 1: Guarda una copia fuera del sitio (off-site). En la nube, esto significa en una región
geográfica diferente. Esto protege contra desastres a nivel de región (terremotos,
inundaciones, apagones masivos).
●​ 1: Guarda una copia offline, aislada o inmutable. Esta es la clave moderna para la
defensa contra ransomware.
●​ 0: Asegura cero errores en la recuperación tras una verificación rigurosa. Los backups
que no se prueban son solo una hipótesis.
Prácticas de Seguridad Adicionales (No Negociables):
●​ Cifrado de Extremo a Extremo con Claves Propias: No basta con el cifrado por
defecto del proveedor. Para datos sensibles, debemos usar Customer-Managed Keys
(CMK) o Bring Your Own Key (BYOK). Esto nos da control total sobre el acceso a los
datos del backup, incluso frente al proveedor de la nube.
●​ Principio de Mínimo Privilegio (PoLP): Las identidades (usuarios o roles) que ejecutan
los backups solo deben tener permisos para escribir y leer backups. No deben tener
permisos de borrado. Un rol separado, altamente restringido y con MFA obligatorio,
debe ser el único con capacidad para eliminar backups (y solo después de que expire
cualquier bloqueo de retención).

5. Técnicas de Recuperación y Estrategias de DR

(Disaster Recovery)
La recuperación no es solo "restaurar un archivo". Es un espectro de estrategias que
balancean coste, RTO y RPO.

Estrategia de Coste RTO Típico RPO Típico Descripción

DR

Backup and Bajo Horas / Días Minutos / Se restaura

Restore Horas toda la
infraestructura
desde cero en
una nueva
región a partir
de los
backups.

Pilot Light Medio-Bajo Decenas de Segundos / Se mantiene

(Luz Piloto) Minutos / Minutos una réplica
Horas mínima de la
infraestructura
en la región de
DR (ej: BBDD
pequeña,
plantillas de
VMs). En caso
de desastre,
se "enciende
la luz" y se
escala a
tamaño de
producción.

Warm Medio-Alto Minutos Cero / Una versión

Standby Segundos funcional pero
(Espera Tibia) a menor
escala de la
infraestructura
ya está
corriendo en la
región de DR.
El failover es
 más rápido.

Multi-Site Muy Alto Segundos Cero La aplicación

Active-Active (Casi Cero) corre
simultáneamen
te en múltiples
regiones, con
balanceo de
carga global.
El fallo de una
región es
transparente
para el
usuario.

6. Auditoría y Pruebas: Del Supuesto a la Certeza

Un plan de recuperación que no se prueba, NO EXISTE.
●​ Simulaciones de Recuperación: No basta con restaurar un archivo. Hay que realizar
ejercicios de DR completos (al menos semestralmente), donde se simula la pérdida
total de una región y se mide el tiempo real que toma volver a estar operativos
(RTO_actual).
●​ Chaos Engineering: En lugar de esperar a que algo falle, ¡provoquemos fallos
controlados! Herramientas como AWS Fault Injection Simulator o Gremlin permiten
inyectar fallos (ej. apagar instancias, introducir latencia, bloquear accesos) en el entorno
de producción para verificar proactivamente que los sistemas de failover y recuperación
funcionan como se espera.
●​ Auditoría y Alertas Automatizadas: Debemos tener monitorización constante sobre el
propio sistema de backup.
○​ ¿Están todos los backups completándose con éxito? (Alerta si falla uno).
○​ ¿Alguien intentó acceder o eliminar un backup inmutable? (Alerta de alta prioridad).
○​ ¿Se está cumpliendo la política de retención? (Reporte de cumplimiento).
○​ Herramientas como AWS Backup Audit Manager o Azure Backup Center son
cruciales aquí.

7. Lienzo de Estrategia de Resiliencia

Para integrar todo lo aprendido, usemos un marco estratégico que combine las capas de
defensa y su verificación.

Dimensión Estratégica Estrategias y Tácticas

🎯 OBJETIVO Integrar backups automáticos y manuales
para crear una defensa en profundidad
que cubra tanto las necesidades
operativas diarias como los eventos
excepcionales, garantizando la resiliencia y
la capacidad de recuperación verificable
del negocio.

🛡️ CAPA 1: Resiliencia Operativa Propósito: Cumplir con el RPO y RTO

(Backups Automáticos) definidos para fallos comunes (corrupción,
borrado, fallo de hardware).
Implementación: • Políticas Basadas en
Etiquetas (Tag-based): Aplicar políticas
de backup automáticamente a cualquier
recurso (VM, DB) que tenga una etiqueta
específica (ej. Backup-Tier: Critical). •
Estrategia Mixta: Usar backups completos
semanales, diferenciales diarios e
incrementales por hora (con PITR). • Ciclo
de Vida: Transición automática a
almacenamiento de archivo (Glacier) a los
90 días y eliminación a los 7 años. •
Inmutabilidad: Activar Object Lock/WORM
para todos los backups críticos por un
mínimo de 30 días.

🔧 CAPA 2: Flexibilidad Estratégica Propósito: Mitigar riesgos durante eventos

(Backups Manuales) de alto impacto y planificados.
Implementación: • Checklist
Pre-Cambio: Exigir un snapshot manual
consistente como paso obligatorio en el
pipeline de CI/CD antes de cualquier
despliegue mayor. • Golden Images:
Realizar backups manuales de sistemas en
un estado "limpio" y validado antes de
aplicar parches, para facilitar un rollback
rápido. • Respuesta a Incidentes: En
caso de un incidente de seguridad, tomar
un snapshot manual inmediatamente para
preservar el estado para análisis forense,
antes de iniciar cualquier remediación.
✅ VERIFICACIÓN (Programa Continuo) Cómo Probar: 1. Pruebas de
Restauración Automatizadas
(Semanales): Un script restaura el último
backup en un entorno de "sandbox",
ejecuta una query de validación y destruye
el entorno. El resultado (éxito/fallo) va a un
dashboard. 2. Ejercicios de Simulación
de DR (Trimestrales): Se simula un
escenario de desastre (ej. "La región
us-east-1 está inaccesible"). El equipo
debe restaurar el servicio en la región de
DR y se miden RTO_actual y RPO_actual. 3.
Análisis de Resultados y Mejora
Continua: Cada prueba genera un
informe. ¿Se cumplió el RTO? ¿Por qué no?
¿El proceso fue lento por un paso manual?
Estos resultados alimentan la mejora
continua del plan y de la automatización.