Backup MySQL · 9 min read · Dec 10, 2025

Backup Incremental MySQL - Backup e Recuperação de Ponto no Tempo de Bancos de Dados InnoDB e MyIsam

Fazer backups incrementais é um requisito importante para grandes bancos de dados de produção. Sem um backup incremental seguro, você não pode se dizer que possui um banco de dados de produção confiável. Porque você deve ter dados suficientes para recuperar seu banco de dados em casos de emergência. Após algumas pesquisas na Internet, não consegui encontrar nenhuma ferramenta que possa fazer um backup incremental completo para MyISAM e InnoDB em um ambiente misto onde aplicações usam ambos os mecanismos de banco de dados simultaneamente (talvez eu não seja um pesquisador especialista no Google e na Internet). Então decidi escrever este, mas para evitar perder tempo e beneficiar de outras soluções de código aberto, preferi adicionar esse recurso ao script -automysqlbackup- que é o melhor script para backup completo em simplicidade e uso generalizado.

Mecanismo

Usamos o recurso Post- e Pre do automysqlbackup para fazer um backup incremental. Antes de iniciar um backup completo, mysql-backup-pre executa uma consulta para bloquear todo o banco de dados durante o processo de backup porque precisamos congelar o binlog para evitar qualquer alteração enquanto o backup está em execução. O nome e a posição do binlog não podem mudar durante o backup. A posição do log binário é muito crucial no subsequente processo de backup incremental e será usada como ponto de partida para iniciar o próximo backup incremental. Após terminar o backup completo, mysql-backup-post remove o bloqueio do banco de dados.

Consulta de Bloqueio: FLUSH TABLES WITH READ LOCK; SELECT SLEEP(86400)

Encontrar Consultas de Bloqueio: mysql -u[username] -p[pass] -e “show processlist” | grep “SELECT SLEEP(86400)” | awk ‘{print $1}’

Requisitos

  • privilégios de root para instalar pacotes e atualizar mysql.conf
  • pacote mysql-community-client
  • instalação do automysqlbackup e mysql-incremental

Instalação

Instale o pacote mysql-community-client para sua distribuição.

Nota: após a instalação do MySQL, você deve ter o comando ‘mysqlshow’.

Instale o automysqlbackup:

download the package from https://sourceforge.net/projects/automysqlbackup/
tar -xzf [PathYouSavedTarFile] -C /tmp/
cd /tmp/
./install.sh

Durante a instalação do automysqlbackup, você será perguntado sobre o caminho do automysqlbackup.conf e seu binário, você pode deixar os padrões sem nenhuma alteração.

rm /etc/automysqlbackup/myserver.conf

Instale o mysql-incremental: Baixe o pacote de https://sourceforge.net/projects/mysqlincrementalbackup/

cd /tmp  
wget http://downloads.sourceforge.net/project/mysqlincrementalbackup/mysql-incremental.tar.gz  
tar xfz mysql-incremental.tar.gz
cp mysql-incremental /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-incremental
cp mysql-backup-post /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-backup-post
cp mysql-backup-pre /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-backup-pre

Atualize o automysqlbackup.conf:

Encontre os parâmetros abaixo, descomente e altere-os:

        CONFIG_mysql_dump_username='Nome de usuário Mysql. Deve ter privilégios para obter Lock'
    CONFIG_mysql_dump_password='Senha'
    CONFIG_backup_dir='O diretório de backup onde você deseja armazenar o backup completo e incremental'
    CONFIG_db_names=('databaseName1' 'databaseName2' )
    CONFIG_db_month_names=('databaseName1' 'databaseName2' )
    CONFIG_mysql_dump_master_data=2
    CONFIG_prebackup="/etc/automysqlbackup/mysql-backup-pre"
    CONFIG_postbackup="/etc/automysqlbackup/mysql-backup-post"

Atualizar my.cnf:

Edite o arquivo de configuração do MySQL:

nano /etc/mysql/my.cnf

1- Formato do BinLog

Devido a algumas limitações no formato STATEMENT, minha recomendação é definir o formato baseado em ROW. Para mais informações, consulte a seção ‘solução de problemas’ neste howto. Você pode verificar o tipo de formato do log binário executando a consulta “ select @@binlog_format; “. Para modificar o formato logbin, você deve adicionar binlog_format = ROW ao mysql.conf ou my.cnf.

2- binlog_do_db

