Backup 3-2-1-1-0: La Regla Explicada con Ejemplo

La supervivencia de una empresa frente a un desastre informático depende enteramente de su estrategia de backup. Durante años, la regla de oro fue la 3-2-1: tres copias de los datos, en dos soportes diferentes, con una copia offsite. Un principio sólido, pero que en la era del ransomware y las amenazas persistentes, ya no es suficiente. Hoy, para garantizar una resiliencia completa, debemos extender esta regla al 3-2-1-1-0, introduciendo la inmutabilidad y la verificación constante de las restauraciones. Este enfoque extendido se ha convertido en un requisito fundamental para cualquiera que gestione infraestructuras IT críticas.

Versiones de referencia: restic 0.16.2 · documentación consultada en noviembre de 2026

La regla 3-2-1 y por qué ya no es suficiente

La regla 3-2-1 es un concepto básico de la protección de datos que asegura una buena cobertura contra la pérdida de datos. Incluye:

3 copias de los datos: el original más dos backups.
2 soportes diferentes: por ejemplo, un disco local y un NAS o cinta.
1 copia offsite: una copia física en un lugar geográficamente separado, o en un almacenamiento en la nube.

Este enfoque es eficaz contra fallos de hardware, eliminaciones accidentales y desastres locales. Sin embargo, las amenazas modernas como el ransomware han demostrado sus límites. Un ransomware puede cifrar no solo los datos de producción, sino también los backups accesibles en red, haciendo que todas las copias sean inutilizables. Del mismo modo, un error administrativo puede propagarse a todas las copias online antes de ser detectado. Aquí es donde el 3-2-1-1-0 entra en juego, añadiendo dos capas cruciales de protección.

Backup 3-2-1-1-0 en 60 segundos

Para quienes tienen prisa, aquí están los conceptos clave de la estrategia 3-2-1-1-0 aplicados con restic:

# 3 copias de los datos (original, local, offsite)
# 2 soportes diferentes (disco local, NAS, cloud S3)
# 1 copia offsite (cloud S3)

# El tercer 1: Realiza el backup en un repositorio S3 con Object Lock habilitado
restic -r s3:s3.amazonaws.com/your-immutable-bucket backup /path/to/your/data --password-file /path/to/password.txt

# El 0: Verifica la integridad de los datos en el repositorio (comprobación rápida)
restic -r s3:s3.amazonaws.com/your-immutable-bucket check --read-data-subset=5% --password-file /path/to/password.txt

# El 0: Realiza una restauración en una VM de prueba para validar la recuperabilidad
restic -r s3:s3.amazonaws.com/your-immutable-bucket restore latest --target /tmp/test-restore --password-file /path/to/password.txt

# El 0: Elimina los datos de prueba después de la verificación
rm -rf /tmp/test-restore

Intro: La resiliencia de los datos en la era del ransomware

En el panorama IT actual, la resiliencia de los datos ya no es solo una cuestión de disponibilidad, sino de supervivencia. Una de cada tres empresas sufre un ataque de ransomware cada año, y el costo promedio de una brecha de datos alcanzó los 4,45 millones de dólares en 2023, según el informe de IBM Cost of a Data Breach. Frente a estas estadísticas, confiar en una estrategia de backup tradicional puede ser insuficiente. Un backup bien configurado y regularmente probado es tu última línea de defensa, pero solo si es inmune a las amenazas más sofisticadas. El objetivo de este artículo es proporcionar una guía práctica y concreta para implementar la regla del backup 3-2-1-1-0, garantizando que tus datos estén protegidos y, sobre todo, sean recuperables cuando cualquier otro sistema falle.

Requisitos Previos

Para seguir el ejemplo práctico, necesitarás:

Un servidor Linux (ej. Ubuntu Server 22.04 LTS o CentOS Stream 9).
Acceso root o un usuario con privilegios sudo.
Un NAS (Network Attached Storage) o un servidor con espacio disponible vía NFS/SMB.
Una cuenta de almacenamiento en la nube compatible con S3 (ej. AWS S3, MinIO, Wasabi, Scaleway) con la funcionalidad Object Lock habilitada para el bucket de destino. Lee también: ACN Cloud QC: Niveles QC1-QC4 Explicados
La herramienta restic instalada en el servidor Linux. Puedes descargarla del sitio oficial o instalarla a través del gestor de paquetes de tu sistema operativo. Por ejemplo, en Debian/Ubuntu:

