Copias de seguridad automáticas de una web: la regla 3‑2‑1 aplicada a tu negocio

Copias de seguridad automáticas de una web: la regla 3‑2‑1 aplicada a un negocio

En la era digital, la continuidad operativa ya no es un lujo, es una obligación contractual y competitiva. Una web caída o unos datos perdidos significan ventas que no se cierran, daño reputacional y, en sectores regulados, posibles sanciones. La raíz de la mayoría de los incidentes críticos es la falta de una estrategia de backup robusta, y la regla 3‑2‑1 sigue siendo la referencia indiscutible para mitigar ese riesgo. En este artículo desglosaremos la regla, la adaptaremos a entornos web modernos y mostraremos cómo su correcta implementación se convierte en una ventaja estratégica para cualquier empresa, desde una pyme con tienda online hasta una empresa con varios entornos.

---

Por qué la mayoría falla en la regla 3‑2‑1

El error más frecuente no es la ausencia de backups, sino la mala arquitectura de los mismos. En la práctica, la mayoría de las pérdidas de datos que vemos se deben a copias guardadas en un único medio o a procesos manuales que dejan de ejecutarse sin que nadie lo note. La causa suele ser una combinación de tres factores:

1. Silos de datos – Los equipos de desarrollo, marketing y operaciones gestionan sus propios repositorios sin un punto de control centralizado. Cada silo crea su propio backup, pero ninguno sigue la regla 3‑2‑1, lo que genera redundancia parcial y, a la larga, inconsistencias.
2. Latencia de restauración – Un backup que tarda más de un día en estar disponible no sirve para una tienda online que necesita recuperarse en horas. La mayoría de los planes de backup tradicionales están diseñados para entornos de archivo, no para aplicaciones de alta disponibilidad.
3. Desacoplamiento insuficiente – Guardar copias en la misma zona geográfica o en la misma infraestructura cloud (por ejemplo, dos snapshots en la misma región de AWS) no protege contra desastres regionales ni contra fallos de proveedor.

Estas deficiencias tienen consecuencias claras: ventas perdidas mientras la web está caída, clientes que no vuelven y, si hay datos personales, obligaciones de notificación según el RGPD. La regla 3‑2‑1 elimina buena parte de esos riesgos al exigir tres copias, en dos tipos de medio distintos y una copia fuera del sitio principal. Pero la teoría no basta: la ejecución exige una arquitectura que contemple tiempos de restauración, retención y pruebas periódicas.

---

La arquitectura correcta

Una arquitectura de backup que respete la regla 3‑2‑1 para una web moderna debe combinar almacenamiento en bloque, object storage y copia física. A continuación, describimos una solución basada en componentes comunes (AWS, Azure, GCP o proveedores locales) que se adapta a cualquier stack LAMP/LEMP, Node.js o serverless.

1. Copia primaria (Media 1 – Almacenamiento en bloque)

   • Qué es: Snapshots de discos EBS (AWS) o Managed Disks (Azure) tomados cada 4 h.
   • Por qué: Permiten restaurar el volumen completo con rapidez. Para bases de datos MySQL o PostgreSQL conviene complementarlos con un volcado lógico, porque un snapshot tomado con la base en marcha puede no ser consistente.
   • Retención: 7 días, con política de rotación automática (ciclo de vida).

2. Copia secundaria (Media 2 – Object Storage)

   • Qué es: Exportación de archivos estáticos y bases de datos en formato SQL dump o Parquet a un bucket S3/Blob/Google Cloud Storage.
   • Por qué: El coste por GB es bajo y el proveedor declara una durabilidad muy alta (S3 anuncia 99,999999999 %). El versionado permite recuperar una versión concreta de un archivo.
   • Retención: 30 días, con versionado activado para evitar sobrescrituras accidentales.

3. Copia off‑site (Media 3 – Almacenamiento físico o Cloud externo)

   • Qué es: Replicación asíncrona a un data center de segunda zona geográfica (por ejemplo, Madrid ↔ Barcelona) o a un proveedor alternativo (AWS ↔ DigitalOcean).
   • Por qué: Asegura que un desastre regional (incendio, corte de fibra) no comprometa la disponibilidad. La replicación se realiza mediante rsync + SSH (hacia un servidor) o AWS DataSync / replicación entre buckets, con cifrado en tránsito y en reposo.
   • Retención: 90 días, con pruebas de restauración mensuales.

Integración con el servicio de mantenimiento

Esta arquitectura se potencia cuando se combina con el servicio de mantenimiento de El Laboratorio, que incluye monitorización de integridad de backups, pruebas automatizadas de restauración y ajustes de políticas de retención según el crecimiento del tráfico. Más información en nuestra página de servicios de mantenimiento.

Diagrama de flujo (descriptivo)

