Estrategias de backup: snapshots vs backups y la regla 3-2-1

Casi todos los que alojan una app han perdido datos o conocen a alguien que los perdió: un DROP TABLE en el entorno equivocado, un disco que se muere, una cuenta bloqueada, un ransomware. Lo que separa un susto de un desastre es tener una copia reciente, en otro lugar, que ya sabes restaurar.

La regla 3-2-1 es la forma más simple de organizarlo. En una app con base de datos, te dice cuántas copias mantener, dónde guardar cada una y qué papel cumplen los snapshots de la plataforma.

¿Qué es la regla 3-2-1 de backup?#

El documento "Data Backup Options", escrito para US-CERT (hoy parte de CISA), la resume así:

• 3 copias de cada archivo importante: 1 principal y 2 backups.
• 2 tipos de medio distintos, para protegerte de riesgos distintos.
• 1 copia guardada fuera del sitio.

La idea es que cada tipo de fallo tumbe como mucho una copia. Un disco roto afecta a un medio. Un incendio, un error de cuenta o una intrusión afectan a todo lo que está en el mismo lugar, y por eso una de las copias tiene que estar lejos. El documento cita el libro The DAM Book, de Peter Krogh, como origen de la regla.

Hoy "medio distinto" se interpreta de forma más amplia: un disco local más almacenamiento de objetos, o dos proveedores independientes. El principio sigue siendo el mismo: elegir lugares que no fallen a la vez.

¿Cómo se aplica a una app y su base de datos?#

Empieza por listar lo que perderías y no puedes recrear. En un bot, una API o un sitio web suelen ser cuatro cosas:

Una configuración típica queda así:

1. Copia 1: la base de datos en producción.
2. Copia 2: el dump diario en el mismo servidor, o un snapshot de la plataforma. Barata y rápida de restaurar.
3. Copia 3: el dump cifrado en almacenamiento de objetos de otro proveedor. Es la copia fuera del sitio.

La copia 3 es la única que sobrevive si pierdes la cuenta entera, y por eso importa más que las otras dos.

¿Qué diferencia hay entre backup, snapshot y réplica?#

• Backup: una copia de un momento concreto que tú controlas, guardada aparte del origen y restaurable en cualquier sitio. Es lo que cuenta la regla 3-2-1.
• Snapshot: una copia que toma la plataforma donde corre tu app o tu base de datos, restaurada desde su panel. Es rápida y cómoda, pero queda dentro de la misma plataforma. Para la regla cuenta como una buena capa, pero solo una.
• Réplica: una segunda instancia que sigue a la primera en tiempo real. Ayuda con la disponibilidad, pero también copia los errores. Un DELETE sin WHERE llega a la réplica en segundos, así que no te protege del error humano.

Snapshots y dumps se complementan. El snapshot resuelve el "deshacer el error de ayer" en minutos. El dump en otro proveedor resuelve el "perdí la cuenta".

¿Cómo montar un backup automático con copia externa?#

El ejemplo usa PostgreSQL y restic, una herramienta open source que cifra los datos, elimina duplicados y los sube a destinos S3. Cambia el dump por mysqldump o mongodump si usas otra base de datos.

Requisitos: pg_dump y restic instalados, un bucket S3 en otro proveedor y las credenciales en variables de entorno. Crea el repositorio una vez:

export AWS_ACCESS_KEY_ID="..."           # claves del bucket de destino
export AWS_SECRET_ACCESS_KEY="..."
export RESTIC_PASSWORD="una-frase-larga" # cifra el repositorio
export RESTIC_REPOSITORY="s3:https://endpoint.example.com/my-bucket"

restic init

Si pierdes la RESTIC_PASSWORD, el repositorio ya no se puede abrir. Guárdala en un gestor de contraseñas, fuera del servidor. Después, el script diario:

#!/usr/bin/env bash
set -euo pipefail
set -a; source /etc/backup.env; set +a  # carga y exporta DB_*, PGPASSWORD, AWS_* y RESTIC_*