sudo apt update && sudo apt install restic

Conocimientos básicos de comandos Linux y gestión de almacenamiento.

1. La regla 3-2-1 y por qué ya no es suficiente

Como se mencionó, la regla 3-2-1 establece tres copias de los datos, en dos soportes diferentes, con una copia offsite. Esta es una base excelente para la mayoría de los escenarios de pérdida de datos. Sin embargo, el problema surge cuando los propios backups se convierten en objetivo o son comprometidos de manera no tradicional. Imagina un ransomware que se propaga en la red y cifra no solo los discos de producción, sino también el NAS donde residen los backups y, si es accesible, también el repositorio offsite. En este escenario, las tres copias podrían estar comprometidas simultáneamente. O bien, un error de configuración puede eliminar o corromper un conjunto completo de backups antes de que te des cuenta. La falta de un mecanismo de inmutabilidad y de una verificación proactiva hace que el 3-2-1 sea vulnerable a amenazas que van más allá de la simple falla de hardware.

2. El tercer 1: una copia offline o inmutable

El «tercer 1» de la regla 3-2-1-1-0 se refiere a una copia de los datos que sea offline o inmutable. Esta es tu última línea de defensa contra ataques de ransomware sofisticados o eliminaciones accidentales masivas.

Copia Offline: Un backup en un soporte físico (cinta, disco USB externo) que se desconecta de la red después de completar el backup. Esto lo hace físicamente inaccesible a cualquier malware o ataque de red. Es el método más seguro, pero requiere gestión manual y tiempos de restauración potencialmente más largos.
Copia Inmutable: Un backup en almacenamiento que impide cualquier modificación o eliminación durante un período de tiempo predefinido (Retention Period). Esta funcionalidad suele ser ofrecida por los servicios de almacenamiento en la nube (ej. AWS S3 Object Lock, Azure Blob Storage Immutability) o por algunos NAS de gama empresarial. Incluso si el sistema está comprometido, el ransomware no puede alterar ni eliminar los backups inmutables hasta que expire el período de retención. Lee también: Microsegmentación Red: VLAN y Firewall en Producción

Para el ejemplo, usaremos un bucket S3 con Object Lock habilitado, que ofrece un excelente equilibrio entre seguridad y automatización. Configura tu bucket S3 con Object Lock en modo «Compliance» o «Governance» para garantizar la inmutabilidad.

3. El 0: cero errores en las pruebas de restauración

Este es quizás el paso más crítico y más descuidado: probar regularmente y con éxito la restauración de tus backups. Un backup que no se restaura es inútil. El «0» en la regla 3-2-1-1-0 significa que tus pruebas de restauración deben tener cero errores. Este no es un evento único, sino un proceso continuo que debe automatizarse lo más posible.

Las pruebas deben incluir:

Verificación de la integridad de los datos: Comprobar que los archivos de backup no estén corruptos.
Restauración parcial: Restaurar archivos o directorios individuales para verificar la granularidad.
Restauración completa: Restaurar el backup completo en un entorno de prueba (una VM dedicada, una sandbox) para simular un desastre y medir el Recovery Time Objective (RTO).

Este proceso te permite identificar problemas en los procedimientos de backup, en la configuración del almacenamiento o en la corrupción de datos antes de que ocurra una emergencia real. Lee también: pg_restore PostgreSQL: Restaurar Dumps y Errores

4. Ejemplo real: servidor Linux, NAS y cloud

Veamos cómo aplicar la regla 3-2-1-1-0 en un entorno típico:

Escenario: Un servidor Linux con datos críticos en /srv/data.

Estrategia 3-2-1-1-0:

Copia 1 (original): Los datos en /srv/data en el servidor Linux.
Copia 2 (local): Backup en un NAS local (soporte diferente al disco del servidor).
Copia 3 (offsite/inmutable): Backup en almacenamiento en la nube S3 con Object Lock habilitado (soporte diferente, offsite, inmutable).

Paso 1: Backup en NAS local (Copia 2)

