Cómo hacer backup de un servidor Linux: rsync, cron, MySQL y restic

Un fallo de disco, un rm accidental o un ataque de ransomware pueden borrar sus datos en segundos, por eso una buena copia de seguridad del servidor Linux es imprescindible. Esta guía combina cuatro métodos complementarios: rsync hacia otro servidor, archivos tar programados con cron, volcados rotativos de MySQL/MariaDB y backups cifrados con restic en un almacenamiento compatible con S3, seguidos de pruebas de restauración. Los comandos funcionan en Debian/Ubuntu y Rocky Linux/AlmaLinux.

Paso 1: Haga backup en otro servidor con rsync

rsync transfiere solo lo que ha cambiado, lo que lo hace ideal para directorios de sitios web y configuración. En el servidor de backup, cree un usuario normal llamado backup y el directorio /backup/web01; en el servidor de origen, cree una clave SSH dedicada (consulte nuestro tutorial de claves SSH). --delete elimina en el destino los archivos que ya no existen en el origen, así que haga primero una simulación con -n.

# Instalar rsync en AMBOS servidores
apt install -y rsync        # Debian / Ubuntu
dnf install -y rsync        # Rocky Linux / AlmaLinux

# En el servidor de origen: clave dedicada para los backups
ssh-keygen -t ed25519 -f /root/.ssh/backup_key -N ""
ssh-copy-id -i /root/.ssh/backup_key.pub -p 22 [email protected]

# Primero una vista previa (-n = simulación) y después la ejecución real
rsync -aHn --delete -e "ssh -i /root/.ssh/backup_key -p 22" \
  /etc /var/www [email protected]:/backup/web01/
rsync -aH --delete -e "ssh -i /root/.ssh/backup_key -p 22" \
  /etc /var/www [email protected]:/backup/web01/

Paso 2: Archivos programados con tar y cron

rsync crea un espejo: si borra algo en el origen, la siguiente sincronización también lo borra en el backup. Compleméntelo con un archivo tar fechado cada día y conserve los últimos siete. El script elimina los archivos antiguos con find -mtime y cron lo ejecuta cada noche.

cat > /usr/local/bin/backup-files.sh <<'EOF'
#!/bin/bash
set -euo pipefail
DEST=/backup/files
KEEP_DAYS=7
mkdir -p "$DEST"
# tar exit code 1 = "file changed while reading", which is acceptable
tar -czpf "$DEST/files-$(date +%F).tar.gz" /etc /var/www /root || [ $? -eq 1 ]
find "$DEST" -name 'files-*.tar.gz' -mtime +$KEEP_DAYS -delete
EOF
chmod 700 /usr/local/bin/backup-files.sh
/usr/local/bin/backup-files.sh && ls -lh /backup/files

# Programación: crontab -e
10 3 * * * /usr/local/bin/backup-files.sh >> /var/log/backup.log 2>&1

Paso 3: Backups automáticos de MySQL/MariaDB con rotación

Copiar los archivos de una base de datos en funcionamiento suele producir un backup corrupto; exporte con mysqldump o mariadb-dump. --single-transaction toma una instantánea coherente de InnoDB sin bloquear las tablas. El script vuelca cada base de datos por separado, la comprime con gzip y conserva 14 días. Las credenciales se guardan en /root/.my.cnf con permisos 600 para que la contraseña nunca aparezca en la línea de comandos ni en la lista de procesos.

# Credenciales (omita este paso si root puede entrar en MariaDB/MySQL mediante unix_socket)
cat > /root/.my.cnf <<'EOF'
[client]
user=root
password=YourDatabaseRootPassword
EOF
chmod 600 /root/.my.cnf

cat > /usr/local/bin/backup-db.sh <<'EOF'
#!/bin/bash
set -euo pipefail
DEST=/backup/mysql
KEEP_DAYS=14
mkdir -p "$DEST"
CLIENT=$(command -v mariadb || command -v mysql)
DUMP=$(command -v mariadb-dump || command -v mysqldump)
for DB in $("$CLIENT" -N -e "SHOW DATABASES" | grep -Ev '^(information_schema|performance_schema|sys)$'); do
  "$DUMP" --single-transaction --routines --triggers --events "$DB" \
    | gzip > "$DEST/$DB-$(date +%F_%H%M).sql.gz"