Você deve especificar os bancos de dados que pretende ter as alterações relacionadas no log binário. Observe que se você não especificar nenhum banco de dados, qualquer alteração em qualquer banco de dados será registrada no log binário. Nesse caso, se você escolher o formato STATEMENT, pode ter alguns problemas ao restaurar a partir do backup incremental e arquivos binlog. Você pode adicionar bancos de dados a esta opção:

binlog_do_db = DATABASENAME1
binlog_do_db = DATABASENAME2

3- expire_logs_days

Para ter arquivos de log binário por mais tempo, você pode aumentar este parâmetro para um valor mais alto. Minha recomendação é 60 dias. Portanto, você deve adicionar ou alterá-lo para “ expire_logs_days = 60 “.

4- log-bin

O diretório onde os logs binários serão armazenados. Em versões antigas do MySQL, o mysql-incremental pode não conseguir encontrar o caminho correto. Portanto, se você receber um erro sobre isso após executar o mysql-incremental, deve atualizar o script mysql-incremental e definir o caminho do log binário.

5- log_slave_updates

Se você estiver configurando o backup mysql-incremental em um servidor escravo, deve habilitar esta opção. Normalmente, um escravo não registra atualizações em seu próprio log binário, pois foram recebidas de um servidor mestre. Esta opção informa ao escravo para registrar as atualizações realizadas por suas threads SQL em seu próprio log binário. http://dev.mysql.com/doc/refman/5.1/en/replication-options-slave.html#option_mysqld_log-slave-updates

Executar automysqlbackup

Execute o automysqlbackup manualmente para ter pelo menos um backup completo de seus bancos de dados especificados.

automysqlbackup

Após executar o comando com sucesso, verifique o arquivo /[BackupDirInAutomysqlbackup]/status/backup_info para as novas informações adicionadas sobre o backup diário. Para detalhes de erro, verifique /var/log/Backup_Post_Pre_log. O arquivo de backup será armazenado no diretório /[BackupDirInAutomysqlbackup]/daily/[DatabaseName]/.

Executar mysql-incremental

Execute o mysql-incremental manualmente agora para ter pelo menos um backup horário.

mysql-incremental

Em caso de erro, os detalhes são registrados no arquivo “/var/log/Backup_Incremental_Log”. Os arquivos de backup incrementais serão armazenados no diretório /[BackupDirInAutomysqlbackup]/IncrementalBackup/.

Editar o crontab do root

Você pode agendar o mysql-incremental por mais de uma hora. Você pode encontrar o tempo total do backup completo a partir do backup_status e, em seguida, com base nesse valor, definir um horário de agendamento preciso. Claro que o backup mysql-incremental tem um mecanismo para encontrar qualquer backup completo em execução antes de começar, então não há preocupação com conflitos entre backups incrementais e completos.

crontab -e
5 00 * * * root /usr/local/bin/automysqlbackup
25 *  * * * root  /etc/automysqlbackup/mysql-incremental

Restaurar Banco de Dados

Para restaurar até um horário específico (recuperação ponto a ponto), primeiro você deve restaurar um backup diário completo e, em seguida, restaurar sequencialmente os arquivos de backup incrementais relacionados. Para esclarecer mais, aqui estão os passos para recuperar o banco de dados testDB. No cenário de exemplo, pretendemos recuperar nossos dados até 2015-5-01 às 2 AM. definimos /backup como nosso diretório principal de backup e testDB como nosso banco de dados alvo:

1- mysql -u root -p DatabaseName < /backup/daily/testDB/daily_DatabaseName_2015-05-16_00h05m_Saturday.sql.gz
2- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_00h25m.1
3- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_01h25m.2
4- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_02h25m.3

Notas Importantes e Solução de Problemas

MySQL suporta diferentes formatos para o log binário. Algumas versões do Mysql usam ‘statement-based’ como formato binlog que esse tipo de binlog tem algumas limitações que devemos prestar atenção quando pretendemos usá-lo no procedimento de backup incremental. Quando o mysql está configurado para o formato baseado em statement, ele não consegue filtrar corretamente com base nos bancos de dados. Se você definir ‘USE ou \u’ para mudar de banco de dados e, em seguida, atualizar outro banco de dados que não está incluído em binlog-do-db, a declaração será registrada no arquivo binlog, o que não é um estado desejável! e exporá alguns problemas ao restaurar com base em um banco de dados específico e também se você mudar para outro banco de dados que não está incluído em binlog-do-db, e atualizar um banco de dados que está incluído em binlog-do-db, a declaração não será registrada no arquivo binlog. nosso objetivo ao adicionar bancos de dados ao binlog-do-db é filtrar com base no banco de dados, mas não funciona como esperado. Se USE ou \u não for executado antes de executar consultas, mysqlbinlog não pode extrair ‘consultas de atualização’ relacionadas a um banco de dados. Explicaremos mais sobre esse problema com os cenários abaixo:

