Backups con Restic en Ubuntu: guía para Cloud Server, Docker y PostgreSQL

Tener una aplicación funcionando en un servidor cloud no alcanza: también necesitas una forma confiable de recuperar datos cuando algo sale mal.

Un snapshot puede ayudarte a volver atrás ante ciertos incidentes, pero no reemplaza una estrategia de backups pensada para archivos, bases de datos, configuraciones y restauraciones parciales. Si borras una tabla por error, si un despliegue pisa archivos importantes o si necesitas mover datos a otro servidor, un backup bien diseñado te da mucho más margen de maniobra.

En esta guía vas a configurar backups cifrados con Restic en un Cloud Server con Ubuntu o Debian. También vas a ver cómo incluir archivos del sistema, dumps de PostgreSQL, volúmenes Docker y una automatización con systemd.

¿Qué es Restic?

Restic es una herramienta open source para hacer backups cifrados, deduplicados e incrementales. Funciona en Linux, macOS, Windows y BSD, y permite guardar repositorios en destinos locales o remotos, como SFTP, S3 compatible, REST server, entre otros.

En la práctica, Restic te ayuda a resolver tres problemas comunes:

no guardar copias completas enormes cada vez;
cifrar los datos antes de enviarlos al destino;
listar, verificar y restaurar snapshots de forma controlada.

La documentación oficial de Restic llama “repositorio” al lugar donde se guardan los backups, y “snapshot” al estado respaldado de un conjunto de archivos en un momento determinado.

¿Cuándo conviene usarlo?

Restic es una buena opción cuando necesitas backups de servidor con bajo mantenimiento y control desde terminal.

Casos de uso típicos:

respaldar /etc, configuraciones de Nginx, archivos de aplicación y uploads;
guardar dumps de PostgreSQL o MySQL/MariaDB;
proteger volúmenes Docker;
enviar backups a otro servidor por SFTP;
mantener copias cifradas fuera del servidor principal;
automatizar backups diarios con logs consultables.

No es una solución mágica para todos los escenarios. En bases de datos grandes o con requisitos estrictos de punto en el tiempo, puede convenir combinarlo con replicación, archivado continuo o herramientas específicas de la base de datos.

Snapshots no es lo mismo que backups

En un Cloud Server puedes usar snapshots o copias automáticas como parte de tu estrategia. Son muy útiles para recuperar un servidor completo o volver a un estado anterior de infraestructura.

Pero un backup aplicativo cumple otro rol:

permite restaurar un archivo puntual;
permite mover datos a otro servidor;
puede tener retención independiente;
puede guardarse en otra ubicación;
puede probarse sin restaurar todo el servidor.

Lo recomendable es combinar ambos enfoques: snapshots para recuperación rápida de infraestructura y backups cifrados para datos críticos.

Requisitos previos

Para seguir esta guía necesitas:

un Cloud Server con Ubuntu 22.04, Ubuntu 24.04, Debian 12 o similar;
acceso por SSH con un usuario con permisos sudo;
un servidor o almacenamiento remoto para guardar los backups;
acceso SFTP por SSH al destino de backup;
Restic instalado en el servidor origen;
espacio temporal suficiente para dumps de base de datos;
PostgreSQL client si vas a respaldar una base PostgreSQL;
Docker instalado si vas a respaldar volúmenes Docker.

Puertos a considerar:

22/tcp saliente hacia el servidor SFTP de backups;
5432/tcp solo si PostgreSQL está en otro servidor y debe aceptarse conexión remota;
443/tcp saliente si usas un backend S3 compatible en lugar de SFTP.

No necesitas abrir puertos entrantes nuevos en el servidor de la aplicación para que Restic haga backups hacia afuera.

Paso 1: Preparar el servidor

Actualiza el índice de paquetes e instala Restic:

sudo apt updatesudo apt install -y restic

Si vas a respaldar PostgreSQL, instala también el cliente:

sudo apt install -y postgresql-client

Crea un directorio para archivos temporales de backup:

sudo mkdir -p /var/backups/appsudo chmod 700 /var/backups/app

Este directorio va a guardar dumps temporales antes de que Restic los envíe al repositorio remoto.

Paso 2: Preparar el destino remoto por SFTP

En el servidor donde guardarás los backups, crea un usuario dedicado. Evita usar root.

sudo adduser backupusersudo mkdir -p /srv/restic/app-servidor-01sudo chown -R backupuser:backupuser /srv/restic

Desde el servidor de la aplicación, verifica que puedas conectarte:

ssh [email protected]

Para automatizar el backup, usa autenticación por llave SSH. Si todavía no tienes una llave para este flujo, crea una:

ssh-keygen -t ed25519 -f ~/.ssh/restic_backup -C "restic-backup"

