Backups en object storage: cómo y por qué guardarlos fuera del servidor

Un backup que vive en el mismo servidor que los datos que protege falla junto con ese servidor. Un disco dañado, una cuenta suspendida, un rm -rf en el directorio equivocado o un ransomware se llevan los dos a la vez. Por eso el destino clásico de una copia de seguridad es un lugar separado, y el object storage es uno de los más prácticos: barato por GB, accesible por HTTP desde cualquier lugar y con una API estándar.

El flujo completo consiste en generar el archivo, subirlo a un bucket compatible con S3, nombrarlo por fecha, borrar lo que quedó viejo y probar la restauración. Los ejemplos usan PostgreSQL y rclone, y las ideas sirven para cualquier base de datos o carpeta. Revisa las opciones de cada herramienta en su documentación oficial, citada en las fuentes.

¿Qué necesitas antes de empezar?#

• Un bucket en un servicio de object storage compatible con S3, con el endpoint, la clave de acceso y la clave secreta (mira qué es el almacenamiento compatible con S3 y qué es un bucket).
• rclone instalado en la máquina que ejecuta el backup. aws-cli también sirve, con comandos parecidos.
• Las herramientas de la base de datos: pg_dump y pg_restore para PostgreSQL (para MySQL y MongoDB, mira cómo hacer un backup de la base de datos).
• Una clave dedicada al backup, separada de la clave que usa tu aplicación. Si el proveedor lo permite, limítala a ese bucket.

Nunca pongas claves en el script ni en el repositorio. Usa variables de entorno o un archivo de configuración con permisos restringidos (chmod 600).

¿Cómo configurar rclone para un bucket S3?#

rclone acepta la configuración por variables de entorno con el formato RCLONE_CONFIG_<NOMBRE>_<OPCIÓN>, así que no necesitas archivo de configuración. Para un servicio compatible con S3 que no es Amazon, usa provider=Other:

export RCLONE_CONFIG_BACKUP_TYPE=s3
export RCLONE_CONFIG_BACKUP_PROVIDER=Other
export RCLONE_CONFIG_BACKUP_ENDPOINT="https://tu-endpoint.ejemplo.com"
export RCLONE_CONFIG_BACKUP_ACCESS_KEY_ID="tu-clave"
export RCLONE_CONFIG_BACKUP_SECRET_ACCESS_KEY="tu-secreto"

Los valores de arriba son ejemplos: cámbialos por los de tu proveedor. Prueba la conexión listando el bucket:

rclone lsd backup:
rclone ls backup:mi-bucket

Si el proveedor se queja de permisos al crear el bucket y este ya existe, agrega --s3-no-check-bucket a los comandos de subida: rclone deja de comprobar (y de intentar crear) el bucket.

¿Cómo subir el dump de una base de datos al bucket?#

Escribe un script que genere el dump, calcule el hash, suba los dos archivos y borre el directorio temporal. El nombre lleva la fecha en UTC, lo que ordena los archivos y evita sobrescribir el de ayer.

#!/usr/bin/env bash
set -euo pipefail

: "${DATABASE_URL:?define DATABASE_URL}"
: "${BUCKET:?define BUCKET}"

STAMP="$(date -u +%Y-%m-%dT%H%M%SZ)"
DIR="$(mktemp -d)"
FILE="app-$STAMP.dump"
trap 'rm -rf "$DIR"' EXIT

  # -Fc: formato custom, comprimido y restaurable con pg_restore
pg_dump "$DATABASE_URL" -Fc -f "$DIR/$FILE"
(cd "$DIR" && sha256sum "$FILE" > "$FILE.sha256")

rclone copyto "$DIR/$FILE"        "backup:$BUCKET/db/$FILE"
rclone copyto "$DIR/$FILE.sha256" "backup:$BUCKET/db/$FILE.sha256"

echo "subido: db/$FILE"

Lo que importa:

• set -euo pipefail detiene el script en el primer error. Sin eso, un pg_dump que falló a la mitad se subiría como si estuviera bien.
• El -Fc de pg_dump genera un archivo comprimido que pg_restore sabe restaurar, incluso de forma parcial.
• rclone copyto copia un archivo a una ruta de destino exacta.
• Ejecútalo con DATABASE_URL y BUCKET definidos en el entorno, nunca escritos en el script.

¿Y para una carpeta de archivos?#

Para archivos subidos por usuarios o configuraciones, comprime la carpeta y súbela como un solo archivo:

tar -czf "$DIR/files-$STAMP.tar.gz" -C /ruta/de/la/carpeta .
rclone copyto "$DIR/files-$STAMP.tar.gz" "backup:$BUCKET/files/files-$STAMP.tar.gz"

Si la carpeta es grande y cambia poco, rclone copy /ruta/de/la/carpeta backup:$BUCKET/files-actual sube solo lo que cambió. Evita rclone sync para backups: borra en el destino lo que ya no existe en el origen, y un error en el origen borraría también la copia.

¿Cómo programar la subida?#

