De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.

Escrevendo scripts de backup

Colaboração: Carlos E. Morimoto

Data de Publicação: 03 de Outubro de 2005

Durante a década de 70, vários utilitários foram desenvolvidos para fazer backup de arquivos armazenados em servidores Unix. 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. 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 (para servidores) e o Konserve (um utilitários mais simples, voltado para usuários domésticos). 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 penetração relativamente pequena. A maior parte dos backups ainda são feitos através de scripts personalizados, escritos pelo próprio administrador. E, novamente, estes scripts utilizam o tar, gzip, rsync e outros.

É justamente sobre estes scripts personalizados que vou falar aqui. Vamos começar com alguns exemplos simples:

Para compactar o conteúdo de uma pasta, usamos o tar combinado com o gzip ou bzip2. O tar agrupa os arquivos e o gzip 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 parta é 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; a invés de z usamos j:

 $ tar -jcvf arquivos.tar.bz2 arquivos/

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 num 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 feitos em arquivos separados e sejam guardados por um certo período, de forma que seja possível recuperar um arquivo qualquer a partir da 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. O comando date retorna a data e hora atual, como em Sex Set 16 12:36:06 BRST 2005. A saída padrão dele não é muito adequada para usar em nomes de arquivos, por isso usamos as opções para alterar o formato de saída, de forma que o resultado seja 2005-09-16-12.37 (ano, mês, dia, hora, minuto, segundo). 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, sem a possibilidade de dois arquivos saírem com o mesmo nome.

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.

Em primeiro lugar, salve os comandos num arquivo de texto, que vamos chamar de backup.sh e transforme-o num executável usando o comando chmod +x backup.sh.

Para que ele seja executado automaticamente todos os dias, copie-o para dentro da pasta /etc/cron.daily e certifique-se que o serviço cron esteja ativo:

# cp -a backup-sh /etc/cron.daily
# /etc/init.d/cron start

Se preferir que o script seja executado apenas uma vez por semana, ou mesmo uma vez por hora, use as pastas /etc/cron.weekly ou a /etc/cron.hourly. Por padrão, os scripts dentro da pasta /etc/cron.daily são executados pouco depois das 6 da manhã (o horário exato varia de acordo com a distribuição), para alterar o horário, edite o arquivo /etc/crontab, alterando a linha:

 25 6 * * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily

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.

Neste 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 pasta automaticamente.

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 simples é simplesmente 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:

#!/bin/bash
mount /dev/sda1 /mnt/sda1
montado=`mount | grep /mnt/sda1`

if [ -z "$montado" ]; then
  exit 1
else
  DATA=`date +%Y-%m-%d-%H.%M`
  cd /mnt/backup
  tar -zcvf trabalho-"$DATA".tar.gz /mnt/hda6/trabalho/
  umount /mnt/sda1
fi

A partir daí, sempre que você deixar o HD externo plugado no final do expediente, o backup é feito e estará pronto no outro dia. Se esquecer de plugar o HD num dia, o script percebe e não faz nada.

Se preferir que o script grave o backup num DVD, ao invés de simplesmente salvar numa pasta, você pode usar o growisofs para gravá-lo no DVD. Neste caso, vamos gerar o arquivo numa pasta temporária e deletá-lo depois da gravação:

#!/bin/bash
DATA=`date +%Y-%m-%d-%H.%M`
rm -rf /tmp/backup; mkdir /tmp/backup; cd /tmp/backup
tar -zcvf trabalho-"$DATA".tar.gz /mnt/hda6/trabalho/
growisofs -speed=2 -Z /dev/dvd -R -J /tmp/backup/trabalho-"$DATA".tar.gz
rm -rf /tmp/backup

O -speed=2 permite que você especifique a velocidade de gravação do DVD, o -Z cria uma nova seção no DVD, é possível usar o mesmo disco para gravar vários backups (se o espaço permitir) usando a opção -M 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 Joliet.

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.

Outro grande aliado na hora de programar backups é o rsync. 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 num 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:

 $ 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.

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. Adicionando uma barra, como em /mnt/hda6/trabalho/, o rsync copiaria o conteúdo interno da pasta diretamente para dentro da /mnt/backup.

Se algum desastre acontecer e você precisar recuperar os dados, basta inverter a ordem das pastas no comando, como em:

 $ rsync -av /mnt/backup/trabalho /mnt/hda6/trabalho/

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 é a 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 -C -l tux" /mnt/hda6/trabalho \
tux@192.168.0.1:/mnt/backup/

Veja que foi adicionado um parâmetro adicional, o --rsh="ssh -C -l tux", que orienta o rsync a utilizar o SSH como meio de transporte. O -C orienta o SSH a comprimir todos os dados (economizando banda da rede) e a se conectar ao servidor remoto usando o login tux (-l tux). 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.

Para recuperar o backup, basta novamente inverter a ordem do comando, como em:

$ rsync -av --rsh="ssh -C -l tux" tux@192.168.0.1:/mnt/backup/ \
mnt/hda6/trabalho

Originalmente, você vai precisar fornecer a senha de acesso ao servidor cada vez que executar o comando. Ao usar o comando dentro do script de backup, você pode gerar uma chave de autenticação, tornando o login automático. Esta opção é menos segura, pois caso alguém consiga copiar a chave (o arquivo .ssh/id_rsa dentro do home do usuário), poderá ganhar acesso ao servidor.

De qualquer forma, para usar este recurso, rode o comando ssh-keygen -t rsa (que gera a chave de autenticação) usando o login do usuário que executará o script de backup, deixando a passphrase em branco. Em seguida, copie-o para o servidor, usando o comando:

 $ ssh-copy-id -i ~/.ssh/id_rsa.pub tux@192.168.0.1

A partir daí, o script de backup pode ser executado diretamente, através do cron, pois não será mais solicitada a senha.