1. Trigger: Cada 4 h, un cron job dispara la creación del snapshot.
2. Orquestador: Un AWS Step Functions o Azure Logic Apps coordina la exportación al bucket y la replicación off‑site.
3. Validación: Un script de checksum SHA‑256 verifica la integridad de cada copia.
4. Alertas: Si alguna verificación falla, se envía un SNS o Teams webhook al equipo de operaciones.

Con esta arquitectura la copia primaria es la vía rápida de restauración y la secundaria cubre los casos en que falla el volumen. Los tiempos reales dependen del tamaño de los datos: se miden en la primera prueba de restauración y se anotan como objetivo (RTO).

---

Implementación paso a paso

A continuación, una guía práctica para poner en marcha la regla 3‑2‑1 en una web basada en Ubuntu 22.04, NGINX, MySQL 8 y AWS. Los pasos son aplicables a otras nubes con ajustes menores.

1. Crear roles y políticas IAM

   aws iam create-role --role-name BackupOperator \
     --assume-role-policy-document file://trust-policy.json
   aws iam put-role-policy --role-name BackupOperator --policy-name backup-minimo \
     --policy-document file://backup-policy.json

   Justificación: backup-policy.json solo concede ec2:CreateSnapshot, ec2:CreateTags y s3:PutObject sobre el bucket de copias. Evita políticas como AmazonS3FullAccess: si se compromete la web, el atacante no debería poder borrar los backups. Activa también el bloqueo de objetos (Object Lock) o el versionado con MFA para el borrado.

2. Configurar snapshots automáticos

   aws ec2 create-snapshot --volume-id vol-0abcd1234efgh5678 \
     --description "Web primary snapshot $(date +%F_%H-%M)" \
     --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Backup,Value=Primary}]'

   Programa con cron (0 */4 * * * /usr/local/bin/create_snapshot.sh).

3. Exportar base de datos a S3

   # Credenciales en ~/.my.cnf (chmod 600), nunca en la línea de comandos
   mysqldump --defaults-extra-file=/root/.my.cnf --single-transaction \
     --quick mydb | gzip > /tmp/mydb_$(date +%F).sql.gz
   aws s3 cp /tmp/mydb_$(date +%F).sql.gz s3://my-backup-bucket/db/ \
     --storage-class STANDARD_IA
   rm /tmp/mydb_*.sql.gz

   Ejecutar cada 6 h mediante cron.

4. Sincronizar archivos estáticos

   aws s3 sync /var/www/html/ s3://my-backup-bucket/files/ \
     --exclude '*.tmp' --exclude 'cache/*' --profile backup

   aws s3 sync copia solo lo que ha cambiado. No uses --delete salvo que el bucket tenga versionado activo: sin él, un borrado accidental en el servidor se propagaría a la copia.

5. Replicación off‑site

   • Opción A (servidor propio o de otro proveedor): sincroniza por SSH con una clave dedicada que solo pueda escribir en el destino.

     rsync -az -e "ssh -i /root/.ssh/backup_key" \
       /var/backups/web/ [email protected]:/srv/backups/web/

   • Opción B (otro proveedor cloud): replica el bucket a otra región o a otro proveedor con la herramienta de replicación nativa o con rclone.
   • En ambos casos la copia off‑site debe estar en una cuenta o credencial distinta de la del servidor web.

6. Probar la restauración

   • Una vez al mes, restaura la última copia en un entorno aparte y comprueba que la web arranca y que los datos se leen.
   • Anota cuánto tarda: ese tiempo es tu RTO real, y la antigüedad de la copia más reciente es tu RPO real.

7. Vigilar que las copias se hacen

   • Un backup que falla en silencio es el fallo más habitual. Envía una alerta si no aparece una copia nueva en el plazo previsto, además de si un trabajo termina con error.

---

Errores que debes evitar

• Guardar las copias en el mismo servidor que la web: un fallo de disco o un ransomware se llevan ambas.
• No probar nunca la restauración. Una copia que no se ha restaurado es una hipótesis.
• Credenciales con permisos de borrado accesibles desde el servidor web.
• Copiar solo los archivos o solo la base de datos. Una web necesita ambas, y con la misma fecha.
• Retención sin criterio. Guardar siete días no sirve si un problema se detecta a las dos semanas.

---

Qué medir

• RPO: cuántos datos puedes perder, es decir, la antigüedad máxima aceptable de la última copia.
• RTO: cuánto tiempo puede estar la web caída mientras restauras.
• Tasa de éxito de los trabajos de copia y de las pruebas de restauración.
• Coste mensual del almacenamiento frente al coste de una hora de parada para tu negocio.

Estos valores dependen de cada negocio. Defínelos antes de elegir herramientas, porque determinan cada cuánto se copia y dónde.

Conclusión

La regla 3‑2‑1 es sencilla de enunciar y exigente de cumplir: tres copias, dos medios, una fuera del sitio, con permisos mínimos y restauraciones probadas. Si prefieres que lo monte y lo vigile alguien, consulta nuestro servicio de mantenimiento web o contacta con el equipo.