Monta una share NFS o SMB desde tu NAS en el servidor Linux. Por ejemplo, monta /mnt/nas_backup.

sudo mkdir -p /mnt/nas_backup
sudo mount -t nfs nas_ip:/export/backup /mnt/nas_backup

Configura un backup diario usando rsync o restic (si el NAS soporta un repositorio restic). Usaremos rsync por simplicidad para el backup local.

#!/bin/bash
SOURCE_DIR="/srv/data"
TARGET_DIR="/mnt/nas_backup/linux_server_data"
LOG_FILE="/var/log/backup_nas.log"

echo "$(date): Inicio backup en NAS" >> "$LOG_FILE"
rsync -avzh --delete --exclude '*/tmp/*' "$SOURCE_DIR/" "$TARGET_DIR/" >> "$LOG_FILE" 2>&1
if [ $? -eq 0 ]; then
    echo "$(date): Backup en NAS completado con éxito" >> "$LOG_FILE"
else
    echo "$(date): ERROR durante el backup en NAS" >> "$LOG_FILE"
fi

Paso 2: Backup en Cloud S3 Inmutable (Copia 3, Offsite, Inmutable)

Utilizaremos restic para este paso. restic es ideal para backups en la nube gracias a la deduplicación, cifrado y soporte para varios backends, incluyendo S3. Asegúrate de haber configurado las credenciales de AWS (o de tu proveedor S3) mediante variables de entorno (ej. AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) o un archivo de configuración.

Inicializa el repositorio restic en el bucket S3. Reemplaza your-immutable-bucket con el nombre de tu bucket.

export RESTIC_PASSWORD_FILE=/etc/restic/backup_password.txt # Asegúrate de que este archivo esté protegido
export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"

# Inicializa el repositorio (solo la primera vez)
restic init -r s3:s3.amazonaws.com/your-immutable-bucket

Ejecuta el backup de los datos:

restic -r s3:s3.amazonaws.com/your-immutable-bucket backup /srv/data

Este comando creará un backup cifrado y deduplicado en tu bucket S3. Gracias a Object Lock, estos snapshots serán inmutables durante el período de retención configurado, protegiéndote de eliminaciones accidentales o de ataques de ransomware.

5. Cómo verificar que el backup realmente se restaure

La fase de verificación es crucial para el «0» de la regla 3-2-1-1-0. No basta con que el backup termine sin errores; debes estar seguro de que los datos son recuperables.

Verificación de la integridad de los datos (rápida)

restic ofrece un comando check que verifica la integridad del repositorio. Puedes especificar un porcentaje de datos a leer para un control más rápido.

restic -r s3:s3.amazonaws.com/your-immutable-bucket check --read-data-subset=5%

Un output típico:

using temporary cache in /tmp/restic-check-cache-123456
repository a2b3c4d5 opened successfully, password is correct
checking snapshots
checking logs
checking keys
checking data
[0:00] 100.00%  500 / 500 packs
check finished

Restauración completa en entorno de prueba

Este es el test definitivo. Configura una VM de prueba separada, preferiblemente con la misma distribución Linux del servidor original. Luego, restaura el último snapshot del backup en esta VM.

# En la VM de prueba, instala restic y configura las credenciales S3
# Ejecuta la restauración
restic -r s3:s3.amazonaws.com/your-immutable-bucket restore latest --target /tmp/test-restore

Después de la restauración, verifica manualmente la integridad de los datos restaurados. Comprueba que los archivos estén presentes, que los tamaños sean correctos y, si es posible, verifica el hash de algunos archivos críticos respecto a los originales. Automatiza este proceso con scripts que comparen directorios o ejecuten pruebas funcionales sobre los datos restaurados.

Errores Comunes y Resolución de Problemas

