Todo el mundo tiene backups hasta que los necesita. El dato incómodo de la profesión: la mayoría de sistemas de copias falla exactamente en el día crítico —porque nunca se probó una restauración, porque el destino estaba corrupto desde hacía meses, o porque ransomware cifró también las copias conectadas—. Este artículo construye un sistema de backup que sobrevive a esas trampas, con verificación criptográfica incluida.
La regla 3-2-1 (y su evolución)
El estándar clásico sigue siendo el punto de partida correcto:
- 3 copias de los datos: el original + dos backups.
- 2 medios distintos: por ejemplo disco local + almacenamiento en la nube. Un solo medio = un único modo de fallo.
- 1 copia fuera de ubicación: si el incendio, el robo o el ransomware afectan al local, la externa sobrevive.
La versión moderna añade una cuarta letra: 3-2-1-1-0, donde el extra significa:
- 1 copia inmutable/offset: un storage que no puede modificarse ni borrarse durante un período (S3 Object Lock, snapshots inmutables). Es la única defensa real contra ransomware que busca activamente shares de red para cifrar también los backups.
- 0 errores verificados: cero copias sin verificar. Un backup no comprobado es una esperanza, no un backup.
Qué copiar: la jerarquía que casi todos ignoran
No todo merece la misma política. Ordena tus datos por criticidad y tasa de cambio:
- Datos irremplazables (bases de datos, código fuente, documentos propios): frecuencia diaria, retención larga.
- Reconstruibles con esfuerzo (configuraciones, entornos): versionarlos en git suele bastar; copia semanal.
- Regenerables (node_modules, builds, caches): no se copian jamás — exclúyelos explícitamente.
Para bases de datos, el matiz crítico: copiar el fichero de datos en caliente produce backups corruptos. Usa los volcados lógicos (pg_dump, mysqldump) o snapshots consistentes del volumen. En Docker, recuerda que el volumen no es backup — hay que volcarlo.
Automatización mínima viable
Un cron nocturno con rsync cubre el 80% de casos personales:
#!/bin/bash
set -euo pipefail
DEST="/mnt/backup/$(date +%Y-%m-%d)"
SRC="/srv/datos"
rsync -a --delete --link-dest="/mnt/backup/latest" "$SRC/" "$DEST/"
ln -sfn "$DEST" /mnt/backup/latest
# Verificación de integridad del lote
find "$DEST" -type f -exec sha256sum {} + > "$DEST.sha256"
# Rotación: borrar lotes de más de 30 días
find /mnt/backup -maxdepth 1 -mtime +30 -exec rm -rf {} +
Los --link-dest crean backups incrementales que ocupan como diferenciales pero funcionan como completos (hard links a ficheros sin cambios). Y la línea clave es la de sha256sum: genera el manifiesto de hashes de cada copia — el fundamento de la verificación que viene ahora.
Verificación de integridad: por qué los bits se corrompen
Las copias se degradan silenciosamente: sectores defectuosos, RAM sin ECC con errores cósmicos reales, cables SATA problemáticos, bugs de sincronización en nube. El fenómeno tiene nombre — bit rot — y su peligro es que no avisa: el fichero abre... hasta que llega a la zona dañada.
La defensa es matemática: el hash SHA-256 de cada fichero calculado en el momento del backup actúa como huella digital. Cualquier alteración posterior —un solo bit— cambia el hash por completo (efecto avalancha). La verificación periódica compara:
cd /mnt/backup/2026-08-15
sha256sum -c 2026-08-15.sha256 --quiet && echo "OK" || echo "CORRUPCIÓN DETECTADA"
Automatizado mensualmente sobre muestras rotativas (o todo, si el volumen lo permite), convierte la corrupción silenciosa en alerta temprana. Para verificar ficheros sueltos —una descarga crítica, un documento importante— nuestro verificador de hashes calcula SHA-256 en el navegador sin subir el fichero a ninguna parte.
La prueba de restauración: la parte que todos saltan
Un backup sin restauración probada es teoría. La prueba completa, trimestral como mínimo:
- Restaura un conjunto aleatorio de ficheros a una ubicación temporal.
- Compara hashes contra el manifiesto.
- Abre documentos representativos; arranca la base de datos restaurada y ejecuta consultas.
- Cronometra el proceso: tu RTO real (tiempo de recuperación) es ese número, no el que dice el plan.
Apunta el resultado. Si restaurar 500 GB tarda 6 horas y tu negocio aguanta 2, tienes un hallazgo, no un backup.
Retención y cifrado
Dos decisiones finales de diseño:
Retención escalonada vence a retención larga uniforme: diarios de 7 días, semanales de 4 semanas, mensuales de 12, anuales según normativa. Cubre borrado accidental reciente (ayer), corrupción lenta (meses atrás) y obligaciones legales.
Cifrado siempre que salga de tu hardware: restic y borg cifran nativamente antes de enviar; en nube, activa cifrado del lado cliente además del del proveedor — la copia que un atacante roba del bucket no debe ser legible. Y protege el acceso: credenciales del backup separadas de las del sistema principal, o el ransomware con acceso admin borra ambos mundos.
Preguntas frecuentes
¿RAID cuenta como backup? No. RAID protege frente a fallo de disco, no frente a borrado accidental, corrupción lógica, ransomware o incendio. Es redundancia, otra cosa distinta.
¿Cada cuánto verificar hashes? Mensual sobre toda la colección pequeña; en colecciones grandes, muestreo rotativo que cubra el 100% cada trimestre. Tras cualquier incidente de disco, verificación completa inmediata.
¿Servicios de nube automáticos? Válidos y convenientes, con dos condiciones: cifrado client-side (la clave no viaja al proveedor) y exportabilidad demostrada — prueba a recuperar tus datos sin su app oficial antes de necesitarlo de verdad.
Verifica la integridad de cualquier fichero con nuestro calculador de hashes, gratis y directamente en tu navegador.