Como fazer backup de MySQL e MariaDB sem corromper: mariadb-dump, mysqldump, mariadb-backup e XtraBackup, com agendamento, restauração e testes.

Para que serve

Copiar a pasta /var/lib/mysql com o banco ligado gera um backup que muitas vezes não sobe. Este artigo mostra os dois jeitos corretos de fazer backup de MySQL e MariaDB: o backup lógico (um arquivo SQL, portátil entre versões, ideal até algumas dezenas de GB) e o backup físico a quente (cópia consistente dos arquivos de dados, muito mais rápida para bancos grandes). Os comandos valem para MariaDB 10.11/11.x (Debian 12/13, Ubuntu 24.04) e MySQL 8.0/8.4.

Pré-requisitos

  • Acesso root ao servidor ou à VM onde o banco roda.
  • Espaço livre em disco para ao menos um backup completo, de preferência em outro volume.
  • Saber se as tabelas são InnoDB (quase sempre). Tabelas MyISAM não têm cópia consistente sem travamento.
Nomes dos comandos mudaram. No MariaDB, os clientes passaram a se chamar mariadb, mariadb-dump e mariadb-backup. Os nomes antigos mysqldump e mariabackup podem não existir nas versões 11.x. No MySQL 8.4, o mysqlpump foi removido; use mysqldump ou o MySQL Shell.

Opção 1: backup lógico com mariadb-dump / mysqldump

  1. Credenciais. No Debian e no Ubuntu, o root do sistema entra no MariaDB pelo socket sem senha. Se o seu servidor exige senha, crie /root/.my.cnf:

    [client]
user=root
password=SUA_SENHA
    chmod 600 /root/.my.cnf

  2. Teste um dump manual de um banco.

    mariadb-dump --single-transaction --routines --triggers --events \
  --hex-blob --default-character-set=utf8mb4 meubanco | zstd -q > /var/backups/meubanco.sql.zst

    A opção --single-transaction lê tudo dentro de uma única transação: o dump sai consistente sem travar as tabelas InnoDB. No MySQL, troque mariadb-dump por mysqldump; as opções são as mesmas. Instale o zstd com apt install zstd se necessário.

  3. Automatize um arquivo por banco. Arquivos separados permitem restaurar um único banco sem tocar nos outros. Crie /usr/local/sbin/dump-mariadb.sh:

    #!/bin/bash
set -euo pipefail
DEST=/var/backups/mysql
DATA=$(date +%F_%H%M)
mkdir -p "$DEST"

for db in $(mariadb -N -e "SHOW DATABASES" | grep -Ev '^(information_schema|performance_schema|sys|mysql)$'); do
  mariadb-dump --single-transaction --routines --triggers --events \
    --hex-blob --default-character-set=utf8mb4 "$db" | zstd -q > "$DEST/${db}_${DATA}.sql.zst"
done

# usuarios e permissoes (MariaDB 10.11+)
mariadb-dump --system=users | zstd -q > "$DEST/_usuarios_${DATA}.sql.zst"

# mantem 7 dias localmente
find "$DEST" -name '*.sql.zst' -mtime +7 -delete
    chmod 700 /usr/local/sbin/dump-mariadb.sh
echo '0 1 * * * root /usr/local/sbin/dump-mariadb.sh' > /etc/cron.d/dump-mariadb

    Para entender o agendamento, veja também o artigo «Como agendar tarefas no Linux com cron e com systemd timers».

    No MySQL não existe --system=users. Exporte os usuários com o MySQL Shell (util.dumpInstance inclui contas) ou gere os comandos com SHOW CREATE USER e SHOW GRANTS.

  4. Leve a cópia para fora do servidor com restic ou rclone (veja os artigos desta categoria), agendando-os depois do dump.

Restaurar um dump

mariadb -e "CREATE DATABASE meubanco_teste CHARACTER SET utf8mb4"
zstd -dc /var/backups/mysql/meubanco_2026-10-08_0100.sql.zst | mariadb meubanco_teste

Restaurar com outro nome permite conferir os dados antes de substituir o banco de produção. Se o banco roda em uma VM, veja também o artigo «Banco de dados em VM no Proxmox: disco, cache e ZFS (volblocksize, recordsize e sync)».

Opção 2: backup físico a quente (bancos grandes)

Para bancos acima de 30 a 50 GB, o dump e principalmente a restauração (que reconstrói todos os índices) ficam lentos. O backup físico copia os arquivos InnoDB enquanto o banco funciona e depois os deixa consistentes.