Usa el cron del sistema. Para ejecutarlo todos los días a las 3 de la mañana, con las variables en un archivo que solo tu usuario puede leer:

0 3 * * * set -a && . /etc/backup.env && /opt/scripts/backup-db.sh >> /var/log/backup-db.log 2>&1

set -a exporta todas las variables definidas en el archivo, para que el script y rclone las vean. El log guarda la salida para que investigues los fallos. Como cron no avisa cuando algo se rompe, vale la pena un paso extra: al final del script, llama a una URL de un monitor externo (un servicio de "heartbeat") y configura una alerta para cuando esa llamada deje de llegar. El silencio es el síntoma de un backup que se detuvo.

¿Cómo aplicar retención y borrar copias viejas?#

Sin retención, el bucket crece para siempre y la factura también. Tienes dos opciones:

1. Una regla de ciclo de vida en el bucket, cuando el proveedor la admite: borra los objetos de una carpeta después de N días, sin script. Mira reglas de ciclo de vida.
2. Limpieza desde el propio script, que funciona en cualquier servicio:

rclone delete "backup:$BUCKET/db" --min-age 30d

--min-age 30d limita el comando a objetos con más de 30 días. Antes de programarlo, ejecútalo con --dry-run para ver qué se borraría.

La regla de ciclo de vida es preferible, porque sigue funcionando aunque el servidor de origen esté caído. Guarda copias de distintas épocas (por ejemplo, diarias de 7 días y una mensual): si un dato corrupto entra en el backup de hoy, todavía necesitas una versión anterior. El razonamiento completo está en la regla 3-2-1.

¿Cómo restaurar y comprobar que funcionó?#

Un backup que nunca se restauró es solo una esperanza. Prueba el camino de vuelta en una máquina o base de datos de prueba:

  # encuentra el archivo más reciente
rclone lsf "backup:$BUCKET/db" | grep '\.dump$' | sort | tail -n 1

  # descarga el dump y su hash, con el nombre original
N=app-2026-10-13T030000Z.dump
rclone copyto "backup:$BUCKET/db/$N"        "./$N"
rclone copyto "backup:$BUCKET/db/$N.sha256" "./$N.sha256"

  # comprueba la integridad
sha256sum -c "$N.sha256"

  # restaura en una base de datos nueva
createdb prueba_restore
pg_restore -d prueba_restore --no-owner "$N"

Descargar con el mismo nombre es necesario porque el archivo .sha256 guarda el nombre original del dump. Después compara conteos (SELECT COUNT(*) en las tablas principales) con la base de datos original y anota cuánto tardó la restauración. Ese es el tiempo real que tendrías en una emergencia.

¿Cuáles son los errores comunes?#

• Un dump parcial subido como bueno: falta set -e/pipefail o nadie revisa el código de salida.
• Claves con demasiado poder: si la clave del backup también puede borrar el bucket entero y se filtra, el atacante borra las copias. Usa una clave separada y, si el servicio lo ofrece, versionado o bloqueo de objetos.
• Copias sin cifrar con datos personales: cifra con gpg o age antes de rclone y guarda la clave fuera del bucket.
• rclone sync en lugar de copy: borra el destino junto con el origen.
• Archivos grandes que fallan: revisa el límite de tamaño del proveedor y el soporte de subida multipart. Mira cómo subir archivos grandes.
• No probar nunca la restauración: el problema solo aparece cuando más lo necesitas.

Cómo hacerlo en Square Cloud#

El Blob Storage de Square Cloud es un object storage con API compatible con S3, así que los comandos de esta guía funcionan cambiando el endpoint y las claves: en rclone, define RCLONE_CONFIG_BACKUP_ENDPOINT="https://s3-blob.squarecloud.app", RCLONE_CONFIG_BACKUP_REGION=auto y las claves S3 creadas en la pestaña "Acceso S3" del panel. aws-cli y boto3 siguen la misma idea. Cada cuenta tiene tres buckets fijos (public, private y legacy, este de solo lectura), y las carpetas son prefijos de clave: envía tus dumps a private, en una carpeta como db/.

No hay tarifa de entrada ni de salida (egress), y todos los planes incluyen una cuota de 5 GB a 250 GB. Para la retención, la regla de carpeta "borrar después de N días" reemplaza a rclone delete --min-age: el conteo parte de la última escritura de cada archivo, y los plazos de menos de 7 días solo existen en Enterprise. Se aceptan archivos de hasta 10 GB, el multipart solo es obligatorio por encima de 100 MB y la durabilidad es de 99,999999999% con replicación triple.

Los snapshots de Square Cloud (manuales en todos los planes; diarios automáticos para bases de datos en todo plan que las incluye y para aplicaciones desde el plan Pro) complementan este flujo. Cubren la recuperación rápida, incluso restaurar el snapshot de una aplicación en una aplicación nueva con un clic. Los dumps que subes al Blob con rclone, en cambio, son una copia que controlas y puedes llevar a donde quieras.

Mira las cuotas y los detalles en la página de Blob Storage.