Entendendo a situação e a necessidade

No VOL podemos encontrar inúmeros artigos sobre backup e espelhamento. O exemplo que falarei neste artigo não é melhor do que nenhum outro, ele apenas descreve uma situação particular, onde encontrei uma saída rápida e fácil de obter o resultado desejado.

A situação é a seguinte: Tenho um servidor Fedora, no qual roda um sistema gigantesco (infelizmente em Windows) que retém todos os dados de uma rede de concessionárias. O sistema é de difícil instalação e tem uma série de configurações no firewall que são peculiares deste sistema. Só de pensar em instalar este sistema “do zero” ou restaurar uma cópia de segurança, já dá uma dor de cabeça.

Além disso, neste mesmo servidor, temos arquivos usados diariamente por todos os funcionários, como planilhas, pequenos bancos de dados, aplicativos, documentos, etc. Pra completar ainda mais a importância deste servidor, ele autentica todos os usuários da rede e não são poucos.

Um das alternativas que eram usadas quando assumi a manutenção das lojas era o backup em DVD dos dados, das planilhas e dos arquivos de configuração do samba. Tudo bem até o dia que tivemos problema em um HD e pra completar haviam esquecido de gravar o backup no DVD por três dias. Por sorte ainda consegui entrar no HD e cloná-lo para um novo, mas se tivesse que instalar do zero, teria que baixar uma versão do Fedora (que é exigência do sistema), instalar do zero e restaurar os dados. Além disso, deveria descompactar todas as planilhas e colocá-la em seus devidos locais, mas o pior seria a autenticação dos usuários.

Nos últimos dias deste backup, ainda tive que escolher alguns arquivos que não fariam parte do backup, pois um DVD de 8GB já estava pequeno. A situação era assustadora.

Quero enfatizar que, no meu caso trata-se de um backup de um servidor, cujo sistema é cheio de peculiaridades e foi instalado por terceiros. Não há nenhum treinamento ou tutorial informando as configurações necessárias, portanto, estou trabalhando com um servidor do qual não conheço sua estrutura e devo obedecer a padrões, necessidades e configurações estabelecidas por outros administradores de rede.

A solução adotada

Procurei uma solução na qual não fosse necessário conhecer o servidor completamente e que me desse o menor trabalho possível para colocar o sistema no ar novamente em caso de uma pane.

Tive então a idéia de clonar o HD completamente, com suas partições e sistema de arquivos completos. Para implantar esta idéia escolhi o comando dd, por ser simples e fácil.

Coloquei então os dois HDs de 500GB no mesmo servidor, e criei um script para clonar diariamente os dados de um HD para outro. Na hipótese de um problema no HD principal, bastava trocar pelo HD de backup e nada estava perdido, nem mesmo as partições com seus tamanhos e sistemas de arquivo.

Vou demonstrar detalhadamente como fazer este tipo de backup.

Metendo a mão na massa!

Vamos partir do princípio de que você já conectou os dois HDs. Neste exemplo, o HD sata que já está instalado e funcionando é o /dev/sda. Portanto, o segundo HD sata deve ser o /dev/sdb.

Esta alternativa de backup é tão fácil que não é necessário nem montar o segundo HD.

Criando o script

Vamos criar então o script que fará toda a tarefa de backup. Ele deverá ter as linhas abaixo, exatamente como estão:

——————————————-

“Destroçando” o script

Além de fazer o backup, este script de apenas duas linhas cria um log que guarda um histórico de todos os backups efetuados, com tempo de início e término, sendo ideal para consultas futuras e para o acompanhamento diário.

A primeira linha #!/bin/sh define o interpretador que será chamado. É praticamente padrão para a maior parte dos scripts executáveis.

A segunda linha tem vários comandos juntos.

O comando date >> historico.log grava a data de início do backup no arquivo histórico.log.

Os caracteres && servem para executar o próximo comando somente após terminar o anterior, ou seja, só começar o backup após gravar a data no arquivo.

O comando dd cria uma cópia do HD de origem if=/dev/sda para o HD de destino of=/dev/sdb.

O comando date >> historico.log repetido após a cópia dos HDs, serve para gravar a data de término da cópia.

Considerações finais sobre este backup

Como enfatizei no início, não defendo esta alternativa de backup como a melhor ou muito menos como a única que se adequa a este caso. Esta alternativa foi a que usei em meio a tantas outras opções e sei que sua aplicação só é viável numa situação como a que ilustrei no início. Em outros casos são aconselhados espelhamentos simultâneos, ou apenas backups dos arquivos importantes.

As únicas desvantagens que vejo neste backup são que ela não oferece nenhuma opção de progresso, como uma barra que indique o quanto ainda falta para terminar o processo e a outra é que demora muito. Um HD sata de 80GB demora 2 horas.

A grande vantagem é que a cópia é feita idêntica ao HD de origem, com sistema de arquivos, partições, etc. Em caso de um problema, basta substituir um HD pelo outro e pronto. As outras vantagens são a facilidade, afinal, não precisa nem montar a partição do novo HD e nem reinstalar todo o sistema com métodos de espelhamentos complexos, além de ser tudo automatizado, sem a possibilidade de esquecimentos dos usuários.

Vale lembrar também, que pelo fato da cópia ser feita cluster por cluster, o HD de destino deve ser maior ou de mesmo tamanho do HD de origem.

Agradeço a quem puder contribuir com relatos de experiências próprias, ou com outras alternativas a esta situação. Agradeço também a quem puder enriquecer este artigo com dicas, comentários, críticas ou sugestões.

O comando echo “###########” >> historico.log serve apenas para colocar caracteres delimitadores para separar as datas de um dia para outro. Pode não parecer tão útil, mas quando tivermos um arquivo com mais de um mês de históricos, estes caracteres farão diferença no visual da análise.

Transformando o script em executável

Para que este script possa ser executado é necessária a linha de comando abaixo. Ela não só transforma em executável, como dá permissão para qualquer usuário executar o arquivo.

$ chmod a=rwx nome_do_script

Agendando a execução diária do script

No meu caso, usei um agendamento diário, de madrugada, onde não havia nenhuma atividade na empresa. Agendei para as 23:00 todos os dias.

Para abrir o crontab para edição use:

$ crontab -e

Para agendar a execução digite a seguinte linha no crontab:

Para sair do crontab pressione a tecla ESC e depois digite :x e pressione ENTER. Após isso o agendamento já está pronto.