Backups em object storage: como e por que guardar fora do servidor

Um backup que mora no mesmo servidor dos dados que protege falha junto com ele. Disco com defeito, conta suspensa, um rm -rf no diretório errado ou um ransomware levam os dois de uma vez. Por isso o destino clássico de uma cópia de segurança é um lugar separado, e o object storage é um dos mais práticos: barato por GB, acessível por HTTP de qualquer lugar e com API padronizada.

O fluxo completo é gerar o arquivo, enviar para um bucket compatível com S3, nomear por data, apagar o que ficou velho e testar a restauração. Os exemplos usam PostgreSQL e rclone, e as ideias valem para qualquer banco ou pasta. Confira as opções de cada ferramenta na documentação oficial, citada nas fontes.

O que você precisa antes de começar?#

• Um bucket em um serviço de object storage compatível com S3, com o endpoint, a chave de acesso e a chave secreta (veja o que é armazenamento compatível com S3 e o que é um bucket).
• O rclone instalado na máquina que roda o backup. O aws-cli também serve; os comandos são parecidos.
• As ferramentas do banco: pg_dump e pg_restore para PostgreSQL (para MySQL e MongoDB, veja como fazer backup do banco de dados).
• Uma chave dedicada ao backup, separada da chave que sua aplicação usa. Se o provedor permitir, limite-a a esse bucket.

Nunca coloque chaves no script nem no repositório. Use variáveis de ambiente ou um arquivo de configuração com permissão restrita (chmod 600).

Como configurar o rclone para um bucket S3?#

O rclone aceita a configuração por variáveis de ambiente, no formato RCLONE_CONFIG_<NOME>_<OPÇÃO>. Assim você não precisa de arquivo de configuração. Para um serviço compatível com S3 que não é a Amazon, use provider=Other:

export RCLONE_CONFIG_BACKUP_TYPE=s3
export RCLONE_CONFIG_BACKUP_PROVIDER=Other
export RCLONE_CONFIG_BACKUP_ENDPOINT="https://seu-endpoint.exemplo.com"
export RCLONE_CONFIG_BACKUP_ACCESS_KEY_ID="sua-chave"
export RCLONE_CONFIG_BACKUP_SECRET_ACCESS_KEY="seu-segredo"

Os valores acima são exemplos: troque pelos do seu provedor. Teste a conexão listando o bucket:

rclone lsd backup:
rclone ls backup:meu-bucket

Se o provedor reclamar de permissão ao criar o bucket e ele já existe, adicione --s3-no-check-bucket aos comandos de envio: o rclone deixa de checar (e tentar criar) o bucket.

Como enviar o dump de um banco para o bucket?#

Crie um script que gera o dump, calcula o hash, envia os dois arquivos e apaga o temporário. O nome carrega a data em UTC, o que ordena os arquivos e evita sobrescrever o de ontem.

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

: "${DATABASE_URL:?defina DATABASE_URL}"
: "${BUCKET:?defina 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, compactado e restaurável com 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 "enviado: db/$FILE"

Pontos que importam:

• set -euo pipefail faz o script parar no primeiro erro. Sem isso, um pg_dump que falhou pela metade seria enviado como se estivesse bom.
• O -Fc do pg_dump gera um arquivo compactado que o pg_restore sabe restaurar, inclusive parcialmente.
• O rclone copyto copia um arquivo para um caminho de destino exato.
• Rode com DATABASE_URL e BUCKET definidos no ambiente, nunca escritos no script.

E para uma pasta de arquivos?#

Para uploads de usuários ou configurações, compacte a pasta e envie como um arquivo só:

tar -czf "$DIR/files-$STAMP.tar.gz" -C /caminho/da/pasta .
rclone copyto "$DIR/files-$STAMP.tar.gz" "backup:$BUCKET/files/files-$STAMP.tar.gz"

Se a pasta é grande e muda pouco, rclone copy /caminho/da/pasta backup:$BUCKET/files-atual envia só o que mudou. Evite rclone sync em backup: ele apaga no destino o que não existe mais na origem, e um erro na origem apagaria também a cópia.

Como agendar o envio?#

Use o cron do sistema. Para rodar todo dia às 3h, com as variáveis em um arquivo que só o seu usuário lê:

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