Copia la clave pública al destino:

ssh-copy-id -i ~/.ssh/restic_backup.pub [email protected]

Prueba la conexión:

ssh -i ~/.ssh/restic_backup [email protected]

Paso 3: Crear el repositorio de Restic

Define una contraseña fuerte para el repositorio. Esta contraseña es crítica: si la pierdes, no podrás recuperar los datos.

Crea un archivo para guardarla:

sudo mkdir -p /etc/resticsudo nano /etc/restic/app.password

Dentro del archivo coloca una contraseña larga y única. Luego ajusta permisos:

sudo chmod 600 /etc/restic/app.passwordsudo chown root:root /etc/restic/app.password

Inicializa el repositorio remoto:

sudo RESTIC_PASSWORD_FILE=/etc/restic/app.password \restic -r sftp:[email protected]:/srv/restic/app-servidor-01 init

Si el comando termina correctamente, Restic habrá creado la estructura inicial del repositorio cifrado.

Paso 4: Crear un backup de archivos críticos

Empieza con directorios habituales de configuración y datos de aplicación. Ajusta la lista según tu servidor.

sudo RESTIC_PASSWORD_FILE=/etc/restic/app.password \restic -r sftp:[email protected]:/srv/restic/app-servidor-01 \backup /etc /var/www /opt

Puedes excluir rutas que no conviene respaldar:

sudo RESTIC_PASSWORD_FILE=/etc/restic/app.password \restic -r sftp:[email protected]:/srv/restic/app-servidor-01 \backup /etc /var/www /opt \--exclude /var/www/cache \--exclude /var/www/tmp

Lista los snapshots disponibles:

sudo RESTIC_PASSWORD_FILE=/etc/restic/app.password \restic -r sftp:[email protected]:/srv/restic/app-servidor-01 snapshots

Paso 5: Respaldar PostgreSQL con pg_dump

Para bases PostgreSQL pequeñas o medianas, pg_dump es una forma práctica de generar un dump consistente sin bloquear lecturas y escrituras normales. Para bases grandes, alta carga o recuperación punto en el tiempo, evalúa una estrategia más avanzada.

Crea un directorio para dumps:

sudo mkdir -p /var/backups/app/postgressudo chmod 700 /var/backups/app/postgres

Genera un dump en formato custom:

sudo -u postgres pg_dump -Fc nombre_base \> /var/backups/app/postgres/nombre_base.dump

Luego respáldalo con Restic:

sudo RESTIC_PASSWORD_FILE=/etc/restic/app.password \restic -r sftp:[email protected]:/srv/restic/app-servidor-01 \backup /var/backups/app/postgres

Cuando termine, puedes borrar el dump temporal si no quieres conservarlo localmente:

sudo rm -f /var/backups/app/postgres/nombre_base.dump

Advertencia: verifica periódicamente que el dump pueda restaurarse. Un backup que nunca se prueba es solo una suposición optimista.

Paso 6: Respaldar volúmenes Docker

Docker recomienda usar volúmenes para persistir datos de contenedores. Los volúmenes sobreviven al ciclo de vida del contenedor, pero eso no significa que estén respaldados automáticamente.

Primero lista tus volúmenes:

docker volume ls

Para crear una copia temporal de un volumen llamado app_data, puedes usar un contenedor auxiliar:

sudo mkdir -p /var/backups/app/dockerdocker run --rm \  -v app_data:/data:ro \  -v /var/backups/app/docker:/backup \  ubuntu tar czf /backup/app_data.tar.gz -C /data .

Luego respalda el archivo generado:

sudo RESTIC_PASSWORD_FILE=/etc/restic/app.password \restic -r sftp:[email protected]:/srv/restic/app-servidor-01 \backup /var/backups/app/docker

Si el volumen pertenece a una base de datos en ejecución, no alcanza con copiar archivos en caliente. En ese caso, prioriza herramientas consistentes como pg_dump, mysqldump, mariadb-dump o el mecanismo recomendado por el motor de base de datos.

Paso 7: Automatizar con systemd timer

Crea un script de backup:

sudo nano /usr/local/sbin/app-backup.sh

Contenido sugerido:

#!/usr/bin/env bashset -euo pipefailREPO="sftp:[email protected]:/srv/restic/app-servidor-01"PASS_FILE="/etc/restic/app.password"TMP_DIR="/var/backups/app/postgres"mkdir -p "$TMP_DIR"chmod 700 "$TMP_DIR"sudo -u postgres pg_dump -Fc nombre_base > "$TMP_DIR/nombre_base.dump"RESTIC_PASSWORD_FILE="$PASS_FILE" restic -r "$REPO" backup \  /etc \  /var/www \  /opt \  "$TMP_DIR" \  --exclude /var/www/cache \  --exclude /var/www/tmpRESTIC_PASSWORD_FILE="$PASS_FILE" restic -r "$REPO" forget \  --keep-daily 7 \  --keep-weekly 4 \  --keep-monthly 6 \  --prunerm -f "$TMP_DIR/nombre_base.dump"

