Estrategia de copia de seguridad en la nube: guía completa

Una estrategia de copia de seguridad en la nube que funciona sigue la regla 3-2-1: tres copias de tus datos, en dos tipos de soporte diferentes, con una copia fuera del sitio. En la práctica: un primario (almacenamiento de producción), una copia local (NAS o disco externo) y al menos un nivel en la nube (Backblaze B2, AWS S3 Glacier Deep Archive o Wasabi). El RGPD, en su artículo 32, exige medidas técnicas apropiadas para garantizar la seguridad del tratamiento de datos personales: la estrategia 3-2-1 con cifrado previo a la subida satisface directamente ese requisito. Añade inmutabilidad mediante bloqueo de objetos, cifra en el lado del cliente con AES-256 antes de subir, automatiza cada noche mediante restic o Borg, y —este es el paso que la mayoría de equipos omite— prueba una restauración completa cada trimestre. Sin una restauración probada, tienes esperanza, no una copia de seguridad.

Por qué la regla 3-2-1 sigue siendo válida en 2026

La 3-2-1 viene de la fotografía en película, pero la matemática no ha cambiado. Tres copias dan suficiente redundancia para que cualquier fallo único (caída de disco, ransomware, un rm -rf accidental) deje dos copias intactas. Dos tipos de soporte mitigan el fallo sistemático: una versión de firmware defectuosa que inutiliza todo un modelo de SSD, o una interrupción de región de un proveedor de nube. El almacenamiento externo protege contra el evento a nivel de edificio: incendio, inundación, robo o el camión de mudanzas golpeando tu rack.

Existen variantes modernizadas. La 3-2-1-1-0 añade una copia inmutable y requiere cero errores en las pruebas de restauración. La 4-3-2 (usada por muchos MSP) mantiene cuatro copias y dos proveedores de nube. Elige una, documéntala y respétala. El número específico importa menos que la disciplina.

Elegir niveles de almacenamiento según coste frente a velocidad de recuperación

Los proveedores de nube ofrecen clases de almacenamiento a precios radicalmente diferentes:

| Nivel | Coste por GB/mes | Latencia al primer byte | Coste de egreso | |-------|-----------------|------------------------|-----------------| | S3 Standard | 0,023 $ | milisegundos | 0,09 $/GB | | S3 Glacier Instant | 0,004 $ | milisegundos | 0,03 $/GB | | S3 Glacier Flexible | 0,0036 $ | 3-5 minutos | 0,02 $/GB | | S3 Glacier Deep Archive | 0,00099 $ | 12 horas | 0,02 $/GB | | Backblaze B2 | 0,006 $ | milisegundos | 0,01 $/GB | | Wasabi | 0,0069 $ | milisegundos | gratis (hasta 1x almacenado/mes) | | Cloudflare R2 | 0,015 $ | milisegundos | gratis |

Para copias de seguridad específicamente, Glacier Deep Archive cuesta aproximadamente 1 $ por TB al mes, pero la latencia de restauración significa que no puedes usarlo para "oh no, borré el archivo de ayer". Un enfoque de dos niveles funciona mejor: copias recientes en un nivel activo (B2 o R2), las de más de 30 días migradas a Glacier Deep Archive mediante políticas de ciclo de vida.

La regla 3-2-1 en términos concretos

Una pila de ejemplo para un conjunto de trabajo de 2 TB:

Producción: portátiles, servidores, datos SaaS (copia primaria)
Local: NAS con ZFS y snapshots, 4 TB útiles, sincronizado semanalmente a un disco USB externo en una caja ignífuga
Nube activa: bucket Backblaze B2 con restic, incremental nocturno, retención de 90 días a ~12 $/mes para 2 TB
Nube fría: S3 Glacier Deep Archive mediante política de ciclo de vida, snapshots anuales, retención de 7 años a ~24 $/año para 2 TB

Coste mensual total: menos de 20 $ para cobertura 3-2-1 completa con un historial de siete años. Más barato que un portátil de repuesto.

Automatizar copias de seguridad con herramientas que no te fallen

Restic es la elección de facto para copias incrementales cifradas en almacenamiento de objetos. Deduplica, comprime, cifra y soporta B2, S3, Azure, GCS y SFTP de forma nativa:

restic -r b2:hexa-backups:produccion init
restic -r b2:hexa-backups:produccion backup /var/data \
  --exclude-file=/etc/restic/exclude.txt \
  --tag nightly
restic -r b2:hexa-backups:produccion forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Ejecútalo cada noche mediante temporizador systemd o cron, con la contraseña del repositorio en un archivo legible solo por root. Borg Backup es una excelente alternativa, especialmente si necesitas soporte de repositorio local; Kopia es más nuevo y tiene una interfaz más amigable.

Para estaciones de trabajo Windows, Duplicati o el propio Historial de archivos de Windows más un destino en la nube cubre lo básico. Para Mac, Time Machine a un NAS local más Arq Backup a Backblaze B2 es una combinación consolidada.

Hacer las copias inmutables contra el ransomware

