Fonte:http://www.guiadohardware.net/tutoriais/backup/
http://www.guiadohardware.net/tutoriais/backup2/Os backups são uma parte importante da administração de qualquer servidor. Diferente de um desktop, onde você pode simplesmente fazer uma imagem do HD usando o partimage ou outro programa similar, em uma servidor os backups precisam, quase sempre, serem feitos com o servidor em operação, sem atrapalharem o acesso dos usuários. O nível de dificuldade também é um pouco maior, já que além de arquivos e pastas, é necessário salvar também arquivos de configuração, bases de dados do MySQL e assim por diante.
Por mais confiável que seja a máquina, desastres acontecem, sem falar na possibilidade de erro humano. Sem backups regulares, é apenas questão de tempo até que você tenha problemas e perca dados importantes.
Em resumo, as principais pastas com as quais você precisa se preocupar ao fazer backup do servidor são:
/var/www: Em um servidor web, a pasta com as páginas é sempre o diretório mais importante, já que é nele que ficarão a maior parte dos arquivos dos usuários.
/var/lib/mysql: Este é o diretório padrão das bases de dados do MySQL, que em muitos casos são tão ou mais importantes que as pastas dos sites propriamente ditos. Embora seja associado ao uso em servidores web, o MySQL pode ser usado para os mais diversos tipos de tarefas.
/home: Se você configurou os virtual hosts do Apache para utilizarem pastas dentro dos diretórios home dos usuários, a pasta home assume o posto de diretório essencial, no lugar da pasta /var/www. O home também é importante caso seja usado para armazenar o spool de e-mails, no caso de servidores de arquivos ou em servidores de acesso remoto (como no caso do LTSP).
/etc: É importante que você faça também backup das configurações do servidor, concentradas na pasta "/etc", caso contrário, você vai passar maus bocados tentando se lembrar das configurações, contas de usuários e outras informações ao reconfigurar o servidor após algum desastre. :)
/var/log: Os logs do sistema também são importantes. Em muitos casos existem normas administrativas ou até mesmo normas legais que tornam obrigatório manter os logs de acesso por longos períodos, daí a necessidade de incluí-los no backup.
Além dos diretórios de dados do sistema, é importante que você tome nota de todas as partições montadas em diretórios fora das pastas principais do sistema que sejam usadas para armazenar arquivos, além de outras pastas que você utilize para guardar dados ou configurações.
Depois de definidos os diretórios a incluir no backup, falta definir que tipo de mídia utilizar.
Antigamente, as unidades de fita eram as mais utilizadas para backup de grandes volumes de dados. As principais vantagens das unidades de fita eram a grande capacidade, combinada com a boa confiabilidade e um custo por megabyte relativamente baixo. Temos aqui uma IBM 7329 SLR100, uma unidade SCSI antiga, que utiliza fitas de 50 GB, com um carregador automático com capacidade para 8 fitas, totalizando 400 GB. O "100" no nome indica a capacidade estimada levando em conta um fator de compressão de 2:1, que dependia dos tipos de arquivos incluídos no backup e que, naturalmente, nem sempre era atingido:
Utilitários como o tar foram originalmente desenvolvidos para facilitarem os backups em fita, gerando um único arquivo contendo todos os dados, que era então gravado na fita de forma sequencial. Para salvar um backup da pasta "/var/www" em uma unidade de fita detectada pelo sistema como "/dev/st0", apenas empacotando os arquivos (sem comprimir), você usaria o comando:
# tar -cvf /dev/st0 /var/www
Isso seria prático enquanto você pudesse armazenar os backups diários em uma única fita, ou caso você utilizasse uma unidade com um carregador automático. É possível dividir o backup em vários volumes e salvá-lo em fitas separadas, mas isso torna o processo extremamente imprático, sem falar que os custos se multiplicam junto com o número de fitas necessárias.
Hoje em dia, existem unidades de fita com mídias de até 800 GB reais (ou 1.6 TB comprimidos), como a Tandberg LTO-4 FH (que custa, em julho de 2008, nada menos do que US$ 4500, mais o custo das fitas), entretanto, elas são bastante caras, o que torna os HDs uma opção muito mais atrativa, já que já existem no mercado HDs de 1 TB a preços competitivos.
Surge então a figura do NAS, um servidor de arquivos dedicado, que freqüentemente utiliza vários HDs em RAID de forma a obter a capacidade necessária. Além das inúmeras opções de produtos comerciais, você pode montar seu próprio NAS usando um PC com Linux. Ao utilizar um NAS, ou outro tipo de servidor de armazenamento, os backups tornam-se mais simples, pois podem ser feitos via rede. Com isso, todo o trabalho manual de trocar as fitas de armazenamento, ou plugar e desplugar HDs externos é eliminado e os backups podem se tornar um processo inteiramente automatizado.
Existem também os casos em que o volume de dados a armazenar é pequeno, o que torna viável utilizar DVDs ou mesmo CD-ROMs para realizar os backups. A vantagem nesse caso é que as mídias são baratas e você pode simplesmente queimar uma nova mídia a cada backup, armazenando todas as cópias antigas. Os CDs e DVDs possuem também uma boa longevidade; mídias de boa qualidade, armazenadas em um ambiente sem luz e com baixa umidade duram cerca de 20 anos ou, em muitos casos, até mais.
Durante a década de 70, vários utilitários foram desenvolvidos para fazer backup de arquivos armazenados em servidores Linux. Os computadores da época eram muito limitados, por isso os utilitários precisavam ser simples e eficientes, e deveriam existir meios de agendar os backups para horários de pouco uso das máquinas.
Sugiram então utilitários como o tar e o gzip e, mais tarde, ferramentas como o rsync. Estes utilitários eram tão eficientes que continuaram sendo usados ao longo do tempo e, por incrível que possa parecer, são usados sem grandes modificações até os dias hoje.
Naturalmente, existem muitos utilitários amigáveis de backup, como o Amanda (http://sourceforge.net/projects/amanda/), mas, internamente, eles continuam utilizando como base o o dump, tar, gzip e outros trigenários. Mais incrível ainda é que estes utilitários possuem uma base de usuários relativamente pequena. A maior parte dos backups ainda é feita através de scripts personalizados, escritos pelo próprio administrador. E, novamente, estes scripts utilizam o tar, gzip, rsync e outros. Vamos começar com alguns exemplos simples:
Para compactar o conteúdo de uma pasta, usamos o tar combinado com o gzip ou o bzip2. O tar agrupa os arquivos e o gzip/bzip2 os compacta. Os arquivos compactados com o gzip usam por padrão a extensão "tar.gz", enquanto os compactados com o bzip2 usam a extensão "tar.bz2". O bzip2 é mais eficiente (chega a obter 10% ou mais de compressão adicional) mas em compensação é bem mais pesado: demora cerca de 3 vezes mais para compactar os mesmos arquivos. Você escolhe entre um e outro de acordo com a tarefa.
O comando para compactar uma pasta é similar ao "tar -zxvf" que usamos para descompactar arquivos. Para compactar a pasta "arquivos/", criando o arquivo "arquivos.tar.gz", o comando seria:
$ tar -zcvf arquivos.tar.gz arquivos/
O "c" indica que o tar deve criar um novo arquivo e o "v" faz com que exiba informações na tela enquanto trabalha. Se preferir comprimir em bz2, muda apenas a primeira letra; ao invés de "z" usamos "j":
$ tar -jcvf arquivos.tar.bz2 arquivos/
Para descompactar o arquivo posteriormente, trocamos a opção "c" por "x", como em:
$ tar -jxvf arquivos.tar.bz2
Como não indicamos uma pasta de destino, o arquivo será simplesmente descompactado na pasta atual. Se o arquivo não é muito grande ou se o espaço em disco não é problema, você pode simplesmente descompactar o arquivo dentro da sua pasta home, ou em outro diretório com espaço suficiente disponível e copiar manualmente os arquivos desejados para a pasta de destino. Essa acaba sendo a opção mais segura, já que você tem mais tempo para revisar tudo e ter certeza de que não está substituindo arquivos por versões antigas.
Você pode também descompactar o arquivo diretamente na pasta desejada. Imagine que você fez anteriormente o backup da pasta "/var/www/site", gerando o arquivo "site.tar.gz", usando os comandos:
# cd /var/www
# tar -zcvf /mnt/sdb1/backups/site.tar.gz site
Nesse caso, o arquivo contém a pasta "site/" e todo o seu conteúdo. Para restaurá-lo posteriormente, diretamente no destino, você usaria:
# cd /var/www
# tar -zxvf /mnt/sdb1/backups/site.tar.gz
Como o comando é executado diretamente dentro da pasta "/var/www/", os arquivos são restaurados diretamente na pasta "site". Usado desta forma, o tar subscreve os arquivos da pasta de destino sem pedir confirmação, por isso tenha cautela ao usá-lo. É muito fácil errar o diretório e restaurar os arquivos na pasta errada, ou especificar o arquivo incorreto e subscrever o conteúdo da pasta pelo de um backup antigo.
Continuando, um dos grandes problemas em utilizar arquivos compactados é que é muito difícil recuperar o conteúdo do arquivo caso ele seja corrompido por qualquer motivo (um badblock no HD, ou um erro durante a transferência, por exemplo). Diferente de em uma pasta com diversos arquivos, onde um ou mais badblocks apenas fariam com que alguns dos arquivos ficassem danificados, erros em um arquivo compactado podem comprometer todo o seu conteúdo.
Tendo isso em mente, é saudável verificar os backups depois de copiá-los para a mídia de destino, o que pode ser feito usando o próprio tar. Nesse caso, usamos a opção "-tf", que faz com que ele liste o conteúdo do arquivo, como em:
$ tar -tf arquivos.tar.bz2
Isso obrigará o tar a abrir o arquivo e listar seu conteúdo. Se houver qualquer erro durante o processo, ele exibirá uma mensagem de erro, alertando sobre o problema.
Estes comandos seriam ideais para fazer um backup completo de uma ou várias pastas do sistema, gerando um arquivo compactado que poderia ser armazenado num HD externo, gravado em um DVD ou mesmo transferido via rede para outro servidor.
Imagine agora um outro cenário, onde você precisa fazer backup dos arquivos de uma pasta de trabalho diariamente. Os arquivos gerados não são muito grandes e você tem muito espaço disponível, mas é necessário que os backups diários sejam feitos em arquivos separados e sejam guardados por um certo período, de forma que seja possível recuperar um arquivo qualquer a partir do backup feito em uma determinada data.
Ao invés de ficar renomeando os arquivos, você poderia usar um pequeno script para que os arquivos fossem gerados já com a data e hora incluída no nome do arquivo:
DATA=`date +%Y-%m-%d-%H.%M`
cd /mnt/backup
tar -zcvf trabalho-"$DATA".tar.gz /mnt/hda6/trabalho/
A primeira linha do script cria uma variável "DATA", contendo o resultado do comando "date +%Y-%m-%d-%H.%M.%S" (os caracteres "`" usados no comando são crases). O comando date retorna a data e hora atual, como em "Qua Jul 2 10:23:46 BRT 2008". A saída padrão não é muito adequada para usar em nomes de arquivos, por isso usamos as opções para alterar o formato de saída, de modo que o resultado seja "2008-07-02-10.23" (ano, mês, dia, hora, minuto). Usamos este valor no nome do arquivo com o backup, de forma que, cada vez que você chame o script, seja gerado um arquivo com a data e hora em que foi gerado.
O próximo passo é fazer com que este script de backup seja executado diariamente, de forma automática, o que pode ser feito usando o cron, que apresentei na dica anterior: http://www.guiadohardware.net/dicas/cron.html
Em primeiro lugar, salve os comandos em um arquivo de texto, que vamos chamar de "script-backup" e transforme-o em executável:
# chmod +x script-backup
Para que o script seja executado automaticamente todos os dias, edite o arquivo "/etc/crontab" adicionando uma nova linha, especificando o horário em que o script será executado, o login sob o qual ele será executado (para simplificar as coisas, você pode utilizar o próprio root) e a localização do script, como em:
25 6 * * * root /usr/local/bin/script-backup
O "25 6" indica o minuto e a hora. Se quiser que o script seja executado às 11 da noite, por exemplo, mude para "00 23". As alterações feitas no arquivo são lidas automaticamente pelo cron, de forma que não é necessário reiniciar o serviço. Se quiser verificar se o cron está mesmo ativo, use o comando "ps aux | grep cron", que deverá retornar algo similar a: "root 2002 0.0 0.1 2280 848 ? Ss Jun30 0:00 /usr/sbin/cron".
Nesse primeiro exemplo, usei a pasta "/mnt/backup" para salvar os arquivos. Esta pasta pode ser o ponto de montagem de um HD externo ou de um compartilhamento de rede, por exemplo. O seu script pode conter os comandos necessários para montar e desmontar a partição automaticamente, além de executar operações diversas definidas por você.
Imagine, por exemplo, que o backup é sempre feito na primeira partição de um HD externo, ligado na porta USB, que é sempre detectada pelo sistema como "/dev/sda1". O script deve ser capaz de montar a partição, gravar o arquivo de backup e depois desmontá-la. Se, por acaso, o HD não estiver plugado, o script deve abortar o procedimento.
Para isso, precisamos verificar se o HD realmente foi montado depois de executar o comando "mount /dev/sda1 /mnt/sda1". Existem muitas formas de fazer isso, uma das mais simples é filtrar a saída do comando "mount" (que mostra todos os dispositivos montados) usando o grep para ver se o "/mnt/sda1" aparece na lista. Se não estiver, o script termina, caso esteja, ele continua, executando os comandos de backup:
mount /dev/sda1 /mnt/backup
montado=`mount | grep /mnt/backup`
if [ -z "$montado" ]; then
exit 2
else
DATA=`date +%Y-%m-%d-%H.%M`
cd /mnt/backup
tar -zcvf trabalho-"$DATA".tar.gz /mnt/hda6/trabalho/
umount /mnt/sda1
fi
Uma vez que o cron fosse configurado para executar o script diariamente, o backup passaria a ser feito automaticamente sempre que você deixasse o HD externo plugado no final do expediente. Se esquecer de plugar o HD em algum dia, o script percebe que a partição não foi montada e não faz nada.
Se preferir que o script grave o backup em um DVD, ao invés de simplesmente salvar em uma pasta, você pode usar o "growisofs" para gravá-lo na mídia. Neste caso, vamos gerar o arquivo em uma pasta temporária e deletá-lo depois da gravação:
DATA=`date +%Y-%m-%d-%H.%M`
# Sanity-check para ter certeza de que tudo está em ordem:
rm -rf /tmp/backup; mkdir /tmp/backup; cd /tmp/backup
# Gera o arquivo, grava o DVD e deleta a pasta temporária
tar -zcvf trabalho-"$DATA".tar.gz /mnt/hda6/trabalho/
growisofs -speed=2 -Z /dev/dvd -R -J /tmp/backup/trabalho-"$DATA".tar.gz
cd ../; rm -rf /tmp/backup
O "-speed=2" permite que você especifique a velocidade de gravação do DVD, enquanto o "-Z" cria uma nova seção dentro da mídia. É possível usar o mesmo disco para gravar vários backups (se o espaço permitir) adicionando a opção "-M" (logo depois do "-Z", dentro do comando) a partir da segunda gravação, que adiciona novas seções no DVD, até que o espaço se acabe.
O "/dev/dvd" indica o dispositivo do drive de DVD. A maioria das distribuições cria o link /dev/dvd apontando para o dispositivo correto, mas, em caso de problemas, você pode indicar diretamente o dispositivo correto, como, por exemplo, "/dev/hdc". As opções "-R -J" adicionam suporte às extensões RockRidge e Joilet, que oferecem (respectivamente) suporte a nomes de arquivos com mais de 8 caracteres no Linux e no Windows.
Se o cron for configurado para executar o script todos os dias, você só precisará se preocupar em deixar o DVD no drive antes de sair. Se quiser que ele faça graça, ejetando a mídia depois de terminar a gravação, adicione um "eject /dev/dvd" no final do script.
Se preferir fazer os backups em CDR, crie uma imagem ISO usando o mkisofs e em seguida grave-a no CD usando o cdrecord. Nesse caso, o comando do growisofs dentro do script seria substituído por:
mkisofs -r -J -o trabalho.iso /tmp/backup/trabalho-"$DATA".tar.gz
cdrecord dev=/dev/hdc trabalho.iso
Este comando do cdrecord funciona em distribuições recentes, que utilizam o Kernel 2.6 em diante (com o módulo ide-cd). No Kernel 2.4, era usada emulação SCSI para acessar o gravador de CD, fazendo com que ele fosse visto e acessado pelo sistema como se fosse um gravador SCSI. Nesse caso, o comando de gravação seria "cdrecord dev=0,0,0 -data arquivo.iso", onde o "0,0,0" é o dispositivo do gravador, que você descobriria usando o comando "cdrecord -scanbus".
Outra pequena observação é que nas distribuições derivadas do Debian o cdrecord é substituído pelo wodim, um fork do projeto que desempenha a mesma função. Nelas, você recebe um "bash: cdrecord: command not found" ao executar o comando, já que o nome do arquivo é diferente. Você pode resolver o problema de forma simples criando um link:
# ln -s /usr/bin/wodim /usr/bin/cdrecord
Outra boa opção seria salvar os backups em um servidor externo, de preferência um servidor remoto, situado em outro estado ou em outro país. Usar dois servidores em locais diferentes elimina a possibilidade de algum tipo de desastre (como um incêndio ou uma inundação) destruir tanto o servidor quanto os backups.
Uma forma simples de fazer com que o script consiga transferir os arquivos automaticamente no final do processo é utilizar um par de chaves do SSH sem passphrase, o que permite que o script transfira arquivos usando o comando "scp", sem precisar lhe pedir a senha ou a passphrase de acesso ao realizar cada cópia. Essa opção é um pouco menos segura do que usar chaves protegidas por uma passphrase, já que caso alguém consiga obter acesso ao arquivo ".ssh/id_rsa" dentro no home do usuário, poderá obter acesso ao servidor. Entretanto, em muitas situações este é um risco aceitável, principalmente se o backup é feito diretamente entre dois servidores protegidos. Além do mais, o risco é reduzido caso você utilize uma conta limitada no segundo servidor.
O primeiro passo seria criar um usuário no segundo servidor, que será usado para permitir o acesso do script. Aproveite para já ajustar o diretório home, especificando a pasta que será usada para armazenar os backups, como em:
# adduser --home /mnt/sdb1/backups bkuser
Em seguida, criamos o par de chaves que será usado para o acesso no primeiro servidor usando o comando "ssh-keygen -t rsa". Ele deve ser executado usando o usuário que será usado para executar o script de backup. Se ele for ser executado pelo root, então o comando é também executado como root:
# ssh-keygen -t rsa
Como a idéia é criar uma chave que possa ser usada para login automático, simplesmente pressione Enter quando o ssh-keygen perguntar pela passphrase, deixando-a em branco.
O próximo passo é instalar a chave gerada no segundo servidor (o "backup.gdhn.com.br" no exemplo), usando o comando "ssh-copy-id", especificando o usuário criado no passo anterior e o endereço do segundo servidor, como em:
# ssh-copy-id -i ~/.ssh/id_rsa.pub bkuser@backup.gdhn.com.br
Com isso, o primeiro servidor passa a ter acesso direto ao segundo através do usuário "bkuser" (especificado no comando), que usaremos para transferir os arquivos através do scp. Você pode fazer um teste transferindo um arquivo qualquer do primeiro servidor para o segundo, como em:
# scp arquivo.tar.gz bkuser@backup.gdhn.com.br:/mnt/sdb1/backups/
Você perceberá que o comando será executado diretamente, sem pedir senha. O próximo passo é adicionar o comando para transferir o arquivo no seu script de backup, como neste exemplo:
#!/bin/sh
DATA=`date +%Y-%m-%d-%H.%M`
cd /mnt/backup
tar -zcvf www-$DATA.tar.gz /var/www
scp www-$DATA.tar.gz bkuser@backup.gdhn.com.br:/mnt/sdb1/backups/
rm -f www-$DATA.tar.gz
Com isso, o script gera o arquivo com o backup, copia para o segundo servidor via scp e, depois de concluída a transferência, deleta a cópia local do arquivo, de forma que elas não se acumulem até acabar com o espaço em disco.
O passo final seria automatizar a execução do script, adicionando uma entrada no arquivo "/etc/crontab" (do primeiro servidor), como em:
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 um novo arquivo com a data de quando foi executado e copiando-o para o segundo servidor, onde os backups ficarão arquivados.
Outro grande aliado na hora de programar backups é orsync. Ele permite sincronizar o conteúdo de duas pastas, transferindo apenas as modificações. Ele não trabalha apenas comparando arquivo por arquivo, mas também comparando o conteúdo de cada um. Se apenas uma pequena parte do arquivo foi alterada, o rsync transferirá apenas ela, sem copiar novamente todo o arquivo.
Ele é uma forma simples de fazer backups incrementais de grandes quantidades de arquivos, ou mesmo partições inteiras, mantendo uma única cópia atualizada de tudo em um HD externo ou num servidor remoto. Este backup incremental pode ser atualizado todo dia e complementado por um backup completo (para o caso de um desastre acontecer), feito uma vez por semana ou uma vez por mês.
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.