Guarda, cierra y asigna permisos:

sudo chmod 700 /usr/local/sbin/app-backup.shsudo chown root:root /usr/local/sbin/app-backup.sh

Crea el servicio:

sudo nano /etc/systemd/system/app-backup.service

Contenido:

[Unit]Description=Backup de aplicacion con ResticWants=network-online.targetAfter=network-online.target[Service]Type=oneshotExecStart=/usr/local/sbin/app-backup.sh

Crea el timer:

sudo nano /etc/systemd/system/app-backup.timer

Contenido:

[Unit]Description=Ejecutar backup diario de aplicacion[Timer]OnCalendar=*-*-* 03:30:00Persistent=trueRandomizedDelaySec=15m[Install]WantedBy=timers.target

Activa el timer:

sudo systemctl daemon-reloadsudo systemctl enable --now app-backup.timer

Verifica que quedó programado:

systemctl list-timers app-backup.timer

Ejecuta una prueba manual:

sudo systemctl start app-backup.servicesudo systemctl status app-backup.service

Consulta logs:

journalctl -u app-backup.service -n 100 --no-pager

Paso 8: Probar una restauración

Primero lista snapshots:

sudo RESTIC_PASSWORD_FILE=/etc/restic/app.password \restic -r sftp:[email protected]:/srv/restic/app-servidor-01 snapshots

Restaura el último snapshot en un directorio temporal:

sudo mkdir -p /tmp/restore-testsudo RESTIC_PASSWORD_FILE=/etc/restic/app.password \restic -r sftp:[email protected]:/srv/restic/app-servidor-01 \restore latest --target /tmp/restore-test

Revisa que existan los archivos esperados:

ls -lah /tmp/restore-test

Para PostgreSQL, restaura en una base de prueba, no directamente sobre producción:

createdb nombre_base_restore_testpg_restore -d nombre_base_restore_test \/tmp/restore-test/var/backups/app/postgres/nombre_base.dump

Cuando termines la prueba, elimina el entorno temporal:

dropdb nombre_base_restore_testsudo rm -rf /tmp/restore-test

Paso 9: Reforzar seguridad

Buenas prácticas mínimas:

usa una contraseña fuerte y única para Restic;
guarda /etc/restic/app.password con permisos 600;
no subas la contraseña al repositorio de código;
usa un usuario remoto dedicado para backups;
evita que el servidor principal tenga permisos amplios sobre otros sistemas;
restringe el acceso SSH por llave;
monitorea errores del servicio con journalctl;
prueba restauraciones de forma periódica;
conserva al menos una copia fuera del servidor principal;
documenta qué se respalda y qué no.

Si una persona atacante compromete tu servidor y también puede borrar todos tus backups, tu estrategia queda débil. Siempre que puedas, usa retención, permisos limitados o almacenamiento con protección contra borrado accidental.

Problemas frecuentes

El backup funciona manualmente pero falla con systemd

Revisa variables de entorno, rutas absolutas y permisos. Los servicios de systemd no cargan el mismo entorno que tu sesión interactiva.

Usa:

journalctl -u app-backup.service -n 100 --no-pager

Restic pide contraseña aunque existe el archivo

Verifica que el script use RESTIC_PASSWORD_FILE y que el archivo sea legible por el usuario que ejecuta el servicio.

sudo ls -l /etc/restic/app.password

El backup de Docker pesa demasiado

Revisa si estás respaldando caches, archivos temporales o datos regenerables. Usa exclusiones cuando corresponda.

El dump de PostgreSQL tarda demasiado

Puede ser normal en bases grandes. En ese caso, revisa tamaño, I/O del servidor, ventanas de menor tráfico y una estrategia más específica para PostgreSQL.

No sé si mis backups sirven

Haz una restauración de prueba. La verificación real no es solo que el comando termine bien, sino que puedas recuperar archivos y levantar una base de prueba.

Conclusión

Un Cloud Server bien administrado necesita más que una aplicación funcionando: necesita una forma clara de volver a estar operativo cuando algo falla.

Con Restic puedes montar una estrategia simple y robusta de backups cifrados para archivos, configuraciones, dumps de base de datos y volúmenes Docker. La clave está en automatizar, revisar logs, definir retención y probar restauraciones.

Si estás desplegando aplicaciones en DonWeb Cloud, combina las herramientas de infraestructura del panel, como snapshots y backups del servidor, con backups aplicativos diseñados para tus datos reales. Esa combinación te da una base mucho más sólida para operar en producción.