El ransomware que cifra tus datos de producción también intentará cifrar tus copias de seguridad. El bloqueo de objetos lo impide. Tanto AWS S3 como Backblaze B2 soportan el "modo de cumplimiento" donde incluso la cuenta raíz no puede eliminar objetos hasta que expire el período de retención:

aws s3api put-object-lock-configuration \
  --bucket backup-inmutable \
  --object-lock-configuration '{
    "ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}
  }'

Durante 30 días tras la subida, nadie —incluido un administrador comprometido— puede eliminar la copia de seguridad. Combina esto con versionado, eliminación con MFA y un rol IAM que pueda escribir pero no sobrescribir, y habrás cerrado el vector dominante de ransomware.

Cifrar en el cliente antes de subir

Incluso con cifrado del lado del proveedor (SSE-KMS), tu proveedor de nube tiene las claves, lo que significa que las solicitudes de subpoena pueden obligar al descifrado. La LOPDGDD y el RGPD son claros: para datos personales sensibles, el responsable del tratamiento debe aplicar medidas técnicas que garanticen que terceros no autorizados no puedan acceder a los datos. Para datos sensibles, cifra antes de que los bytes salgan de tu red. Restic hace esto automáticamente; para archivos ad-hoc, age es una buena opción:

age -r age1xyz... -o archivo.tar.gz.age archivo.tar.gz
aws s3 cp archivo.tar.gz.age s3://backups/

Almacena la clave privada de age en 1Password o en una clave de hardware como YubiKey. Haz una copia de seguridad de la clave misma en papel, cifrada con una frase, en una caja de seguridad. Una clave de cifrado perdida es tan catastrófica como los datos perdidos.

La prueba de recuperación es la copia de seguridad

Cada trimestre, elige un archivo o servidor al azar y restáuralo de extremo a extremo en un entorno limpio. Mide:

RTO (objetivo de tiempo de recuperación): desde la decisión hasta la restauración
RPO (objetivo de punto de recuperación): cuántos datos se perdieron (horas, días)
Integridad: ¿los bytes restaurados coinciden con el hash original?

Un ejemplo real: un equipo que ejecutaba copias de seguridad nocturnas en S3 Glacier Deep Archive descubrió durante su primera prueba de restauración que aprovisionar los permisos de restauración más esperar las 12 horas de recuperación hacía que el RTO fuera de 18 horas cuando su negocio necesitaba 4. Movieron la retención activa a Glacier Flexible (recuperación en 3-5 minutos) y mantuvieron Deep Archive solo para el historial de cumplimiento. Esa prueba les salvó de aprender la lección durante un incidente real.

Documenta el runbook mientras avanzas: comandos, credenciales, frases de descifrado, quién puede autorizar una restauración. Pruébalo en un portátil nuevo para saber que el runbook funciona sin tu entorno local.

Requisitos regulatorios de retención

Muchos marcos especifican retención mínima. En España, la LOPDGDD no establece plazos fijos de retención, pero exige que los datos no se conserven más tiempo del necesario para la finalidad declarada. A nivel europeo y sectorial:

RGPD: sin número fijo; conservar solo el tiempo necesario para las finalidades declaradas
HIPAA: 6 años para registros de auditoría y políticas
SOX: 7 años para registros financieros
PCI DSS 4.0: 1 año para registros de auditoría, 3 meses "disponibles inmediatamente"
FINRA 17a-4: 3-6 años, almacenamiento WORM requerido

Etiqueta las copias de seguridad con metadatos de retención y aplica políticas de ciclo de vida para no conservar datos más tiempo del necesario (un problema del RGPD) ni menos del requerido (un problema SOX).

Monitorización y alertas

Las copias de seguridad que fallan silenciosamente son peores que ninguna copia. Cada trabajo de restic o Borg debe emitir métricas: duración, bytes transferidos, archivos cambiados, éxito/fallo. Envíalas a Prometheus, Datadog o un registro de cron simple monitorizado por una herramienta estilo Dead Man's Snitch que alerte cuando el latido esperado no llega. El modo de fallo que intentas capturar es "las copias de seguridad llevan 90 días rotas y nadie lo ha notado".

Alerta sobre: fallo del trabajo, trabajo omitido, corrupción del repositorio (restic check), cambio de tamaño inusual (pérdida de datos o crecimiento inesperado) y fallo en la prueba de restauración.

HexaTransfer no es una herramienta de copia de seguridad: sirve para transferencias únicas cifradas. Pero los mismos principios de cifrado de extremo a extremo se aplican cuando envías un archivo de copia de seguridad a un colega. Pruébalo en https://hexatransfer.com — gratuito, sin cuenta, hasta 10 GB.

De la estrategia a la disciplina

Una estrategia de copia de seguridad en la nube vive o muere por la disciplina más que por la arquitectura. Ejecuciones nocturnas, pruebas de restauración trimestrales, revisiones anuales del runbook, retención inmutable y cifrado en el cliente no son glamorosas, pero son la diferencia entre "teníamos una copia de seguridad" y "teníamos una recuperación". Escribe lo que haces, automatiza lo que puedas, prueba lo que no puedas automatizar y mantén el coste mensual total lo suficientemente bajo como para que nadie en finanzas te pida que lo recortes.