O set -a exporta todas as variáveis definidas no arquivo, para que o script e o rclone as enxerguem. O log guarda a saída para você investigar falhas. Como o cron não avisa quando algo quebra, vale um passo extra: no fim do script, chame uma URL de um monitor externo (um serviço de "heartbeat") e configure um alerta para quando a chamada deixar de chegar. O silêncio é o sintoma de um backup que parou.

Como aplicar retenção e apagar cópias antigas?#

Sem retenção, o bucket cresce para sempre e a conta também. Você tem duas opções:

1. Regra de ciclo de vida no bucket, quando o provedor suporta: apaga os objetos de uma pasta depois de N dias, sem script. Veja regras de ciclo de vida.
2. Limpeza pelo próprio script, que funciona em qualquer serviço:

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

O --min-age 30d limita o comando a objetos com mais de 30 dias. Antes de agendar, rode com --dry-run para ver o que seria apagado.

A regra de ciclo de vida é preferível, porque continua valendo mesmo se o servidor de origem estiver fora do ar. Mantenha cópias de épocas diferentes (por exemplo, diárias de 7 dias e uma mensal): se um dado corrompido entrar no backup de hoje, você ainda precisa de uma versão anterior. O raciocínio completo está em a regra 3-2-1.

Como restaurar e verificar que deu certo?#

Um backup que nunca foi restaurado é só uma esperança. Teste o caminho de volta em uma máquina ou banco de teste:

  # descobre o arquivo mais recente
rclone lsf "backup:$BUCKET/db" | grep '\.dump$' | sort | tail -n 1

  # baixa o dump e o hash, mantendo o nome original
N=app-2026-10-13T030000Z.dump
rclone copyto "backup:$BUCKET/db/$N"        "./$N"
rclone copyto "backup:$BUCKET/db/$N.sha256" "./$N.sha256"

  # confere a integridade
sha256sum -c "$N.sha256"

  # restaura em um banco novo
createdb teste_restore
pg_restore -d teste_restore --no-owner "$N"

Baixar com o mesmo nome é necessário porque o arquivo .sha256 guarda o nome original do dump. Depois compare contagens (SELECT COUNT(*) nas tabelas principais) com o banco original e anote quanto tempo a restauração levou. Esse é o tempo real que você teria numa emergência.

Quais erros são comuns?#

• Dump parcial enviado como bom: falta set -e/pipefail ou ninguém olha o código de saída.
• Chaves com poder demais: se a chave do backup também apaga o bucket inteiro e vazar, o atacante apaga as cópias. Use chave separada e, se o serviço oferecer, versionamento ou bloqueio de objetos.
• Cópia sem criptografia com dados pessoais: criptografe com gpg ou age antes do rclone, e guarde a chave fora do bucket.
• rclone sync no lugar de copy: apaga o destino junto com a origem.
• Arquivos grandes falhando: confira o limite de tamanho do provedor e o suporte a upload multipart. Veja como enviar arquivos grandes.
• Nunca testar a restauração: o problema só aparece quando você mais precisa.

Como fazer isso na Square Cloud#

O Blob Storage da Square Cloud é um object storage com API compatível com S3, então os comandos deste guia funcionam trocando o endpoint e as chaves: no rclone, defina RCLONE_CONFIG_BACKUP_ENDPOINT="https://s3-blob.squarecloud.app", RCLONE_CONFIG_BACKUP_REGION=auto e as chaves S3 geradas na aba "Acesso S3" do painel. O aws-cli e o boto3 seguem a mesma ideia. Cada conta tem três buckets fixos (public, private e legacy, este só leitura), e as pastas são prefixos de chave: mande os dumps para o private, numa pasta como db/.

Não há taxa de entrada nem de saída (egress), e todo plano já inclui uma cota de 5 GB a 250 GB. Para a retenção, a regra de pasta "apagar após N dias" substitui o rclone delete --min-age: a contagem parte da última escrita de cada arquivo, e prazos abaixo de 7 dias só existem no Enterprise. Arquivos de até 10 GB são aceitos, o multipart só é obrigatório acima de 100 MB, e a durabilidade é de 99,999999999% com replicação tripla.

Os snapshots da Square Cloud (manuais em todo plano; diários e automáticos para bancos em todo plano com bancos e para aplicações a partir do Pro) complementam esse fluxo. Eles cobrem a recuperação rápida, inclusive restaurar o snapshot de uma aplicação numa aplicação nova em um clique. Já os dumps que você envia ao Blob com rclone são uma cópia que você controla e leva para onde quiser.

Veja cotas e detalhes na página do Blob Storage.