Backup do MySQL sem precisar parar o serviço

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, como vimos na dica de ontem, 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: Link

Anúncios

~ por 3c0linux em julho 28, 2010.

 
%d blogueiros gostam disto: