En algún momento, todo administrador Linux tiene la misma revelación silenciosa: el servidor es estable, hasta que deja de serlo: y NO porque Linux sea inestable, sino porque todo lo que lo rodea sí lo es.
Discos SSD que fallan sin avisar. Actualizaciones que rompen dependencias. Un rm -rf ejecutado en el directorio equivocado. Ransomware que cifra volúmenes completos. Corrupciones silenciosas.
Por eso, si administras servidores Linux, necesitas algo más que “hacer backups”. Necesitas una estrategia de recuperación diseñada para sobrevivir fallos reales.
Aquí te explico cómo implementar la estrategia de backup 3-2-1 en Linux, basada en experiencia práctica y en escenarios que todo sysadmin debería anticipar.
¿Qué es la estrategia de backup 3-2-1?
La regla 3-2-1 es un estándar clásico en administración de sistemas:
- 3 copias de los datos
- 2 tipos diferentes de almacenamiento
- 1 copia fuera del sitio (off-site)
Pero el valor real no está en los números. Está en la mentalidad de diseñar asumiendo que algo fallará.
¿Qué protege realmente cada una de las partes?
| Principio | Te protege contra |
|---|---|
| 3 copias | Corrupción silenciosa, borrados accidentales, errores humanos |
| 2 tipos de almacenamiento | Fallos de disco, bugs del sistema de archivos, fallos de controlador |
| 1 copia off-site | Ransomware, robo, incendio, pérdida total del host |
Cuando entiendes esto, la estrategia deja de ser teoría y se convierte en arquitectura.
Paso 1: Decidir qué datos realmente deben respaldarse
Uno de los errores más comunes en Linux es intentar hacer backup de absolutamente todo. Esto, terminando generando:
- Restauraciones lentas
- Backups gigantes
- Recuperaciones problemáticas
Lo más interesantes es, dividir el servidor en dos categorías: los datos irremplazables y los datos reconstruibles.
Los Datos Irremplazables (sí se respaldan)
Son datos que representan tiempo, decisiones o trabajo humano:
- Directorios de aplicaciones
- Bases de datos (exportadas como dumps lógicos, no archivos en caliente)
/etc(configuración del sistema)- Cron jobs y tareas automatizadas
- Scripts personalizados
- Contenido generado por usuarios
Datos reconstruibles (no se respaldan)
Respaldar esto suele ser un error:
- El sistema operativo
- Paquetes instalados
- Cachés
- Logs temporales
El sistema se reinstala limpio y los datos son lo que realmente nos importa salvar.
Con esta decisión vas a reducir el tamaño, la complejidad y tiempo de recuperación.
Copia 1: Producción (la copia frágil)
El servidor en producción ya es una copia de los datos; pero es..
- La más expuesta
- La que más cambia
- La primera que cae
Por eso, debes considerar el sistema en producción como efímero: todo lo demás existe para sobrevivir a su caída.
Copia 2: Backup local en almacenamiento separado
Aquí es donde muchas estrategias fallan, un backup en el mismo disco NO es un backup.
La segunda copia debe de:
- Vivir en un almacenamiento distinto
- Idealmente en otro volumen o dispositivo
- Ejecutarse automáticamente
- Generar backups incrementales
¿Qué se encarga de proteger esta copia?
- Borrados accidentales
- Cambios de configuración erróneos
- Actualizaciones fallidas
- Errores humanos recientes
Es la vía de recuperación más rápida, pero esto aún NO es suficiente.
Copia 3: Backup Off-Site en almacenamiento externo
Aquí es donde la estrategia 3-2-1 se vuelve crítica ante los casos más graves, por ejemplo si ocurre alguno de los siguientes problemas:
- Ransomware
- Robo físico
- Incendio
- Corrupción masiva
- Fallo total del host
Todo lo local desaparece y, por eso la tercera copia debe “vivir” fuera de tu la propia infraestructura del sistema.
Las opciones más comunes son:
- Amazon S3
- Backblaze B2
- Almacenamiento S3-compatible
- Servidor remoto en otra ubicación física
Lo importante no es la marca, lo importante es que sea..
- Externo
- Aislado
- Encriptado
- Con políticas de retención
Aquí es donde realmente se diseña para los desastres reales.
El “2” en 3-2-1: Por qué importa la diversidad de almacenamiento
Muchas personas interpretan mal esta parte, puesto que NO significa “dos proveedores”. Significa dos dominios de fallo diferentes.
Lo más ideal dentro de una arquitectura segura es:
- Backup local → almacenamiento en bloque
- Backup remoto → almacenamiento distribuido de objetos
Así, estarás protegido ante fallas por razones distintas: un bug en el filesystem no afecta al almacenamiento de objetos o una caída cloud, no afectará al recovery local.
Esta separación es intencional.
Automatización: No es opcional
Si los backups dependen de la memoria humana, fallarán. SIEMPRE. Todo debe estar automatizado:
- Programación
- Retención
- Encriptación
- Subida a almacenamiento externo
- Verificación de integridad
- Alertas de fallo
CONSEJO RELEVANTE: Si un backup falla y no te enteras de ello, deberías asumir que NO tienes backup.
Pruebas de restauración: el muy importante paso que casi todos ignoran
Un backup que NUNCA has restaurado NO es un backup. Es solamente una esperanza que NO sabes si saldrá bien. Por tanto, debes probar periódicamente:
- La restauración de archivos individuales
- La restauración de directorios completos
- La validación de dumps de base de datos
- Los permisos y ownership
- El correcto funcionamiento de los servicios tras la restauración
La mayoría de los fallos no son por datos faltantes. Normalmente, son por:
- Permisos incorrectos
- Paths erróneos
- Dependencias de servicios
Descubrir esto, a la hora de una emergencia será demasiado tarde. Por ello, debes afrontar esos posibles problemas antes.
Errores más comunes en estrategias de backup Linux
- ❌ Guardar backups en el mismo disco
- ❌ No cifrar la copia off-site
- ❌ No tener retención versionada
- ❌ No probar restauraciones
- ❌ Respaldar el sistema operativo completo sin necesidad
- ❌ No tener alertas de fallo
Conclusión
Una estrategia 3-2-1 bien implementada NO es un método paranoico. Es la metodología más honesta y segura.
Debes tener en cuenta, que los servidores fallan y las personas cometen errores. Además, el software, nunca sabes cuando te puede llegar a sorprender con un funcionamiento extraño o erróneo.
Si diseñes tu arquitectura con capas, aislamiento y capacidad real de recuperación; vas a obtener algo fundamental: un sistema -cuasi- completamente predecible.
Y en los backups, lo predecible es lo que puede salvar a tu empresa; porque en recuperación de los datos más importantes, lo emocionante será lo último que querrás experimentar.