done
find "$DEST" -name '*.sql.gz' -mtime +$KEEP_DAYS -delete
EOF
chmod 700 /usr/local/bin/backup-db.sh

# Programación: crontab -e
20 2 * * * /usr/local/bin/backup-db.sh >> /var/log/backup.log 2>&1

Paso 4: Backups cifrados en almacenamiento compatible con S3 con restic

restic ofrece deduplicación, cifrado e instantáneas, y funciona con AWS S3, Cloudflare R2, MinIO y cualquier otro servicio compatible con S3. Incluya el directorio de volcados de bases de datos del paso 3 para tener una copia externa de todo. forget --prune aplica una política de retención diaria/semanal/mensual y libera espacio.

# Instalar restic
apt install -y restic                                   # Debian / Ubuntu
dnf install -y epel-release && dnf install -y restic    # Rocky / AlmaLinux

# Configuración del repositorio para un bucket compatible con S3
cat > /root/.restic.env <<'EOF'
export AWS_ACCESS_KEY_ID=YOUR_ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=YOUR_SECRET_KEY
export RESTIC_REPOSITORY=s3:https://s3.example.com/my-backup-bucket/web01
export RESTIC_PASSWORD_FILE=/root/.restic.pass
EOF
openssl rand -base64 32 > /root/.restic.pass
chmod 600 /root/.restic.env /root/.restic.pass

. /root/.restic.env
restic init
restic backup /etc /var/www /backup/mysql
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic snapshots

# Programación: crontab -e
40 3 * * * { . /root/.restic.env && restic backup -q /etc /var/www /backup/mysql && restic forget -q --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune; } >> /var/log/restic.log 2>&1

Paso 5: Pruebe la restauración de sus backups con regularidad

Un backup que nunca se ha restaurado es solo una esperanza. Haga un simulacro de restauración al menos una vez al mes: extraiga archivos en una carpeta temporal, importe un volcado en una base de datos de prueba y compare el número de filas, y ejecute restic check. Lo ideal es reconstruir una vez todo en un servidor nuevo y anotar cuánto tiempo lleva.

# Archivos: listar un archivo tar y extraer un directorio en una carpeta temporal
tar -tzf /backup/files/files-2026-10-01.tar.gz | head
mkdir -p /tmp/restore
tar -xzf /backup/files/files-2026-10-01.tar.gz -C /tmp/restore etc/nginx

# Base de datos: importar en una base de datos desechable y comparar
mysql -e "CREATE DATABASE restore_test"
gunzip -c /backup/mysql/shop-2026-10-01_0220.sql.gz | mysql restore_test
mysql -e "SELECT COUNT(*) FROM restore_test.orders"
mysql -e "DROP DATABASE restore_test"

# restic: verificar el repositorio y restaurar la última instantánea
. /root/.restic.env
restic check
restic restore latest --target /tmp/restic-restore --include /etc/nginx

Preguntas frecuentes

Los backups están llenando el disco. ¿Qué hago?

Reduzca KEEP_DAYS, excluya cachés y logs (--exclude con tar) y mueva los backups a otro servidor o a un almacenamiento de objetos. Consulte nuestro tutorial sobre disco lleno para obtener consejos de limpieza.

¿La tarea de cron nunca se ejecuta?

Revise /var/log/backup.log y journalctl -u cron (crond en Rocky). Cron usa un PATH mínimo, así que utilice rutas completas en los scripts y asegúrese de que el script sea ejecutable.

¿Volcar una base de datos grande ralentizará mi sitio?

Con InnoDB y --single-transaction las tablas no se bloquean, pero el volcado sigue consumiendo E/S de disco, así que prográmelo fuera de las horas pico. Para bases de datos muy grandes, considere backups físicos en caliente con mariadb-backup o Percona XtraBackup.

¿Sigue con problemas después de seguir estos pasos? Abra un ticket de soporte y el equipo técnico de IMIDC, disponible 24/7, le ayudará. Incluya la IP del servidor, la versión del sistema operativo, los comandos que ejecutó y la salida completa del error para que podamos localizar el problema más rápido.