Estratégia de backup 3-2-1 e snapshots: o básico

Quase todo mundo que hospeda um app já perdeu dados ou conhece alguém que perdeu: um DROP TABLE no ambiente errado, um disco que morre, uma conta bloqueada, um ransomware. O que separa um susto de um desastre é existir uma cópia recente, em outro lugar, que você já sabe restaurar.

A regra 3-2-1 é o jeito mais simples de organizar isso. Num app com banco de dados, ela diz quantas cópias manter, onde guardar cada uma e qual papel os snapshots da plataforma cumprem.

O que é a regra 3-2-1?#

O documento "Data Backup Options", escrito para o US-CERT (hoje parte da CISA), resume assim:

• 3 cópias de cada arquivo importante: 1 primária e 2 backups.
• 2 tipos de mídia diferentes, para se proteger de riscos diferentes.
• 1 cópia fora do local principal.

A ideia é que cada tipo de falha derrube no máximo uma cópia. Disco que quebra afeta uma mídia. Incêndio, erro de conta ou invasão afeta tudo que está no mesmo lugar, e é por isso que uma das cópias precisa estar longe. O documento cita o livro The DAM Book, de Peter Krogh, como origem da regra.

Hoje se lê "mídia diferente" de forma mais ampla: disco local e armazenamento de objetos, ou dois provedores independentes. O princípio continua o mesmo: escolher lugares que não falham juntos.

Como aplicar a regra a um app e ao banco?#

Comece listando o que você perderia e não conseguiria recriar. Para um bot, uma API ou um site, normalmente são quatro coisas:

Uma aplicação típica fica assim:

1. Cópia 1: o banco em produção.
2. Cópia 2: o dump diário no mesmo servidor ou um snapshot da plataforma. Barato e rápido de restaurar.
3. Cópia 3: o dump criptografado num armazenamento de objetos de outro provedor. É a cópia fora do local.

A cópia 3 é a única que sobrevive se você perder a conta inteira, e por isso ela importa mais do que as outras duas.

Qual a diferença entre backup, snapshot e réplica?#

• Backup: cópia de um momento específico que você controla, guardada separada da origem e restaurável em qualquer lugar. É o que a regra 3-2-1 conta.
• Snapshot: cópia tirada pela plataforma onde o app ou o banco roda, restaurada pelo painel dela. É rápido e prático, mas fica dentro da mesma plataforma. Para a regra, conta como uma boa camada, mas uma só.
• Réplica: segunda instância que acompanha a primeira em tempo real. Ajuda na disponibilidade, mas copia os erros junto. Um DELETE sem WHERE chega à réplica em segundos, então ela não protege contra erro humano.

Snapshots e dumps se complementam. O snapshot resolve o "desfazer o erro de ontem" em minutos. O dump em outro provedor resolve o "perdi a conta".

Como montar um backup automático com cópia externa?#

O exemplo usa PostgreSQL e o restic, uma ferramenta open source que criptografa os dados, elimina duplicatas e envia tudo para destinos S3. Troque o dump por mysqldump ou mongodump se usar outro banco.

Pré-requisitos: pg_dump e restic instalados, um bucket S3 em outro provedor e as credenciais em variáveis de ambiente. Crie o repositório uma vez:

export AWS_ACCESS_KEY_ID="..."           # chaves do bucket de destino
export AWS_SECRET_ACCESS_KEY="..."
export RESTIC_PASSWORD="uma-senha-longa" # criptografa o repositório
export RESTIC_REPOSITORY="s3:https://endpoint.exemplo.com/meu-bucket"

restic init

Se você perder a RESTIC_PASSWORD, o repositório não abre mais. Guarde-a no cofre de senhas, fora do servidor. Depois, o script diário:

#!/usr/bin/env bash
set -euo pipefail
set -a; source /etc/backup.env; set +a  # carrega e exporta DB_*, PGPASSWORD, AWS_* e 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 do banco (formato custom, já compactado)

restic backup "$DIR" /srv/app/uploads  # 2. envia o dump e os arquivos de usuários para fora do servidor

restic forget --keep-daily 7 --keep-weekly 4 --prune  # 3. mantém 7 diários e 4 semanais, apaga o resto

restic check  # 4. confere a integridade do repositório

O script lê DB_HOST, DB_USER e DB_NAME do ambiente, e o pg_dump lê a senha de PGPASSWORD ou de ~/.pgpass, para ela não aparecer no histórico. O cron não herda o seu shell, por isso o topo do script carrega todas essas variáveis, junto com AWS_* e RESTIC_*, de /etc/backup.env (com permissão 600). O set -a as exporta para o pg_dump e o restic, o que um source sozinho não faz. Agende com cron para as 3h: 0 3 * * * /opt/backup.sh >> /var/log/backup.log 2>&1. Se cron é novidade, veja o que é um cron job.

O restic também chama seus pontos de restauração de "snapshots", mas eles ficam no seu bucket e não têm relação com os da plataforma. O prune bloqueia o repositório enquanto roda, então não o agende no mesmo horário de outro backup. Para escolher o destino da cópia externa, veja backups em armazenamento de objetos.

Como saber que o backup funciona?#

Um backup que nunca foi restaurado é só uma esperança. Faça um teste de verdade, pelo menos uma vez por trimestre, com as mesmas variáveis RESTIC_* e AWS_* exportadas:

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

Troque pedidos por uma tabela sua. Compare a contagem com a de produção e anote quanto tempo a restauração levou: esse é o seu tempo real de recuperação. Se a restauração falhar, o script precisa de ajuste, e é melhor descobrir isso agora do que no dia do problema.

Quais erros são comuns?#

• Backup só no mesmo servidor ou na mesma conta. Perdeu o servidor, perdeu tudo. A cópia fora do local não é opcional.
• Nunca testar a restauração. O erro aparece quando você mais precisa.
• Script que falha em silêncio. Use set -euo pipefail e alerte quando o job não rodar (um monitor externo que espera um "ping" ao final resolve).
• Esquecer os arquivos e o .env. O banco está salvo, mas o app não sobe sem os segredos.
• Senha de criptografia guardada só no servidor. Se o servidor some, a cópia fica ilegível.
• Retenção curta demais. Se um erro passa despercebido por dez dias e você guarda sete, todas as cópias já estão contaminadas.

Como fazer isso na Square Cloud#

Na Square Cloud, os snapshots ocupam a camada de recuperação rápida, a cópia 2 do esquema acima. Os bancos de dados têm snapshot automático diário em todo plano com bancos, e as aplicações, a partir do plano Pro. Cada um fica guardado por 7 dias, e o mais recente por até 30 dias. Em qualquer plano você pode tirar snapshots manuais antes de uma mudança arriscada.

Um snapshot de aplicação restaura inteiro na mesma aplicação ou em outra, inclusive numa aplicação nova, em um clique no painel. Um snapshot de banco restaura no mesmo banco, em outro do mesmo motor ou num banco novo. Você também pode baixar o snapshot de banco como .zip, e esse download é o ponto de partida da cópia externa: guarde o arquivo fora da plataforma, junto com o dump agendado do exemplo acima.

Mantenha também o código no GitHub e as variáveis de ambiente salvas num local seguro: o painel importa e exporta o .env no formato KEY=VALUE. Os detalhes de retenção e restauração estão na página de snapshots.