MariaDB: mariadb-backup

  1. Instale o pacote da mesma versão do servidor e faça o backup:

    apt install -y mariadb-backup
mariadb-backup --backup --target-dir=/var/backups/mariadb-full/$(date +%F)

  2. Prepare o backup (aplica o log de transações e deixa os arquivos prontos para uso). Faça isso logo após o backup, não na hora do desastre:

    mariadb-backup --prepare --target-dir=/var/backups/mariadb-full/2026-10-08

  3. Para restaurar, o diretório de dados precisa estar vazio e o serviço parado:

    systemctl stop mariadb
mv /var/lib/mysql /var/lib/mysql.antigo
mkdir /var/lib/mysql
mariadb-backup --copy-back --target-dir=/var/backups/mariadb-full/2026-10-08
chown -R mysql:mysql /var/lib/mysql
systemctl start mariadb

O mariadb-backup também faz backups incrementais (--incremental-basedir), úteis quando o banco é grande e muda pouco.

MySQL 8.0/8.4: Percona XtraBackup ou MySQL Shell

  • Percona XtraBackup é o equivalente para MySQL: xtrabackup --backup --target-dir=..., depois xtrabackup --prepare e xtrabackup --copy-back. A série do XtraBackup deve acompanhar a do servidor (8.0 para MySQL 8.0, 8.4 para MySQL 8.4).
  • MySQL Shell (mysqlsh) faz dumps lógicos em paralelo, bem mais rápidos que o mysqldump: util.dumpInstance("/var/backups/mysqlsh") e, para restaurar, util.loadDump(...).

Recuperação até um ponto no tempo

Se o RPO precisa ser menor que o intervalo entre dumps, ative o log binário (log_bin) e guarde os arquivos de binlog junto com o backup. Na restauração, você volta o último backup completo e reaplica os binlogs até o minuto anterior ao problema com mariadb-binlog (ou mysqlbinlog). Registre a posição do binlog no dump com --master-data=2 no MariaDB ou --source-data=2 no MySQL.

Como testar o backup de MySQL e MariaDB

  • Os arquivos do dia existem e não estão vazios: ls -lh /var/backups/mysql.
  • O dump termina com a linha de conclusão: zstd -dc ARQUIVO | tail -1 deve mostrar -- Dump completed on ....
  • Uma vez por mês, restaure em um banco de teste e compare a contagem de linhas das principais tabelas com a produção.

Problemas comuns

"Got packet bigger than max_allowed_packet"

Há registros grandes (BLOBs). Acrescente --max-allowed-packet=1G no dump e ajuste a mesma variável no servidor de destino da restauração.

Restauração em outra versão falha com erro de collation

Dumps do MySQL 8 usam utf8mb4_0900_ai_ci, que versões mais antigas do MariaDB não reconhecem. Ao migrar de MySQL para MariaDB, substitua a collation no arquivo ou converta para utf8mb4_unicode_ci antes.

mariadb-backup reclama de versão

O mariadb-backup precisa ser da mesma versão do servidor. Atualize os dois juntos e faça um backup completo novo após cada atualização de versão principal.

Dump trava a aplicação

Provavelmente há tabelas MyISAM ou o dump foi feito sem --single-transaction. Converta as tabelas para InnoDB ou agende o dump para a madrugada.

Perguntas frequentes

Posso copiar a pasta /var/lib/mysql como backup?

Não com o banco ligado: a cópia sai inconsistente e muitas vezes não sobe. Use um dump lógico ou o backup físico a quente com mariadb-backup ou XtraBackup.

Qual a diferença entre mysqldump e mariadb-dump?

São a mesma ferramenta com nomes diferentes. No MariaDB o nome atual é mariadb-dump, e o antigo pode não existir nas versões 11.x; no MySQL continua mysqldump.

O mysqldump trava as tabelas?

Com --single-transaction, tabelas InnoDB não são travadas e o dump sai consistente. Tabelas MyISAM continuam sendo um problema; converta-as para InnoDB.

Quando usar backup físico em vez de dump?

Em bancos acima de 30 a 50 GB, quando o dump e principalmente a restauração ficam lentos demais para o RTO do negócio.

Como restaurar o banco até um horário específico?

Ative o log binário, restaure o último backup completo e reaplique os binlogs até o minuto anterior ao problema com mariadb-binlog ou mysqlbinlog.

Leitura complementar

Precisa de ajuda?

Se o backup ou a restauração do banco der erro, abra um ticket na área do cliente com a mensagem completa e a versão do banco (mariadb --version ou mysql --version).

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também