Em outra dica, sobre backup de servidores, mostrei como fazer um backup das bases de dados do MySQL salvando diretamente o conteúdo da pasta “/var/lib/mysql”. 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.
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 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 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 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 arquiv 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 Fonte: http://www.guiadohardware.net/dicas/backup-mysql.html
