Backup MySQL · 3 min read · Feb 10, 2026

Backup e Recuperação MySQL Com mysql-zrm No Debian Sarge - Página 4

6 Verifique Seus Backups

Agora queremos verificar a integridade do nosso conjunto de backup dailyrun. Podemos fazer isso assim:

mysql-zrm --action verify-backup --backup-set dailyrun

A saída deve ser parecida com isto:

| Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305. INFO: mysql-zrm-version INFO: Verification successful |

(Você pode ignorar o aviso na primeira linha, não é nada sério.)

Em seguida, queremos verificar um backup específico dentro do nosso conjunto de backup dailyrun. Primeiro, executamos

mysql-zrm-reporter -show restore-full-info --where backup-set=dailyrun

para descobrir quais backups estão disponíveis:

| backup_set backup_date backup_level backup_directory ---------------------------------------------------------------------------------------------------------- dailyrun Tue 26 Sep 2006 07:57:47 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195747 dailyrun Tue 26 Sep 2006 07:58:08 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195808 dailyrun Tue 26 Sep 2006 07:58:31 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195831 dailyrun Tue 26 Sep 2006 08:24:04 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926202404 |

Como você pode ver, há quatro backups em nosso conjunto de backup dailyrun. Queremos verificar o último, que está no diretório /var/lib/mysql-zrm/dailyrun/20060926202404. É assim que podemos fazer isso:

mysql-zrm --action verify-backup --backup-set dailyrun --no-quiet --source-directory /var/lib/mysql-zrm/dailyrun/20060926202404

A saída deve ser parecida com isto:

| Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305. INFO: mysql-zrm-version INFO: Verification successful |

7 Recuperação de Dados

Vamos supor que nosso banco de dados tenha falhado e perdemos dados. É assim que podemos restaurar nossos dados a partir de nossos backups MySQL. Primeiro, executamos

mysql-zrm-reporter -show restore-full-info --where backup-set=dailyrun

para descobrir quais backups estão disponíveis:

| backup_set backup_date backup_level backup_directory ---------------------------------------------------------------------------------------------------------- dailyrun Tue 26 Sep 2006 07:57:47 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195747 dailyrun Tue 26 Sep 2006 07:58:08 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195808 dailyrun Tue 26 Sep 2006 07:58:31 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195831 dailyrun Tue 26 Sep 2006 08:24:04 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926202404 |

Queremos restaurar a partir do nosso último backup, que está em /var/lib/mysql-zrm/dailyrun/20060926202404:

mysql-zrm --action restore --backup-set dailyrun --source-directory /var/lib/mysql-zrm/dailyrun/20060926202404

A saída é parecida com isto:

| Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305. INFO: mysql-zrm-version INFO: Restored database from raw backup: egroupware INFO: Restored database from raw backup: mysql INFO: Restore done in 14 seconds. MySQL server has been shutdown. Please restart after verification. |

Os dados foram restaurados, mas o servidor MySQL foi desligado. Portanto, devemos iniciá-lo agora:

/etc/init.d/mysql start

Se você fez seus backups no formato lógico em vez do formato bruto, você também pode recuperar seus dados assim.

8 Múltiplas Políticas de Backup

Até agora, tínhamos uma configuração global em /etc/mysql-zrm/mysql-zrm.conf que se aplicava a todos os nossos conjuntos de backup. Agora vamos supor que temos um conjunto de backup osCommerce para nosso banco de dados osCommerce, outro conjunto de backup vBulletin para nosso banco de dados vBulletin, etc.

Não faz sentido fazer backup de todos os nossos bancos de dados MySQL no conjunto de backup osCommerce, porque esse backup deve conter apenas o banco de dados osCommerce, e o mesmo se aplica ao nosso conjunto de backup vBulletin. É assim que podemos resolver esse problema:

Cada conjunto de backup tem seu próprio subdiretório no diretório /etc/mysql-zrm, por exemplo, o conjunto de backup osCommerce tem o diretório /etc/mysql-zrm/osCommerce. Agora, sempre que o mysql-zrm é executado, ele primeiro verifica a configuração global em /etc/mysql-zrm/mysql-zrm.conf e, em seguida, verifica o diretório do conjunto de backup atual para o arquivo mysql-zrm.conf cujas configurações substituem as configurações globais em /etc/mysql-zrm/mysql-zrm.conf. Por exemplo, se o conjunto de backup atual for osCommerce, o mysql-zrm leria primeiro a configuração de /etc/mysql-zrm/mysql-zrm.conf e depois a configuração de /etc/mysql-zrm/osCommerce/mysql-zrm.conf.

Se quisermos apenas fazer backup do banco de dados MySQL osCommerce no conjunto de backup osCommerce, colocamos o seguinte em /etc/mysql-zrm/osCommerce/mysql-zrm.conf:

vi /etc/mysql-zrm/osCommerce/mysql-zrm.conf

| databases=osCommerce |

9 Remoção de Backups Antigos

Se você não definiu a política de retenção em sua configuração mysql-zrm, os backups MySQL são mantidos para sempre, o que significa que seu disco rígido ficará cheio com o tempo. Você pode remover backups antigos simplesmente excluindo o diretório de backup. Por exemplo, se você tiver um backup em /var/lib/mysql-zrm/dailyrun/20060926195831 e não precisar mais dele, você pode excluí-lo assim:

rm -fr /var/lib/mysql-zrm/dailyrun/20060926195831

10 Log

mysql-zrm registra no arquivo de log /var/log/mysql-zrm/mysql-zrm.log.

Share: X/Twitter LinkedIn

Receba novas postagens na sua caixa de entrada

Sem spam. Cancele a assinatura a qualquer momento.