bancos de dados: 
 - binlog
     - pessoa (tabela) 
  - binlog2
     - pessoa (tabela)

 binlog-do-db=binlog2 (supõe-se que apenas a alteração deste banco de dados seja registrada no arquivo binlog)
--------Cenário 1---------
\u binlog2
insert into person (data) values ('17') ---> registrado no binlog  *estado desejado*
insert into binlog.person (data) values ('25'); ---> registrado no binlog (o banco de dados alvo é 'binlog') *estado indesejado*
--------Cenário 2---------
\u binlog
insert into person (data) values ('17') ---> não é registrado no binlog  *estado desejado*
insert into binlog2.person (data) values ('25'); ---> não é registrado no binlog (o banco de dados alvo é 'binlog2') *estado indesejado* porque o banco de dados binlog2 está sendo alterado, então queremos ter essa alteração, mas não será registrada no arquivo logbin
--------Cenário 3---------
se você apenas se conectar ao banco de dados sem nenhuma declaração USE ou \u, todas as atualizações em qualquer banco de dados serão registradas, mas mysqlbinlog não poderá filtrar com base em um banco de dados específico, então esse não é um estado desejável para nosso propósito no backup incremental. Usar USE ou \u antes de executar consultas de atualização é muito importante. Porque mysqlbinlog encontra consultas de atualização com base na declaração USE no arquivo binlog.

Solução alternativa para o problema mencionado

  1. Definindo usuários em bancos de dados de forma que cada usuário tenha acesso apenas a um banco de dados para atualizar (usuário da aplicação) e, ao se conectar ao banco de dados, o nome do banco de dados deve ser especificado. Claro que a maioria das aplicações possui um arquivo de configuração onde as credenciais e o nome do banco de dados estão definidos, então, nesse caso, você não terá acesso cruzado aos bancos de dados e não haverá preocupação em usar “\USE ou \u”.

  2. Se você usar o formato binlog baseado em linha, todos os problemas mencionados desaparecerão. Em outras palavras, o formato baseado em linha é um método muito mais adequado para binlog. https://dev.mysql.com/doc/refman/5.1/en/replication-options-binary-log.html

Arquivos de Log

Tentei registrar tudo em um arquivo de log para que você possa encontrar informações suficientes nos logs:

/var/log/Backup_Post_Pre_log
/var/log/Backup_Incremental_Log
/[SpecifiedBackupDirInAutomysqlbackup.conf]/status/backup_info

O arquivo “backup_info” contém informações detalhadas sobre o backup e quando o backup foi finalizado (Os horários estão no formato de Tempo Unix). Contém o nome do binlog e a posição do ponto no tempo em que o backup começou, o tipo de backup, o número de backups desde o último backup completo e a duração do backup.

Exemplo de backup_info:

1431043501,mysql-bin.000026,120,Daily,2015-05-08,0,24
1431044701,mysql-bin.000026,120,Hourly,2015-05-08,1,1

Aqui está a descrição dos diferentes valores:

 1º) 1431043501 : indica o momento em que o backup foi finalizado. Você pode executar o comando date --date @1431043501 no servidor onde o backup foi feito para visualizá-lo em formato legível por humanos.
 2º) Mysql-bin.000026 : indica o nome do log binário que o backup até este arquivo foi feito.
 3º) 120 : indica a posição do binlog que o backup até esta posição no log binário foi feito.
 4º) Diário/Horário: indica o tipo de backup. Diário significa o backup completo pelo script automysqlbackup e Horário é feito pelo script mysql-incremental.
 5º) 2015-05-08: A data em que o backup foi feito. Esta data será usada na criação do diretório para backup incremental e também como base para restaurar backups horários. No procedimento de restauração, primeiro um backup completo é restaurado e, em seguida, outros backups incrementais são restaurados sequencialmente.
 6º) 0 : indica o número de backups desde o último backup completo. 0 significa que o backup é completo e outros significam horário. Este número é muito importante no procedimento de restauração.
 7º) 24: A duração do backup em segundos.

Relatório de Bug

Você pode relatar bugs ou dar suas sugestões e comentários em https://sourceforge.net/projects/mysqlincrementalbackup.

Share: X/Twitter LinkedIn
#Backup MySQL

Receba novas postagens na sua caixa de entrada

Sem spam. Cancele a assinatura a qualquer momento.