DIR=/var/backups/app
mkdir -p "$DIR"

pg_dump -h "$DB_HOST" -U "$DB_USER" -d "$DB_NAME" -Fc -f "$DIR/db.dump"  # 1. dump de la base (formato custom, ya comprimido)

restic backup "$DIR" /srv/app/uploads  # 2. envía el dump y los archivos de usuarios fuera del servidor

restic forget --keep-daily 7 --keep-weekly 4 --prune  # 3. conserva 7 diarios y 4 semanales, borra el resto

restic check  # 4. verifica la integridad del repositorio

El script lee DB_HOST, DB_USER y DB_NAME del entorno, y pg_dump lee la contraseña de PGPASSWORD o de ~/.pgpass, para que nunca aparezca en el historial de la shell. Cron no hereda tu shell, así que el inicio del script carga todas esas variables, junto con AWS_* y RESTIC_*, desde /etc/backup.env (con permisos 600). set -a las exporta a pg_dump y restic, algo que un source solo no hace. Prográmalo con cron a las 3 a. m.: 0 3 * * * /opt/backup.sh >> /var/log/backup.log 2>&1. Si cron es nuevo para ti, mira qué es un cron job.

restic también llama "snapshots" a sus puntos de restauración, pero viven en tu bucket y no tienen nada que ver con los de una plataforma. prune bloquea el repositorio mientras corre, así que no lo programes a la misma hora que otro backup. Para elegir el destino de la copia externa, mira backups en almacenamiento de objetos.

¿Cómo sabes que el backup funciona?#

Un backup que nunca se restauró es solo una esperanza. Pruébalo de verdad, al menos una vez por trimestre, con las mismas variables RESTIC_* y AWS_* exportadas:

restic restore latest --target /tmp/restore-test
createdb restore_test
pg_restore -d restore_test --no-owner /tmp/restore-test/var/backups/app/db.dump
psql -d restore_test -c "SELECT count(*) FROM orders;"

Cambia orders por una de tus tablas. Compara el conteo con el de producción y anota cuánto tardó la restauración: ese es tu tiempo real de recuperación. Si la restauración falla, el script necesita ajustes, y es mejor descubrirlo ahora que el día del problema.

¿Qué errores son comunes?#

• Backup solo en el mismo servidor o la misma cuenta. Pierdes el servidor, pierdes todo. La copia fuera del sitio no es opcional.
• No probar nunca una restauración. El error aparece justo cuando más lo necesitas.
• Un script que falla en silencio. Usa set -euo pipefail y avisa cuando el job no corre (un monitor externo que espera un "ping" al final lo resuelve).
• Olvidar los archivos subidos y el .env. La base de datos está a salvo, pero la app no arranca sin sus secretos.
• Guardar la contraseña de cifrado solo en el servidor. Si el servidor desaparece, la copia queda ilegible.
• Retención demasiado corta. Si un error pasa desapercibido diez días y guardas siete, todas las copias ya están contaminadas.

Cómo hacerlo en Square Cloud#

En Square Cloud, los snapshots ocupan la capa de recuperación rápida, la copia 2 del esquema anterior. Las bases de datos tienen un snapshot automático diario en todo plan que las incluye, y las aplicaciones, desde el plan Pro. Cada uno se guarda 7 días, y el más reciente hasta 30 días. En cualquier plan puedes tomar snapshots manuales antes de un cambio arriesgado.

Un snapshot de aplicación se restaura completo en la misma aplicación o en otra, incluso en una aplicación nueva, con un clic en el panel. Un snapshot de base de datos se restaura en la misma base, en otra del mismo motor o en una base nueva. También puedes descargar el snapshot de base de datos como .zip, y esa descarga es el punto de partida de tu copia externa: guarda el archivo fuera de la plataforma, junto al dump programado del ejemplo anterior.

Mantén también el código en GitHub y las variables de entorno guardadas en un lugar seguro: el panel importa y exporta el .env en formato KEY=VALUE. Los detalles de retención y restauración están en la página de snapshots.