Como fazer backup do banco de dados (MySQL, PostgreSQL, MongoDB)

Um backup de banco de dados é uma cópia dos dados que você consegue restaurar quando algo dá errado: um DELETE sem WHERE, um disco que falha, uma migração que corrompe tabelas. A forma mais portátil é gerar um dump: um arquivo com o conteúdo do banco, que você restaura em qualquer servidor compatível.

Os comandos abaixo, para MySQL, PostgreSQL e MongoDB, seguem a documentação oficial de cada ferramenta. Um backup que nunca foi restaurado é só uma esperança, por isso cada seção termina com a restauração.

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

• As ferramentas de linha de comando instaladas na máquina que roda o backup: mysqldump (vem com o cliente MySQL), pg_dump e pg_restore (cliente PostgreSQL) e mongodump e mongorestore (MongoDB Database Tools).
• Host, porta, usuário, senha e nome do banco. Em bancos hospedados, o painel mostra a string de conexão.
• Um usuário com permissão de leitura em tudo que será copiado.
• Espaço em disco para o arquivo. Confira o tamanho do primeiro dump antes de agendar.
• Um banco vazio para testar a restauração. Nunca teste restaurando por cima da produção.

Evite colocar a senha direto na linha de comando: ela aparece no histórico do shell e na lista de processos. Use variáveis de ambiente ou os arquivos de configuração das ferramentas (por exemplo ~/.my.cnf e ~/.pgpass).

Como fazer backup de um banco MySQL?#

Use o mysqldump. Para tabelas InnoDB, a opção --single-transaction abre uma transação e lê uma visão consistente sem bloquear as escritas.

mysqldump -h "$DB_HOST" -u "$DB_USER" -p \
  --single-transaction --routines --triggers --events \
  --databases meubanco > meubanco.sql

--routines e --events incluem procedures, funções e eventos agendados, que ficam de fora por padrão. Os triggers já entram no dump por padrão, e a opção só deixa isso explícito. --databases grava também o CREATE DATABASE no arquivo. No Windows, use --result-file=meubanco.sql no lugar do redirecionamento >, porque o PowerShell pode gravar em UTF-16 e o arquivo não carrega depois.

Para restaurar:

mysql -h "$DB_HOST" -u "$DB_USER" -p < meubanco.sql

Como o dump foi feito com --databases, ele já traz o CREATE DATABASE e o USE, então você não precisa informar o nome do banco.

Como fazer backup de um banco PostgreSQL?#

Use o pg_dump no formato custom (-Fc). Ele é compactado por padrão e permite restaurar só parte do banco com o pg_restore.

pg_dump -h "$DB_HOST" -U "$DB_USER" -d meubanco -Fc -f meubanco.dump

Restaure em um banco novo:

createdb -h "$DB_HOST" -U "$DB_USER" teste_restore
pg_restore -h "$DB_HOST" -U "$DB_USER" -d teste_restore --no-owner meubanco.dump

--no-owner evita erros de ALTER OWNER quando o usuário da restauração é diferente do original. Para restaurar por cima de objetos existentes, use --clean --if-exists. Com -j 4, o pg_restore carrega dados e índices em paralelo (só nos formatos custom e directory).

Se preferir um arquivo SQL puro (pg_dump -f meubanco.sql, sem -Fc), restaure com psql -X -h "$DB_HOST" -U "$DB_USER" -d teste_restore -f meubanco.sql.

Como fazer backup de um banco MongoDB?#

Use o mongodump com um arquivo único compactado:

mongodump --uri="$MONGO_URI" --gzip --archive=meubanco.archive.gz

Se a MONGO_URI tiver a senha, ela aparece na lista de processos (ps). A documentação recomenda omitir a senha da URI para o mongodump pedi-la, ou usar --config com um arquivo YAML. Sem --db, ele copia todos os bancos da instância. Para um só, adicione --db=meubanco. Para restaurar:

mongorestore --uri="$MONGO_URI" --gzip --archive=meubanco.archive.gz

Acrescente --drop para apagar as coleções existentes antes de restaurar, mas só em ambiente de teste ou quando tiver certeza do que está fazendo. Para restaurar só uma coleção, use --nsInclude="meubanco.pedidos".

