Estrategia 3-2-1 para tu VPS con Restic y S3

Por qué los snapshots del proveedor no son suficientes: tres límites concretos

Lo que garantiza una estrategia 3-2-1 y lo que no garantiza un snapshot

• Tres copias: la original en disco local, una en snapshots del proveedor, una fuera del proveedor en S3 — ningún punto de fallo único puede borrar todo.
• Dos soportes distintos: el disco NVMe de tu VPS y el almacenamiento de objetos de otro proveedor están separados física y lógicamente.
• Cifrado antes de la transferencia: Restic cifra del lado del cliente con AES-256; el proveedor de almacenamiento S3 solo ve blobs opacos, ilegibles sin tu clave.
• Prueba de restauración: una copia de seguridad no probada es una promesa, no una garantía. Un timer systemd puede verificar automáticamente que un archivo centinela sea restaurable.
• Independencia del proveedor: tu bucket B2 o R2 no puede eliminarse desde el panel de control de tu proveedor VPS.
• Un snapshot de alojamiento no cifra antes de la transferencia: los datos son legibles por el proveedor.
• Un snapshot de alojamiento nunca verifica la coherencia a nivel de aplicación de tus bases de datos.

Las tres copias explicadas: local, proveedor, fuera del sitio

Backblaze B2 vs Cloudflare R2: elegir tu backend S3

Desplace la tabla

Implementación completa: Restic + S3 en tu VPS

1. 01

   Exportar variables de entorno a un archivo seguro

   Crea /root/.restic-env con las variables necesarias. Para Backblaze B2:

   export RESTIC_REPOSITORY="s3:https://s3.us-west-004.backblazeb2.com/tu-bucket"
   export RESTIC_PASSWORD="tu-contraseña-de-repositorio"
   export AWS_ACCESS_KEY_ID="tu-b2-key-id"
   export AWS_SECRET_ACCESS_KEY="tu-b2-application-key"

   Para Cloudflare R2, reemplaza la URL del repositorio y las claves:

   export RESTIC_REPOSITORY="s3:https://<account-id>.r2.cloudflarestorage.com/tu-bucket"
   export RESTIC_PASSWORD="tu-contraseña-de-repositorio"
   export AWS_ACCESS_KEY_ID="tu-r2-access-key-id"
   export AWS_SECRET_ACCESS_KEY="tu-r2-secret-access-key"

   Restringe inmediatamente los permisos: chmod 600 /root/.restic-env. Este archivo nunca debe ser commiteado en un repositorio Git.

2. 02

   Inicializar el repositorio Restic en S3

   Carga el entorno, luego inicializa el repositorio cifrado en tu bucket:

   source /root/.restic-env
   restic init

   Restic crea la estructura del repositorio y sella el cifrado con tu contraseña. Guarda la contraseña del repositorio fuera del VPS: en un gestor de contraseñas o una bóveda cifrada en una máquina separada. Sin ella, ninguna restauración es posible, incluso si tienes acceso completo al bucket.

3. 03

   Ejecutar una primera copia de seguridad hacia S3

   Prueba el camino completo con una copia manual:

   source /root/.restic-env
   restic backup /etc /var/www /opt/docker-data

   Para bases de datos, genera un dump primero o usa el modo stdin. Ejemplo para PostgreSQL:

   pg_dump -U postgres mibd | restic backup --stdin --stdin-filename mibd.sql

   Verifica que el snapshot fue creado: restic snapshots.

4. 04

   Definir la política de retención

   El comando forget elimina referencias a snapshots antiguos; --prune libera físicamente los bloques huérfanos en el backend:

   restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --prune

   Justificación de los valores. Siete diarios cubren una semana completa — suficiente para detectar una corrupción silenciosa que solo aparece días después del incidente. Cuatro semanales ofrecen una ventana de un mes para detectar un problema a nivel de aplicación. Tres mensuales permiten restaurar a un estado anterior al trimestre actual. --prune es esencial: sin él, forget marca snapshots para eliminación pero no libera espacio en el bucket.

5. 05

   Distinguir restic check de restic check --read-data

   Estos dos comandos no verifican lo mismo.

   restic check valida los metadatos del repositorio — estructura de packs, coherencia de índices, integridad de punteros. Rápido (segundos a minutos según el tamaño del repositorio). Ejecútalo después de cada forget --prune.

   restic check

   restic check --read-data descarga y verifica cada blob de datos comparándolos con su hash criptográfico. Lento (proporcional al volumen del repositorio) y potencialmente costoso en egress. Resérvalo para una verificación mensual o tras dudas sobre la integridad del bucket.

   restic check --read-data

6. 06

   Crear la unidad systemd de copia de seguridad (.service)

   Crea /etc/systemd/system/restic-backup.service:

   [Unit]
   Description=Restic backup a S3
   After=network-online.target
   Wants=network-online.target
   
   [Service]
   Type=oneshot
   EnvironmentFile=/root/.restic-env
   ExecStartPre=/bin/sh -c 'curl -sf --max-time 10 https://one.one.one.one > /dev/null || exit 1'
   ExecStart=/usr/bin/restic backup /etc /var/www /opt/docker-data
   ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --prune
   ExecStartPost=/usr/bin/restic check
   StandardOutput=journal
   StandardError=journal

   ExecStartPre verifica la conectividad de red antes de intentar la copia — si el VPS está aislado o el bucket es inaccesible, el servicio falla de forma limpia.

7. 07

   Crear la unidad systemd de planificación (.timer)

   Crea /etc/systemd/system/restic-backup.timer:

   [Unit]
   Description=Timer diario para restic-backup.service
   
   [Timer]
   OnCalendar=*-*-* 03:00:00
   Persistent=true
   RandomizedDelaySec=900
   
   [Install]
   WantedBy=timers.target

   Persistent=true garantiza que si el VPS está apagado a las 03:00, la copia se ejecutará en el siguiente arranque. Activa y arranca:

   systemctl daemon-reload
   systemctl enable --now restic-backup.timer

   Verifica el estado del timer: systemctl status restic-backup.timer y los logs del último run: journalctl -u restic-backup.service.

8. 08

   Crear una prueba de restauración automatizada con archivo centinela

   Crea el archivo centinela e inclúyelo en tu copia de seguridad:

   echo "sentinel-$(date +%s)" > /opt/restic-sentinel.txt

   Crea /etc/systemd/system/restic-restore-test.service:

   [Unit]
   Description=Prueba de restauración Restic
   After=network-online.target
   
   [Service]
   Type=oneshot
   EnvironmentFile=/root/.restic-env
   ExecStart=/bin/sh -c '
     rm -rf /tmp/restic-test-restore && \
     restic restore latest --target /tmp/restic-test-restore && \
     test -f /tmp/restic-test-restore/opt/restic-sentinel.txt && \
     echo "Restauración OK" || \
     (echo "FALLO restauración centinela" && exit 1)
   '
   StandardOutput=journal
   StandardError=journal

   Crea el timer semanal /etc/systemd/system/restic-restore-test.timer:

   [Unit]
   Description=Prueba semanal de restauración Restic
   
   [Timer]
   OnCalendar=Sun 04:00:00
   Persistent=true
   
   [Install]
   WantedBy=timers.target

   Activa: systemctl enable --now restic-restore-test.timer.

Resolución de problemas: cuatro errores comunes

Plan de recuperación: ¿cuánto tiempo lleva restaurar desde B2 o R2?