Para instalar o rsync, procure pelo pacote "rsync" no gerenciador de pacotes. No Debian instale com um "apt-get install rsync" e no Mandriva com um "urpmi rsync".
Para fazer um backup local, basta informar a pasta de origem e a pasta de destino, para onde os arquivos serão copiados, como em:
$ rsync -av /mnt/hda6/trabalho/ /mnt/backup/
A opção "-a" (archive) faz com que todas as permissões e atributos dos arquivos sejam mantidos, da mesma forma que ao criar os arquivos com o tar, e o "v" (verbose) mostra o progresso na tela.
A cópia inicial vai demorar um pouco, mais do que demoraria uma cópia simples dos arquivos, mas, a partir da segunda vez, a operação será muito mais rápida, já que serão copiadas apenas as mudanças.
Note que neste comando estamos copiando a pasta "trabalho" recursivamente para dentro da "/mnt/backup", de forma que seja criada a pasta "/mnt/backup/trabalho". Se omitíssemos a barra, como em "rsync -av /mnt/hda6/trabalho /mnt/backup/", o rsync copiaria o conteúdo interno da pasta diretamente para dentro da "/mnt/backup". Como pode ver, a barra final é importante dentro da sintaxe do rsync.
Se algum desastre acontecer e você precisar recuperar os dados, basta inverter a ordem das pastas no comando, fazendo com que a pasta com o backup seja a origem e a pasta original seja o destino, como em:
$ rsync -av /mnt/backup/trabalho/ /mnt/hda6/trabalho
O rsync é bastante prático para automatizar backups locais, como em casos em que o servidor possui dois HDs e você deseja que o segundo armazene uma cópia completa dos arquivos do primeiro, para o caso de qualquer eventualidade. Um exemplo de script de backup simples para esta função seria:
#! /bin/sh
mount /dev/sdb1 /mnt/sdb1
rsync -av --delete /var/ /mnt/sdb1/ >> /tmp/rsync.log
rsync -av --delete /home/ /mnt/sdb1/ >> /tmp/rsync.log
rsync -av --delete /etc/ /mnt/sdb1/ >> /tmp/rsync.log
umount /mnt/sdb1
hdparm -S 24 /dev/sdb
Neste exemplo, estou salvando cópias das pastas "var", "home" e "etc" na partição "/dev/sdb1", montada pelo script dentro da pasta "/mnt/sdb1". O ">> /tmp/rsync.log" faz com que a saída dos comandos seja salva no arquivo especificado, de forma que você possa verificar as mensagens no dia seguinte, em busca de erros.
O "--delete" faz com que arquivos apagados na pasta original sejam apagados também na pasta do backup, fazendo com que ela se mantenha como uma cópia fiel. Naturalmente, a opção pode ser removida do comando se o objetivo é fazer com que o backup mantenha arquivos antigos, de forma que você possa recuperá-los posteriormente, caso necessário.
Uma peculiaridade do script é que a partição é montada no início do script e desmontada no final. A idéia seria que o segundo HD fosse usado apenas para o backup e ficasse desativado no restante do tempo, de forma que o desgaste (e a possibilidade de qualquer defeito mecânico) seja reduzido. O comando "hdparm -S 24 /dev/sdb" executado no final do script ajusta o gerenciamento de energia para o HD, fazendo com que ele entre em modo standby (onde os discos param de girar, as cabeças de leitura ficam estacionadas e apenas parte dos componentes da placa lógica ficam ativos) depois de 2 minutos de inatividade. Com isso, o HD será ativado no início da backup e ficará dormindo todo o resto do tempo, praticamente sem consumir energia.
Este script poderia ser executado uma vez por dia usando o cron, de forma que você tivesse sempre um backup do dia anterior à mão, pronto para recuperar qualquer arquivo deletado acidentalmente. Naturalmente, este backup local deveria ser complementado por algum backup remoto, que permitisse recuperar os arquivos em casos de catástrofes. Para isso, você poderia complementá-lo com um backup completo feito usando o tar e o scp, como vimos no tópico anterior.
É possível também fazer backups incrementais com o rsync de forma muito simples usando-o em combinação com o comando "cp -al". O comando "cp -a" permite fazer uma cópia exata de uma pasta, copiando todo o seu conteúdo e mantendo todas as permissões de acesso. Entretanto, quando adicionamos o parâmetro "l", o cp passa a se comportar de forma completamente diferente, criando hard links em vez de copiar os arquivos.
Diferente dos soft links (criados usando o comando "ln -s"), os hard links são atalhos que apontam diretamente para os inodes dos arquivos de destino dentro do sistema de arquivos. Com isso, eles são vistos pelo sistema exatamente da mesma forma que os arquivos reais, com exceção de que eles não ocupam espaço (com exceção dos poucos bytes usados pelo atalho). Ao usar o comando "cp -al", criamos uma cópia exata da pasta original, onde os arquivos são substituídos por hard links apontando para os arquivos originais.
Com isso, podemos usar o rsync para realizar backups incrementais, usando o "cp -al" para gerar "snapshots" das cópias dos dias anteriores. Veja um exemplo:
rm -rf backup.6
mv backup.5 backup.6
mv backup.4 backup.5
mv backup.3 backup.4
mv backup.2 backup.3
mv backup.1 backup.2
cp -al backup.0 backup.1
rsync -av --delete /arquivos/ backup.0
Se executado diariamente, este pequeno script criaria um conjunto de 7 pastas, numeradas de 0 a 6, usadas para armazenar os backups. Tudo começaria com a pasta "backup.0", que armazenaria sempre o backup completo, feito através do rsync. Cada vez que o script é executado, o sistema rotaciona todas as pastas anteriores, copia a pasta "backup.0" para a "backup.1" usando o "cp -al" e em seguida atualiza o backup completo armazenado na pasta "backup.0", recomeçando o ciclo.
Se o script fosse executado todos os dias ao longo de uma semana, começando na segunda-feira, quando chegasse no domingo a pasta "backup.0" armazenaria o backup do domingo, a "backup.1" o do sábado e assim por diante, até chegar na "backup.6", que armazenaria o backup da segunda-feira anterior.
Como as pastas são na verdade conjuntos de hard links para os arquivos da pasta "backup.0", o espaço ocupado em disco seria equivalente ao de um único backup completo e não de sete.
Adaptando o script anterior para este novo conceito, teríamos o seguinte:
#! /bin/sh
mount /dev/sdb1 /mnt/sdb1
# Cria a pasta para o caso do script ser executado pela primeira vez:
mkdir /mnt/sdb1/backup.0 &>/dev/null
# Rotaciona as pastas anteriores:
rm -rf backup.6
mv backup.5 backup.6
mv backup.4 backup.5
mv backup.3 backup.4
mv backup.2 backup.3
mv backup.1 backup.2
# Faz a cópia usando o cp -al:
cp -al backup.0 backup.1
# Atualiza o backup na pasta backup.0:
rsync -av --delete /var/ /mnt/sdb1/backup.0/ >> /tmp/rsync.log
rsync -av --delete /home/ /mnt/sdb1/backup.0/ >> /tmp/rsync.log
rsync -av --delete /var/ /mnt/sdb1/backup.0/ >> /tmp/rsync.log
# Ao terminar, desmonta a partição e ativa o gerenciamento de energia:
umount /mnt/sdb1; hdparm -S 24 /dev/sdb
Este processo funciona bem para arquivos que foram criados e deletados (remover um arquivo da pasta original não o apaga das pastas com as cópias feitas usando o "cp -al"). A principal limitação desse processo é que, como na realidade existe apenas uma cópia do arquivo, quando o arquivo é atualizado todos hard links passam a apontar para a versão mais recente. Ou seja, se um usuário deletou um arquivo, você seria capaz de recuperá-lo 5 dias depois sem problemas, mas se ele precisa de uma versão anterior do arquivo, a situação se complica.
Em outras palavras, o fato de remover o arquivo da pasta "backup.0" não apaga as cópias armazenadas nas pastas anteriores; o arquivo é deletado do HD apenas se você remove todos os hard links que apontam pra ele. Este é o grande atrativo de usar hard links: você tem múltiplas cópias do arquivo sem ter que arcar com o espaço adicional. A grande limitação é que, diferente de ao usar múltiplas cópias completas, que você não tem como reverter alterações feitas nos arquivos, apenas recuperar arquivos deletados.
Devido a isso, é importante combinar o sistema de rotacionamento com backups semanais completos, de preferência arquivados em um local diferente, ou gravados em alguma mídia removível, como no caso dos DVDs e das fitas DAT.
Você poderia ter, então, dois scripts de backup, um executado todos os dias, fazendo o backup incremental e outro executado uma vez por semana, fazendo o backup completo. Ao agendá-los no cron, você teria uma configuração similar a essa:
59 4 * * * root /usr/local/bin/backup-incremental
59 6 * * 0 root /usr/local/bin/backup-completo
Com isso, o backup incremental seria feito todos os dias às 4:59, enquanto o backup completo seria feito apenas no domingo às 6:59. Veja que os scripts foram propositalmente agendados para serem executados em horários diferentes, para que o sistema tenha tempo de terminar o backup incremental do domingo antes de executar o script do backup completo.
O rsync pode ser também usado remotamente. Originalmente ele não utiliza nenhum tipo de criptografia, o que faz com que ele não seja muito adequado para backups via internet. Mas este problema pode ser resolvido com a ajuda do SSH, que pode ser utilizado como meio de transporte. Não é à toa que o SSH é chamado de canivete suíço, ele realmente faz de tudo.
Neste caso o comando ficaria um pouco mais complexo:
$ rsync -av --rsh="ssh -l gdh" /mnt/arquivos gdh@192.168.1.1:/mnt/backup/
Veja que foi adicionado um parâmetro adicional, o --rsh="ssh -l gdh", que orienta o rsync a utilizar o SSH como meio de transporte. O "-l gdh" orienta o SSH a se conectar ao servidor remoto usando o login "gdh". Naturalmente, para que o comando funcione, é preciso que o servidor esteja com o SSH habilitado e você tenha um login de acesso. Em seguida, vem a pasta local com os arquivos, o endereço IP (ou domínio) do servidor e a pasta (do servidor) para onde vão os arquivos.
Uma observação é que usando apenas os parâmetros "-av", o rsync se limita a atualizar e a gravar novos arquivos na pasta do servidor, sem remover arquivos que tenham sido deletados na pasta local. Por um lado isto é bom, pois permite recuperar arquivos deletados acidentalmente, mas por outro pode causar confusão. Se você preferir que os arquivos que não existem mais sejam deletados, adicione o parâmetro "--delete", que usamos no tópico anterior, como em:
$ rsync -av --delete --rsh="ssh -l gdh" /mnt/arquivos gdh@192.168.1.1:/mnt/backup/
Para recuperar o backup, basta inverter a ordem do comando, como em:
$ rsync -av --rsh="ssh -l gdh" gdh@192.168.1.1:/mnt/backup/ /mnt/arquivos
Você pode também ativar o uso de compressão, de forma a reduzir o volume de bytes transferidos. Isso é útil sobretudo ao fazer backup de bases de dados do MySQL ou de pastas com arquivos html, que geralmente suportam um bom índice de compressão. Para isso, basta adicionar o parâmetro "z", como em:
$ rsync -avz --rsh="ssh -l gdh" gdh@gdhn.com.br:/var/www/gdhn /mnt/backup/
Neste exemplo, salvamos uma cópia da pasta "/var/www/gdhn" do servidor "gdhn.com.br" no diretório local "/mnt/backup/", fazendo um backup local dos arquivos do site.
Originalmente, você vai precisar fornecer a senha de acesso ao servidor cada vez que executar o comando, o que impossibilita seu uso em scripts de backup automático. Para automatizar a conexão, a melhor solução é usar um par de chaves do SSH com a passphrase em branco, assim como no exemplo do backup automático usando o tar do exemplo anterior.
Imagine que você quer fazer um backup completo de todos os arquivos dentro da pasta "/var/www" do servidor A no servidor B, de forma que o tráfego web possa ser rapidamente desviado para ele em caso de problemas com o primeiro servidor.
O primeiro passo seria criar um novo usuário no servidor B, que permitirá o acesso aos arquivos por parte do servidor A, como em "adduser backup".
O passo seguinte seria gerar as chaves do SSH (no servidor A), com o comando "ssh-keygen -t rsa" usando o login do usuário que executará o script de backup (e deixando a passphrase em branco) e instalar a chave pública no servidor B, usando o comando:
# ssh-copy-id -i ~/.ssh/id_rsa.pub backup@servidorB
Até aqui os passos são os mesmos que vimos no tópico sobre o tar, já que apenas refizemos os passos para automatizar a autenticação do SSH. Falta agora apenas escrever o script de backup, que fará o sincronismo. Se você não precisar que o script faça checagens adicionais, ele poderia ter uma única linha, como em:
#!/bin/sh
rsync -avz --delete --rsh="ssh -l backup" /var/www backup@servidorB:/var/www/
Diferente do comando anterior, destinado a fazer uma cópia local do diretório "/var/www/gdhn" do servidor remoto, este script (que seria executado pelo servidor A) copia diretamente todos os arquivos da pasta "/var/www" para o servidor B, de forma que ele funcione como um espelho.
Uma observação importante é que o usuário "backup" no servidor B deve ter permissão de escrita na pasta "/var/www", do contrário o sincronismo não vai funcionar por falta de permissões.
Caso a idéia seja fazer com que as modificações feitas no servidor A sejam replicadas rapidamente para o servidor B (imagine o caso de um sistema de balanceamento de carga entre os dois servidores, por exemplo), você poderia usar o parâmetro "*/5" no campo de minutos ao incluir o trabalho no "/etc/crontab" (de forma que o script fosse executado a cada 5 minutos), como em:
*/5 * * * * root /usr/local/bin/script-rsync
Fazendo backup das bases de dados do MySQL: Uma das grandes dúvidas de qualquer administrador iniciante é como fazer backup das bases de dados do MySQL, já que os dados são gravados e acessados através do servidor MySQL e não diretamente através de arquivos, como no caso dos arquivos referentes aos sites, salvos na pasta "/var/www", por exemplo.
As bases de dados do MySQL são salvas por padrão dentro da pasta "/var/lib/mysql". Ao criar a base de dados "phpbb", por exemplo, será criada a pasta "/var/lib/mysql/phpbb", contendo um conjunto de arquivos, referentes às tabelas criadas.
A forma mais simples de fazer backup das bases de dados do MySQL é simplesmente salvar o conteúdo da pasta "/var/lib/mysql", criando um arquivo .tar.gz ou mesmo copiando os arquivos diretamente para outra partição. O maior problema é que as bases de dados são alteradas continuamente durante a operação do banco de dados, o que leva a cópias inconsistentes. Se alguns dos arquivos dentro da pasta com a base mudam no meio da cópia, o backup conterá uma mistura de dados novos e antigos, uma receita para o desastre.
A forma mais segura é parar o serviço do MySQL antes de fazer o backup, garantindo assim que nada será alterado durante a cópia, como no exemplo abaixo:
# /etc/init.d/mysql stop
# tar -zcvf mysql.tar.gz /var/lib/mysql/
# /etc/init.d/mysql start
Um exemplo de script de backup simples para fazer um backup completo dos arquivos da pasta "/var/www", contendo os arquivos de todos os sites hospedados no servidor, e também da base de dados do MySQL, incluindo as datas em que os backups foram realizados nos nomes dos arquivos, seria:
#!/bin/sh
# Acessa a pasta onde os backups serão salvos:
cd /var/backup
# Cria uma variável contendo a data atual:
DATA=`date +%Y-%m-%d-%H.%M`
# Faz backup da pasta /var/www:
tar -zcvf www-$DATA.tar.gz /var/www
# Pára o MySQL e faz backup das bases de dados:
/etc/init.d/mysql stop
tar -zcvf mysql-$DATA.tar.gz /var/lib/mysql
/etc/init.d/mysql start
Ao executar o script, você teria dois arquivos, como em "www-2008-06-27-07.21.tar.gz" e "mysql-2008-06-27-07.21.tar.gz". Veja que a data incluída nos nomes dos arquivos propositalmente inclui também a hora e os minutos em que foram gerados, de forma que você saiba exatamente quando os arquivos foram gerados e obtenha sempre arquivos de nomes diferentes, mesmo que o script seja executado várias vezes em seqüência.
Para automatizar a execução do script, você pode adicionar uma entrada no arquivo "/etc/crontab", assim como fizemos nos exemplos anteriores:
59 4 * * * root /usr/local/bin/script-backup
Esta entrada faria com que o script fosse executado todos os dias às 4:59 da manhã, sempre gerando dois novos arquivos com a data de quando foram executados. Com isso, ficaria faltando apenas copiar ou mover os arquivos regularmente para outro servidor, onde eles ficarão arquivados.
Um script como esse sem dúvidas pode resolver seu problema de forma simples. Você poderia incluir linhas adicionais para que o backup incluísse outras pastas do sistema, como por exemplo os diretórios com os logs. O problema com essa abordagem é que cada vez que o script é executado o servidor MySQL ficará fora do ar durante alguns segundos (ou minutos). Se a base de dados é usada pelo site da sua empresa, por exemplo, ele ficará fora do ar até que o backup seja concluído e o servidor MySQL volte a ser iniciado.
Agendar o backup usando o cron de forma que ele seja feito durante a madrugada (quando o tráfego é menor), minimiza o problema, mas não o soluciona completamente, já que, independentemente do horário, você vai acabar sempre perdendo algumas visitas.
A segunda opção é fazer um backup online, sem parar o servidor. O utilitário mais simples (e provavelmente o mais usado) para isso é o mysqldump, que acompanha o pacote principal do MySQL.
Diferente do método anterior, onde os arquivos são copiados diretamente, o mysqldump acessa o banco de dados por vias normais, da mesma forma que um aplicativo qualquer faria. Em outras palavras, ele não lê os arquivos, mas sim as informações armazenadas nas bases de dados. Isso permite que o backup seja consistente, mesmo que as bases de dados sejam alteradas durante o backup.
Para salvar todas as bases de dados do servidor no arquivo "backup.sql", criado no diretório atual, por exemplo, o comando seria:
# mysqldump -u root -p -x -e -A > backup.sql
O "-u root -p" especifica o usuário que será usado para acessar o banco de dados. No exemplo estou fazendo um backup completo, por isso estou usando diretamente o root. A opção "-x" trava as bases de dados no momento em que cada uma é copiada, evitando qualquer problema de inconsistência, enquanto a "-e" é uma opção de otimização, que permite ao mysqldump combinar argumentos INSERT dentro das tabelas, o que torna tanto o backup quanto a restauração mais rápidos. Finalizando, a opção "-A" especifica um backup completo, de todas as bases de dados.
Se o comando parasse por aí, o mysqldump simplesmente escreveria todo o conteúdo das bases de dados na própria janela do terminal, resultando em uma longa exibição de informações, sem muita utilidade. Como queremos que a saída seja salva em um arquivo, usamos o ">", que redireciona a saída para o arquivo especificado.
O arquivo "backup.sql" gerado é basicamente um arquivo de texto gigante contendo declarações de todas as informações armazenadas. Você pode reduzir o tamanho do arquivo para um quarto (ou menos) do tamanho original compactando o arquivo, o que pode ser feito adicionando a opção "| gzip" antes do ">" no comando, como em:
# mysqldump -u root -p -x -e -A | gzip > backup.sql.gz
Note que nesse exemplo adicionei também o ".gz" no nome do arquivo, indicando que se trata de um arquivo compactado. Para usá-lo posteriormente, você precisaria apenas descompactar o arquivo, usando o comando "gunzip", como em:
# gunzip backup.sql.gz
O maior problema com estes dois comandos é que você precisa digitar a senha do MySQL depois de rodar o comando, o que dificulta seu uso em scripts de backup automático. É possível eliminar a necessidade de digitar a senha especificando-a diretamente no comando, depois do "-p" (sem espaços), como em:
# mysqldump -u root -p12345 -x -e -A | gzip > backup.sql.gz
Um exemplo de script simples de backup automático usando o comando acima seria:
#!/bin/sh
cd /var/backup
DATA=`date +%Y-%m-%d-%H.%M`
# Faz backup das bases de dados usando o mysqldump
mysqldump -u root -p12345 -x -e -A | gzip > backup-$DATA.sql.gz
Se você gerou um par de chaves no SSH sem passphrase e instalou a chave pública no servidor de backup remoto, como vimos anteriormente, poderia adicionar as linhas abaixo no final do script para que o arquivo fosse automaticamente movido para o servidor de backup remoto no final do processo:
scp backup-$DATA.sql.gz usuario@servidor-de-backup:/mnt/backups/
rm -f backup-$DATA.sql.gz
O passo final seria adicionar uma entrada no cron para automatizar a execução do script. Para que ele fosse executado todas as segundas, quartas e sextas às 22:58 (para o exemplo ficar diferente do anterior :) a linha no arquivo "/etc/crontab" seria:
58 22 * * 1,3,5 root /usr/local/bin/script-backup
Note que ao incluir senhas em arquivos, é extremamente importante restringir as permissões, de forma que apenas o root (ou o usuário em questão) tenha permissão para lê-lo. Qualquer outro usuário do servidor que tenha acesso de leitura no arquivo, poderá ler a senha e acessar o servidor MySQL:
# chmod 700 /usr/local/bin/script-backup
Usando o "700" os demais usuários não poderão ver nem executar o arquivo, o que seria o ideal no nosso exemplo, já que a entrada no crontab faz com que ele seja executado usando a conta de root. Se você quiser que outros usuários possam executar o arquivo manualmente quando necessário, mas ainda assim sem poder ver a senha armazenada dentro dele, o ideal seria criar um grupo, adicionar os usuários desejados dentro dele e setar as permissões do arquivo para "710", onde os usuários que fazem parte do grupo podem apenas executar o arquivo, sem ver seu conteúdo. Os comandos seriam:
# addgroup backup-sql
# adduser joao backup-sql
# adduser joaquim backup-sql
# chown root:backup-sql /usr/local/bin/script-backup
# chmod 710 /usr/local/bin/script-backup
Voltando ao tema principal, o "mysqldump -u root -p -x -e -A" permite fazer um backup completo de todas as bases do servidor, que poderia ser usado para restaurar os dados em uma instalação limpa do MySQL. É possível também fazer backups localizados, contendo apenas uma base de dados específica.
Nesse caso, em vez de usar a opção "-A", você usaria a opção "-B", seguida pela base de dados a ser salva, como em:
# mysqldump -u root -p -x -e -B phpbb > phpbb.sql
Na hora de restaurar o backup, deixamos de usar o mysqldump e passamos a utilizar o cliente mysql, que se encarrega de ler os comandos e os dados adicionados nos arquivos e usá-los para povoar as bases de dados. O comando ficaria então:
# mysql -u root -p --database=phpbb < phpbb.sql
Você pode também especificar a senha diretamente no comando, assim como no caso do mysqldump, como em:
# mysql -u root -p12345 --database=phpbb < phpbb.sql
Se você tentar restaurar o backup sobre uma base de dados contendo dados, provavelmente receberá uma mensagem de erro logo no início do processo, avisando que uma das tabelas já existe, como em:
ERROR 1050 at line 19: Table 'wp_comments' already exists
A solução no caso é remover a base de dados antiga usando o cliente MySQL e criar outra em branco para então fazer a restauração, como em:
# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 18
Server version: 5.0.32-Debian_7etch5-log Debian etch distribution
Type 'help;' or 'h' for help. Type 'c' to clear the buffer.
mysql> DROP DATABASE phpbb;
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE DATABASE phpbb;
Query OK, 1 row affected (0.00 sec)
mysql> exit
Bye
# mysql -u root -p --database=phpbb < phpbb.sql
Outra opção seria adicionar a opção "--add-drop-table" ao gerar o backup com o mysqldump. Ela faz com que ele inclua instruções para que as bases sejam excluídas e recriadas automaticamente durante a restauração, evitando que você precise fazê-lo manualmente. O comando ficaria então:
# mysqldump --add-drop-table -u root -p -x -e -B phpbb > phpbb.sql
O comando para restaurar continua o mesmo, com a diferença de que você não precisa mais usar os comandos "DROP DATABASE;" e "CREATE DATABASE;" antes de fazer a restauração.
Esta opção pode ser adicionada também ao comando para fazer o backup completo das bases de dados, facilitando assim sua restauração:
# mysqldump --add-drop-table -u root -p -x -e -A > backup.sql
O backup poderia ser então restaurado diretamente usando o comando abaixo, sem que você precisasse remover as bases e tabelas manualmente antes de iniciar a recuperação:
# mysql -u root -p < backup.sql
O backup usando o mysqldump e a restauração usando o mysql são preferíveis à cópia manual dos arquivos da pasta "/var/lib/mysql", pois evita problemas de incompatibilidade ao migrar os dados para versões diferentes do MySQL. Além disso, a facilidade de fazer o backup sem precisar parar o servidor é uma grande vantagem em um ambiente de produção.