Em um replica set, --oplog grava também as escritas que acontecem durante o dump, para o resultado representar um único instante (restaure com --oplogReplay). Essa opção não combina com --db nem com --collection, e não funciona em cluster com sharding.

E o Redis?#

O Redis grava snapshots do conjunto de dados no arquivo dump.rdb, por regras como save 60 1000 ou pelo comando BGSAVE. Segundo a documentação, o arquivo nunca é modificado depois de pronto, então copiá-lo com o servidor ligado é seguro. Fazer backup do Redis é copiar esse arquivo. Para restaurar, coloque-o no diretório de dados antes de iniciar o servidor (com o AOF ativo, o Redis carrega o AOF no lugar dele). Os detalhes de persistência estão em O que é Redis.

Como automatizar e guardar fora do servidor?#

Backup manual cai no esquecimento. Agende com cron e ponha a data no nome do arquivo:

#!/usr/bin/env bash
set -euo pipefail
ARQ="meubanco-$(date +%F-%H%M).dump"
pg_dump -h "$DB_HOST" -U "$DB_USER" -d meubanco -Fc -f "$ARQ"
rclone copy "$ARQ" destino:backups/  # exemplo: envia para fora do servidor
find . -name 'meubanco-*.dump' -mtime +7 -delete

Para rodar todo dia às 3h, adicione 0 3 * * * /caminho/backup.sh ao crontab. O cron não carrega as variáveis do seu shell, então defina DB_HOST e DB_USER no próprio script e deixe a senha no ~/.pgpass. O find apaga dumps com mais de 7 dias para o disco não encher.

A cópia fora do servidor segue a lógica da regra 3-2-1. Um armazenamento de objetos compatível com S3 é um bom destino, como explica backups em armazenamento de objetos.

Como saber que o backup funciona?#

1. Confira que o arquivo não está vazio: ls -lh e compare com o dump anterior.
2. Restaure em um banco de teste, como nos exemplos acima.
3. Compare contagens: SELECT COUNT(*) nas tabelas principais, ou db.pedidos.countDocuments() no MongoDB, nos dois bancos.
4. Anote quanto tempo a restauração levou. Esse é o tempo de recuperação que você terá numa emergência.

Repita o teste com regularidade, não só uma vez.

Quais erros são comuns?#

• Dump parcial sem aviso: o comando falhou no meio e o arquivo ficou pela metade. Use set -e no script e confira o código de saída.
• Versão da ferramenta diferente da do servidor: use pg_dump, mysqldump e mongodump em versão compatível com a do servidor, e restaure com a mesma ferramenta ou uma mais nova. Versão antiga de cliente é fonte comum de erro.
• Esquecer procedures e eventos no MySQL: sem --routines e --events eles não vão para o arquivo.
• Senha no histórico do shell: use arquivos de credenciais.
• Backup só no mesmo disco: perder o servidor significa perder tudo.
• Nunca testar a restauração: o erro aparece só quando você mais precisa.

Como fazer isso na Square Cloud#

Na hospedagem de bancos da Square Cloud (MongoDB, PostgreSQL, MySQL e Redis, a partir do plano Standard), o ponto de restauração recente já vem no plano. Todo plano com bancos faz um snapshot automático diário de cada banco: cada um fica guardado por 7 dias, e o mais recente por até 30 dias. Antes de uma migração ou de um DELETE arriscado, você tira um snapshot manual pelo painel, até 8 por GB de RAM do plano por dia.

A restauração segue a regra de testar fora da produção: o snapshot volta inteiro no mesmo banco, em outro banco do mesmo motor ou num banco novo, então você confere as contagens numa cópia antes de mexer no banco principal. Para guardar uma cópia sua, baixe o snapshot como .zip, o que vale para todos os motores, inclusive o Redis.

Os dumps deste guia continuam sendo a cópia independente e portátil. O banco aceita conexões de fora com host, porta, senha e os certificados baixados no painel, então o script de cron acima pode rodar na sua máquina ou num CI. O TLS é obrigatório: passe a CA para a ferramenta (--ssl-ca no mysqldump, sslrootcert na string do pg_dump, --tlsCAFile no mongodump) e, no PostgreSQL e no MongoDB, também o certificado do cliente (sslcert e sslkey, ou --tlsCertificateKeyFile). Como cada banco é de nó único, sem replica set, o --oplog do mongodump não se aplica.

Veja retenção, limites e restauração em Snapshots.