Estrategias de backup para un VPS con rsync y rclone
Dedicated & VPS
23

El problema del backup en VPS

En un hosting con cPanel el backup suele estar resuelto por el panel. En un VPS puro, tú eres el responsable. Los datos críticos están repartidos en varios lugares: carpetas web, bases de datos, configuraciones de servicios, correos. Un backup serio debe cubrirlos todos y además llevarlos fuera del servidor — un respaldo en el mismo disco no te sirve si el disco falla.

Qué respaldar

1. Datos de aplicaciones web

Generalmente están en /var/www/, /home/usuario/public_html/ u otras rutas según tu distribución y panel. Incluyen código, uploads, configuraciones locales.

2. Bases de datos

MySQL/MariaDB, PostgreSQL, MongoDB. Requieren un dump correctamente hecho, no solo copiar los archivos del motor — eso corrompe.

3. Configuraciones del sistema

  • /etc/nginx/ o /etc/apache2/ — configuración del servidor web.
  • /etc/php/ — configuración de PHP.
  • /etc/mysql/ o /etc/my.cnf — configuración de la BD.
  • /etc/ssh/ — configuración de SSH y llaves host.
  • /etc/letsencrypt/ — certificados si usas Certbot.
  • /etc/fstab, /etc/hosts, /etc/crontab — archivos puntuales.

4. Correo (si tu servidor lo gestiona)

En servidores con Postfix/Dovecot, los buzones suelen estar en /var/mail/ o /home/usuario/Maildir/.

5. Listas de paquetes instalados

No son datos, pero facilitan reconstruir el servidor si hay que migrar. Guárdalas:

dpkg --get-selections > paquetes-instalados.txt   # Debian/Ubuntu
dnf list installed > paquetes-instalados.txt      # RHEL/Rocky

Método 1 — rsync a otro servidor

rsync es la herramienta estándar para sincronización de archivos. Copia solo los cambios entre backups (delta), lo que es muy eficiente para grandes volúmenes con pocos cambios.

Copia básica a servidor remoto

rsync -av /var/www/ usuario@servidor-backup:/backups/oxira/www/

Con compresión y progreso

rsync -avz --progress /var/www/ usuario@servidor-backup:/backups/oxira/www/

Con eliminación de archivos borrados (sync real)

rsync -avz --delete /var/www/ usuario@servidor-backup:/backups/oxira/www/

Cuidado con --delete: si borras algo por accidente, el próximo rsync lo borra del destino también. Úsalo solo si el destino debe ser un "espejo" exacto.

Usando llave SSH sin contraseña

Para automatización, crea una llave SSH sin passphrase en el servidor origen y agrégala al authorized_keys del destino. Así rsync corre desatendido en cron.

Método 2 — rclone a la nube

rclone es "rsync para la nube" — sincroniza con Google Drive, Dropbox, Mega, S3, Backblaze B2, OneDrive y decenas de proveedores más, con cifrado opcional en ambos extremos.

Instalación

curl https://rclone.org/install.sh | sudo bash

Configurar un remote

rclone config

Te guía interactivamente para autorizar el proveedor. Para Google Drive te pide abrir una URL y pegar un código. Para S3 pide access key y secret.

Copiar una carpeta

rclone copy /backups/diario gdrive:/oxira-backups/diario

Sincronizar (con borrado)

rclone sync /backups/diario gdrive:/oxira-backups/diario

Con cifrado

rclone tiene un tipo de remote especial "crypt" que cifra localmente antes de subir. Ni Google ni Dropbox pueden leer tus archivos cifrados:

rclone config
# new remote → crypt → nombre → remote base → contraseña

Luego usas el remote encriptado normalmente: rclone copy /backups mi-crypt:/. rclone cifra el nombre de archivos y el contenido al subir, y descifra al descargar.

Script completo de backup

Un ejemplo que respalda bases de datos, código web y configuraciones, comprimido y con rotación:

#!/bin/bash
set -e

BACKUP_DIR=/home/backup/oxira
FECHA=$(date +%Y%m%d-%H%M)
DIA_SEMANA=$(date +%u)
RETENCION_DIAS=14

mkdir -p "$BACKUP_DIR/db" "$BACKUP_DIR/www" "$BACKUP_DIR/etc"

# 1. Bases de datos
echo "[1/4] Respaldando bases de datos..."
for DB in $(mysql -e "SHOW DATABASES;" | grep -Ev "^(Database|information_schema|performance_schema|mysql|sys)$"); do
    mysqldump --single-transaction --quick --routines --triggers $DB | \
        gzip > "$BACKUP_DIR/db/${DB}-${FECHA}.sql.gz"
done

# 2. Archivos web
echo "[2/4] Respaldando archivos web..."
tar -czf "$BACKUP_DIR/www/www-${FECHA}.tar.gz" -C /var/www .

# 3. Configuraciones
echo "[3/4] Respaldando configuraciones..."
tar -czf "$BACKUP_DIR/etc/etc-${FECHA}.tar.gz" \
    /etc/nginx /etc/php /etc/mysql /etc/letsencrypt 2>/dev/null || true

# 4. Rotación: eliminar backups viejos
echo "[4/4] Rotando backups antiguos..."
find "$BACKUP_DIR" -type f -name "*.gz" -mtime +$RETENCION_DIAS -delete

# 5. Enviar a la nube con rclone
echo "[5/5] Sincronizando a la nube..."
rclone sync "$BACKUP_DIR" gdrive:/oxira-backups --transfers 4

echo "Backup terminado: $FECHA"

Guárdalo en /usr/local/bin/backup-oxira.sh, dale permisos de ejecución (chmod +x) y agrégalo a cron:

0 3 * * * /usr/local/bin/backup-oxira.sh >> /var/log/backup.log 2>&1

Corre cada día a las 3 AM y deja un log de lo que hizo.

Buenas prácticas

Prueba de restauración regular

Una vez al mes, restaura uno de los backups en una máquina de pruebas (puede ser un contenedor Docker o un VPS temporal). Confirma que:

  • El archivo .sql.gz descomprime correctamente.
  • La base de datos importa sin errores.
  • Las aplicaciones arrancan con los datos restaurados.

Si algo falla, arréglalo ahora — no cuando el servidor real esté caído.

Ciclos múltiples

Mantén varios niveles de retención, no solo "el último backup":

  • Diario — últimos 7 días.
  • Semanal — últimas 4 semanas.
  • Mensual — últimos 6-12 meses.

Permite recuperar de errores que descubres tarde (un archivo borrado hace 20 días que nadie notó).

Cifrado para datos sensibles

Si tus backups incluyen datos personales de usuarios, correos o información bancaria, cífralos antes de subirlos. rclone crypt, GPG o simplemente openssl enc sirven.

Monitoreo

Un backup que falla silenciosamente durante meses es el peor escenario. Al menos configura que el script envíe correo si fracasa, o usa un servicio como healthchecks.io que te alerta si el script no corre.

Qué NO hacer

  • No guardar backups solo en el mismo servidor. Si muere el disco, mueren los backups.
  • No confiar en un solo proveedor de nube. Idealmente mantén copias en dos servicios distintos.
  • No hacer backups sin rotación. Llenas el disco en pocas semanas.
  • No olvidar probar la restauración. Es lo más importante del proceso.