Error o mensaje exacto	Causa	Solución
`Error: repository does not exist`	El repositorio `restic` no ha sido inicializado o la ruta es incorrecta.	Ejecuta `restic init` o verifica la ruta del repositorio (`-r`).
`Permission denied` durante el backup	El usuario que ejecuta `restic` no tiene permisos de lectura sobre los datos o de escritura en el destino.	Asegúrate de que el usuario tenga los permisos correctos (`sudo`, `chown`, `chmod`).
Backup lento o falla en S3	Problemas de conectividad, credenciales S3 erróneas, Object Lock no configurado.	Comprueba la conexión de red, las variables de entorno de AWS, y verifica la configuración de Object Lock en el bucket S3.
`Error: data corruption` durante `restic check`	Corrupción de los datos en el repositorio de backup.	Este es un error grave. Podría ser necesario restaurar desde un snapshot anterior o recrear el repositorio si la corrupción es extensa. Comprueba la fiabilidad del almacenamiento de destino.
Restauración falla o datos incompletos	Snapshot corrupto, problemas de permisos en el destino, espacio insuficiente.	Verifica el snapshot con `restic check`, comprueba los permisos en el directorio de destino (`--target`) y el espacio en disco.
`Error: S3 bucket does not support object lock`	El bucket S3 no tiene Object Lock habilitado o está habilitado en modo no compatible.	Crea un nuevo bucket S3 y habilita Object Lock durante la creación (no puede habilitarse después).

Preguntas frecuentes

¿Cuál es la diferencia entre una copia offsite y una copia inmutable?

Una copia offsite es simplemente una copia de los datos que se encuentra en una ubicación geográficamente diferente a la principal. Puede estar en otro centro de datos o en un servicio en la nube. Una copia inmutable, en cambio, es una copia que no puede ser modificada, eliminada o sobrescrita durante un período de tiempo predefinido, independientemente de su ubicación. Una copia inmutable también puede ser offsite, combinando así los beneficios de ambos enfoques.

¿Cada cuánto tiempo debo probar mis backups?

La frecuencia depende de tu Recovery Point Objective (RPO) y Recovery Time Objective (RTO). Para datos muy críticos, las pruebas deberían ser al menos semanales o mensuales. Para entornos menos críticos, trimestrales podrían ser suficientes. Lo importante es que las pruebas sean regulares y automatizadas lo más posible, para reducir la carga manual y garantizar consistencia.

¿El backup 3-2-1-1-0 es válido también para las máquinas virtuales?

Absolutamente sí. La regla es agnóstica respecto al tipo de dato o sistema. Para las VM, los backups pueden ser a nivel de host (ej. con Proxmox Backup Server) o a nivel de invitado. Lo importante es aplicar los principios de copias múltiples, soportes diferentes, offsite, inmutabilidad y pruebas de restauración a todas tus VM críticas.

¿Puedo usar un simple disco USB como copia inmutable?

Un disco USB puede ser considerado una copia offline si se desconecta físicamente después del backup. Esto lo hace inmune a ransomware de red. Sin embargo, no es inmutable en el sentido técnico del término (los datos pueden ser eliminados si el disco se vuelve a conectar). Es una solución económica pero requiere gestión manual y no ofrece la misma protección contra errores humanos o accesos no autorizados como un Object Lock en la nube.

¿El 3-2-1-1-0 me protege de todo tipo de pérdida de datos?

No, ninguna estrategia de backup puede garantizar una protección completa. El 3-2-1-1-0 es un framework robusto que mitiga la mayoría de los riesgos, incluidos ransomware, fallos de hardware, desastres naturales y errores humanos. Sin embargo, no protege de bugs de software que corrompen los datos antes del backup, o de pérdidas de datos entre un backup y otro (a menos que se implemente un sistema de Continuous Data Protection). Es la mejor práctica actual, pero debe integrarse con otras medidas de seguridad.

Conclusiones con Puntos Clave Operativos

La evolución de la regla 3-2-1 a la 3-2-1-1-0 es un paso obligatorio para cualquier administrador de sistemas o responsable de seguridad que quiera garantizar la resiliencia de los datos en un entorno de amenazas en continua evolución. La adición de una copia inmutable u offline y el imperativo de «cero errores» en las pruebas de restauración transforman una buena estrategia de backup en una excelente. Integrar herramientas como restic con servicios en la nube que ofrecen Object Lock permite automatizar gran parte de este proceso, reduciendo el riesgo de errores manuales y garantizando que tu última línea de defensa esté siempre lista. No esperes a que sea demasiado tarde: revisa y actualiza tu estrategia de backup hoy mismo.

Fuentes

Actualizado: noviembre de 2026