Copias de seguridad en servidores

Nadie piensa demasiado en las copias de seguridad hasta el día en que las necesita de verdad. Un disco que falla, un ataque de ransomware, un error humano que borra una base de datos completa, una actualización que corrompe el sistema... En cualquiera de esos escenarios, la diferencia entre una interrupción de minutos y una catástrofe de días (o la pérdida total de datos) suele ser una sola cosa: si existía una copia de seguridad fiable y probada.

En este artículo vemos cómo diseñar una estrategia de backups sólida para servidores, qué tipos de copia existen, cómo aplicar la regla 3-2-1 y, sobre todo, cómo asegurarte de que esas copias realmente sirven cuando llega el momento de restaurar.

Por qué las copias de seguridad no son opcionales

Es habitual pensar que "mi proveedor cloud ya hace backups" o que "el RAID me protege ante fallos de disco". Ambas ideas son parcialmente ciertas pero peligrosamente incompletas:

• El RAID protege ante el fallo físico de un disco, pero no ante un borrado accidental, una corrupción de datos o un ataque de ransomware que cifra archivos en todos los discos a la vez.
• Los backups automáticos de muchos proveedores cloud suelen tener una retención limitada y, en muchos casos, no cubren todos los escenarios de pérdida de datos (por ejemplo, si borras un recurso completo, no siempre hay backup de lo que había dentro). La copia de seguridad es la última línea de defensa: cuando todo lo demás falla (seguridad, redundancia, buenas prácticas), es lo único que garantiza poder volver a un estado funcional.

Tipos de copia de seguridad

Copia completa (full backup)

Copia todos los datos seleccionados, cada vez. Es la más sencilla de restaurar (solo necesitas la última copia), pero también la que más espacio y tiempo consume.

Copia incremental

Solo copia los cambios desde la última copia (completa o incremental). Es rápida y ocupa poco espacio, pero restaurar requiere aplicar la copia completa más todas las incrementales en orden, lo que es más lento y algo más frágil (si una copia intermedia falla, se rompe la cadena).

Copia diferencial

Copia los cambios desde la última copia completa (no desde la última incremental). Ocupa más que la incremental pero la restauración es más simple: solo necesitas la última completa y la última diferencial.

Una estrategia habitual combina una copia completa semanal con copias incrementales o diferenciales diarias, equilibrando espacio de almacenamiento y velocidad de restauración.

La regla 3-2-1 (y su evolución 3-2-1-1-0)

Es el estándar de facto en estrategias de backup:

• 3 copias de los datos en total (la copia original más dos copias de seguridad).

• 2 soportes o tipos de almacenamiento distintos (por ejemplo, disco local y almacenamiento en la nube).

• 1 copia fuera del sitio físico (offsite), para protegerse ante desastres que afecten a la ubicación principal (incendio, robo, inundación). Una versión más moderna añade dos elementos frente a amenazas actuales como el ransomware:

• 1 copia offline o inmutable (que no pueda ser modificada ni cifrada por un atacante que haya comprometido el sistema).

• 0 errores: verificar regularmente que las copias se pueden restaurar sin errores.

# Ejemplo simple de backup con rsync a un destino remoto
rsync -avz --delete /var/www/ usuario@servidor-backup:/backups/www/
 
# Ejemplo de backup con compresión y fecha en el nombre
tar -czf /backups/db_$(date +%Y%m%d).tar.gz /var/lib/mysql/

Herramientas habituales para backups en servidores

• rsync: sincronización eficiente de archivos, ideal para copias incrementales a nivel de sistema de archivos.
• Bacula / Bareos: soluciones robustas de backup empresarial con gestión centralizada de múltiples servidores.
• Restic / Borg Backup: herramientas modernas con cifrado, deduplicación y compresión eficiente, muy populares en entornos self-hosted.
• Herramientas nativas de base de datos: mysqldump o pg_dump para bases de datos MySQL/PostgreSQL, que generan copias consistentes de los datos.
• Snapshots de proveedores cloud: útiles como complemento, pero no deberían ser la única estrategia de backup.

# Ejemplo de dump de una base de datos MySQL
mysqldump -u usuario -p nombre_basedatos > backup_$(date +%Y%m%d).sql

Diseñar un plan de recuperación ante desastres (Disaster Recovery)

Tener copias de seguridad es solo la mitad del trabajo. La otra mitad es saber exactamente qué hacer cuando hay que restaurar. Un buen plan de recuperación debe definir:

• RPO (Recovery Point Objective): cuánta pérdida de datos es aceptable, medida en tiempo. Si haces backups cada 24 horas, tu RPO es de 24 horas: en el peor caso, perderías un día de datos.
• RTO (Recovery Time Objective): cuánto tiempo puede estar el servicio caído hasta restaurarse por completo.
• Procedimiento documentado: pasos concretos, en orden, para restaurar cada componente del sistema (no debería depender de la memoria de una sola persona).
• Responsables asignados: quién ejecuta la recuperación y quién tiene que ser informado.

La importancia de probar las restauraciones

Este es, con diferencia, el punto que más administradores se saltan. Un backup que nunca se ha probado es, en la práctica, un backup del que no sabes si funciona. Es relativamente común descubrir, en pleno incidente, que:

• El backup estaba corrupto o incompleto.
• Faltaban credenciales o configuraciones necesarias para restaurar (no solo los datos, también el contexto).
• El proceso de restauración tardaba muchísimo más de lo esperado, incumpliendo el RTO definido. La recomendación es simple aunque incómoda: programa restauraciones de prueba periódicas, en un entorno aislado, para verificar que las copias son realmente utilizables.

Buenas prácticas

1. Automatiza las copias de seguridad; no dependas de que alguien se acuerde de hacerlas manualmente.
2. Verifica la integridad de cada copia tras generarla (checksums, logs de éxito/error).
3. Cifra las copias, especialmente si contienen datos sensibles y se almacenan fuera de tu infraestructura.
4. Mantén al menos una copia inmutable o desconectada de la red, como protección frente a ransomware.
5. Documenta el proceso de restauración paso a paso, actualizado.
6. Revisa periódicamente las políticas de retención: cuántas copias guardas y durante cuánto tiempo.
7. Monitoriza que las tareas de backup se completan correctamente, con alertas si fallan.

Errores habituales

El error más costoso es no probar nunca las restauraciones, seguido de cerca por tener todas las copias en la misma ubicación física o en el mismo proveedor que los datos originales, lo que anula buena parte de la protección. También es frecuente olvidar backups de elementos "no obvios", como configuraciones de servidores, certificados, variables de entorno o credenciales de aplicaciones, centrando todo el esfuerzo solo en las bases de datos.

Conclusión

Una estrategia de copias de seguridad sólida combina tipos de copia adecuados a cada necesidad, la regla 3-2-1 (o su versión ampliada 3-2-1-1-0) y, sobre todo, pruebas periódicas de restauración. No se trata de acumular copias por acumular, sino de tener la certeza de que, ante cualquier incidente, es posible recuperar los datos y el servicio dentro de un tiempo razonable.

Invertir tiempo en diseñar y probar bien esta estrategia es, sin exagerar, una de las decisiones más rentables que puede tomar cualquier administrador de sistemas: cuesta poco comparado con el coste real de una pérdida de datos irrecuperable.