Cómo implementar una estrategia de copias de seguridad y recuperación ante desastres en servidores Linux

Idea central: un backup que no se puede restaurar no es un backup. La recuperación debe probarse antes del desastre, no durante la emergencia.

Elementos críticos en servidores Linux

• Configuración: /etc, archivos systemd, nginx, apache, ssh, firewall, cron.
• Datos de aplicaciones: /var/www, /srv, /opt, directorios de sistemas internos.
• Bases de datos: PostgreSQL, MariaDB, MySQL, MongoDB u otras.
• Usuarios y claves: cuentas, llaves SSH, certificados TLS, credenciales de servicios.
• Contenedores: volúmenes Docker, manifiestos Compose, imágenes críticas, Kubernetes YAML.
• Logs necesarios: logs de auditoría, seguridad, transacciones y cumplimiento.
• Documentación: pasos de restauración, arquitectura, IP, DNS, responsables y dependencias.

Importante: una copia sincronizada en la nube no siempre es suficiente. Si un ransomware cifra archivos locales y la sincronización replica esos cambios, la copia remota también puede quedar afectada.

sudo apt update
sudo apt install -y borgbackup

borg init --encryption=repokey-blake2 backup@servidor-backup:/backups/servidor-linux

borg create --stats --progress \
  backup@servidor-backup:/backups/servidor-linux::'{hostname}-{now:%Y-%m-%d_%H:%M}' \
  /etc \
  /home \
  /var/www \
  /srv \
  --exclude '/home/*/.cache'

borg prune --list \
  --keep-daily=7 \
  --keep-weekly=4 \
  --keep-monthly=6 \
  backup@servidor-backup:/backups/servidor-linux

export RESTIC_REPOSITORY=sftp:backup@servidor-backup:/backups/restic-servidor
export RESTIC_PASSWORD='colocar-una-clave-larga-y-segura'

restic init

restic backup /etc /home /var/www /srv \
  --exclude '/home/*/.cache'

restic snapshots
restic check

Cuidado: guarda la contraseña de cifrado en un gestor seguro. Si pierdes la clave, no podrás restaurar los backups cifrados.

sudo -u postgres pg_dump -Fc basedatos > /backups/basedatos_$(date +%F).dump

#!/bin/bash
set -euo pipefail

export RESTIC_REPOSITORY="sftp:backup@servidor-backup:/backups/restic-servidor"
export RESTIC_PASSWORD_FILE="/root/.restic-password"

restic backup /etc /home /var/www /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/sbin/backup-restic.sh
sudo chmod 600 /root/.restic-password

mkdir -p /tmp/prueba-restore
restic restore latest --target /tmp/prueba-restore

find /tmp/prueba-restore -maxdepth 3 -type f | head

Checklist de prueba de restauración

1. Restaurar en un servidor de prueba.
2. Verificar integridad de archivos.
3. Restaurar base de datos.
4. Validar permisos y propietarios.
5. Levantar servicios.
6. Probar acceso de usuarios.
7. Medir tiempo total de recuperación.
8. Documentar errores encontrados.

Controles obligatorios

• Cifrar backups antes de enviarlos fuera del servidor.
• Usar credenciales distintas para producción y backup.
• No permitir que el servidor productivo borre todas las copias históricas.
• Activar almacenamiento inmutable cuando sea posible.
• Mantener una copia offline o aislada.
• Proteger claves de cifrado en gestor seguro.
• Registrar cada restauración y acceso al repositorio.
• Probar recuperación desde una copia aislada.

• Estado de último backup exitoso.
• Tamaño del backup comparado con días anteriores.
• Errores de conexión al repositorio remoto.
• Espacio disponible en almacenamiento de backup.
• Resultado de pruebas de integridad.
• Tiempo de ejecución de cada tarea.
• Resultado de restauraciones de prueba.

• Guardar el backup en el mismo servidor.
• No cifrar copias externas.
• No probar restauración.
• Respaldar archivos de base de datos sin consistencia.
• No documentar pasos de recuperación.
• Usar una sola copia en la nube como única protección.
• No proteger credenciales del repositorio de backup.
• No monitorear fallos de tareas automáticas.
• No tener copia offline o inmutable.
• No medir RTO y RPO reales.

¿Cada cuánto debo hacer backup?

Depende del RPO. Para archivos poco cambiantes puede bastar una vez al día. Para bases de datos críticas puede requerirse respaldo continuo, WAL archiving o replicación complementaria.

¿rsync es suficiente?

Para copias simples puede servir, pero no reemplaza versiones históricas, cifrado, deduplicación, retención ni protección contra borrado accidental o ransomware.

¿La nube reemplaza al backup?

No. La nube es un destino posible, pero debe configurarse con cifrado, control de acceso, versionado, inmutabilidad y pruebas de restauración.

¿Una réplica es lo mismo que un backup?

No. La réplica ayuda con disponibilidad, pero también puede replicar errores, borrados o corrupción. El backup permite volver a un punto anterior.

¿Qué es recuperación ante desastres?

Es el conjunto de procesos para reconstruir servicios críticos después de caída, pérdida de datos, ransomware, error humano, falla de hardware o desastre físico.

¿Qué debo probar primero?

Restaurar un archivo, luego un directorio completo, después una base de datos y finalmente un servidor completo en ambiente de prueba.

• Comandos básicos que debes aprender para administrar tu servidor Linux
• Por qué los servidores usan Linux: ventajas para empresas y administradores TI
• Ciberseguridad en Linux: 50 herramientas gratuitas para proteger servidores y estaciones
• Las 25 herramientas de ciberseguridad open source más utilizadas por administradores y analistas

Conclusión editorial

El verdadero backup no es el archivo guardado: es la capacidad demostrada de recuperar el servicio. Una empresa preparada no pregunta “¿tenemos copias?”, sino “¿ya probamos restaurar, cuánto tardamos y qué datos perderíamos?”. Esa diferencia separa una copia improvisada de una estrategia real de continuidad.