Backup de banco de dados: mysqldump, automação e restauração

De tudo que vive no seu servidor, o banco de dados é o mais crítico: é onde estão os pedidos, os usuários, o conteúdo. E é também o mais volátil — uma migração malfeita, um DELETE sem WHERE ou uma invasão podem apagá-lo num instante. A diferença entre um susto e uma catástrofe é ter um backup recente e testado. Veja como montar isso direito.

O que faz um bom backup de banco

• Automático — não depende de você lembrar.
• Frequente — compatível com quanto dado você não pode perder.
• Offsite — uma cópia fora do servidor (a regra 3-2-1).
• Testado — você já restaurou pelo menos uma vez e sabe que funciona.

Backup com mysqldump (MySQL/MariaDB)

O mysqldump gera um arquivo .sql com os comandos para recriar todo o banco. É a forma mais portátil de backup.

mysqldump -u usuario -p nome_do_banco > backup.sql

Para todos os bancos de uma vez:

mysqldump -u root -p --all-databases > backup_completo.sql

Comprima para economizar espaço (bancos comprimem muito bem):

mysqldump -u usuario -p nome_do_banco | gzip > backup.sql.gz

💡 Para bancos grandes ou InnoDB, adicione --single-transaction — ele faz um dump consistente sem travar as tabelas durante o backup.

E no PostgreSQL?

O equivalente é o pg_dump:

pg_dump -U usuario nome_do_banco | gzip > backup.sql.gz

Automatizando com cron

Um backup manual você esquece; um agendado roda sozinho. Crie um script /root/backup-db.sh:

#!/bin/bash
DATA=$(date +%F_%H-%M)
DEST=/var/backups/db
mkdir -p "$DEST"
mysqldump -u root --single-transaction --all-databases | gzip > "$DEST/db_$DATA.sql.gz"
# Mantem so os ultimos 14 dias
find "$DEST" -name "db_*.sql.gz" -mtime +14 -delete

Dê permissão e agende no cron (todo dia às 3h):

chmod +x /root/backup-db.sh
crontab -e
# adicione a linha:
0 3 * * * /root/backup-db.sh

Pronto: backup diário, comprimido, com retenção de 14 dias. (Guarde as credenciais num arquivo .my.cnf com permissão restrita em vez de deixá-las no script.)

O passo que salva de verdade: mandar para fora do servidor

Backup no mesmo servidor não te protege se o servidor for comprometido, corrompido ou perdido. Envie uma cópia para outro lugar — outro servidor, um bucket S3/Backblaze, ou o Google Drive via rclone:

rclone copy /var/backups/db remoto:backups-db

Adicione essa linha ao final do script de backup e você terá cópias offsite automáticas.

O passo que quase todo mundo pula: RESTAURAR

Um backup nunca restaurado é uma aposta, não uma garantia. Restaurar é simples — e você precisa saber fazer antes da emergência:

# de um dump comprimido:
gunzip < backup.sql.gz | mysql -u root -p nome_do_banco

# de um .sql simples:
mysql -u root -p nome_do_banco < backup.sql

Teste periodicamente restaurando num banco de teste. Confirme que os dados voltam inteiros. Fazer isso uma vez por trimestre transforma esperança em certeza.

Antes de toda mudança grande

Crie o hábito: antes de uma migração, atualização de app ou alteração em massa, rode um dump manual. Se algo der errado, você volta em segundos em vez de entrar em pânico.

Checklist de backup de banco

• [ ] mysqldump/pg_dump com compressão
• [ ] --single-transaction para dumps consistentes sem travar
• [ ] Agendado no cron, com retenção (ex.: 14 dias)
• [ ] Cópia offsite (outro servidor / S3 / rclone)
• [ ] Restauração testada ao menos uma vez
• [ ] Dump manual antes de mudanças grandes

Controle total do seu backup

Automatizar dumps, cron e envio offsite exige acesso root — território da VPS. A VittHost oferece VPS com root e IP dedicado, no Brasil e no Canadá:

👉 Ver planos de VPS

Com o backup garantido, acelere o banco: veja como otimizar MySQL/MariaDB.