Neste artigo vou relatar uma experi\u00eancia que tive na empresa onde trabalho e como encontrei a sa\u00edda para o problema. Vou explicar detalhadamente como fazer um backup completo do disco em outro HD, de uma forma t\u00e3o f\u00e1cil que dispensa at\u00e9 mesmo montar o outro hd. A c\u00f3pia \u00e9 completa, feita cluster por cluster e isso faz com que em caso de problemas, apenas uma troca de HD resolva a situa\u00e7\u00e3o.<\/p>\n
No VOL podemos encontrar in\u00fameros artigos sobre backup e espelhamento. O exemplo que falarei neste artigo n\u00e3o \u00e9 melhor do que nenhum outro, ele apenas descreve uma situa\u00e7\u00e3o particular, onde encontrei uma sa\u00edda r\u00e1pida e f\u00e1cil de obter o resultado desejado.<\/p>\n
A situa\u00e7\u00e3o \u00e9 a seguinte: Tenho um servidor Fedora, no qual roda um sistema gigantesco (infelizmente em Windows) que ret\u00e9m todos os dados de uma rede de concession\u00e1rias. O sistema \u00e9 de dif\u00edcil instala\u00e7\u00e3o e tem uma s\u00e9rie de configura\u00e7\u00f5es no firewall que s\u00e3o peculiares deste sistema. S\u00f3 de pensar em instalar este sistema “do zero” ou restaurar uma c\u00f3pia de seguran\u00e7a, j\u00e1 d\u00e1 uma dor de cabe\u00e7a.<\/p>\n
Al\u00e9m disso, neste mesmo servidor, temos arquivos usados diariamente por todos os funcion\u00e1rios, como planilhas, pequenos bancos de dados, aplicativos, documentos, etc. Pra completar ainda mais a import\u00e2ncia deste servidor, ele autentica todos os usu\u00e1rios da rede e n\u00e3o s\u00e3o poucos.<\/p>\n
Um das alternativas que eram usadas quando assumi a manuten\u00e7\u00e3o das lojas era o backup em DVD dos dados, das planilhas e dos arquivos de configura\u00e7\u00e3o do samba. Tudo bem at\u00e9 o dia que tivemos problema em um HD e pra completar haviam esquecido de gravar o backup no DVD por tr\u00eas dias. Por sorte ainda consegui entrar no HD e clon\u00e1-lo para um novo, mas se tivesse que instalar do zero, teria que baixar uma vers\u00e3o do Fedora (que \u00e9 exig\u00eancia do sistema), instalar do zero e restaurar os dados. Al\u00e9m disso, deveria descompactar todas as planilhas e coloc\u00e1-la em seus devidos locais, mas o pior seria a autentica\u00e7\u00e3o dos usu\u00e1rios.<\/p>\n
Nos \u00faltimos dias deste backup, ainda tive que escolher alguns arquivos que n\u00e3o fariam parte do backup, pois um DVD de 8GB j\u00e1 estava pequeno. A situa\u00e7\u00e3o era assustadora.<\/p>\n
Quero enfatizar que, no meu caso trata-se de um backup de um servidor, cujo sistema \u00e9 cheio de peculiaridades e foi instalado por terceiros. N\u00e3o h\u00e1 nenhum treinamento ou tutorial informando as configura\u00e7\u00f5es necess\u00e1rias, portanto, estou trabalhando com um servidor do qual n\u00e3o conhe\u00e7o sua estrutura e devo obedecer a padr\u00f5es, necessidades e configura\u00e7\u00f5es estabelecidas por outros administradores de rede.<\/p>\n
Procurei uma solu\u00e7\u00e3o na qual n\u00e3o fosse necess\u00e1rio conhecer o servidor completamente e que me desse o menor trabalho poss\u00edvel para colocar o sistema no ar novamente em caso de uma pane.<\/p>\n
Tive ent\u00e3o a id\u00e9ia de clonar o HD completamente, com suas parti\u00e7\u00f5es e sistema de arquivos completos. Para implantar esta id\u00e9ia escolhi o comando dd, por ser simples e f\u00e1cil.<\/p>\n
Coloquei ent\u00e3o os dois HDs de 500GB no mesmo servidor, e criei um script para clonar diariamente os dados de um HD para outro. Na hip\u00f3tese de um problema no HD principal, bastava trocar pelo HD de backup e nada estava perdido, nem mesmo as parti\u00e7\u00f5es com seus tamanhos e sistemas de arquivo.<\/p>\n
Vou demonstrar detalhadamente como fazer este tipo de backup.<\/p>\n<\/div>\n
Vamos partir do princ\u00edpio de que voc\u00ea j\u00e1 conectou os dois HDs. Neste exemplo, o HD sata que j\u00e1 est\u00e1 instalado e funcionando \u00e9 o \/dev\/sda. Portanto, o segundo HD sata deve ser o \/dev\/sdb.<\/p>\n
Esta alternativa de backup \u00e9 t\u00e3o f\u00e1cil que n\u00e3o \u00e9 necess\u00e1rio nem montar o segundo HD.<\/p>\n
Vamos criar ent\u00e3o o script que far\u00e1 toda a tarefa de backup. Ele dever\u00e1 ter as linhas abaixo, exatamente como est\u00e3o:<\/p>\n
——————————————-<\/p>\n
Al\u00e9m de fazer o backup, este script de apenas duas linhas cria um log que guarda um hist\u00f3rico de todos os backups efetuados, com tempo de in\u00edcio e t\u00e9rmino, sendo ideal para consultas futuras e para o acompanhamento di\u00e1rio.<\/p>\n
A primeira linha #!\/bin\/sh define o interpretador que ser\u00e1 chamado. \u00c9 praticamente padr\u00e3o para a maior parte dos scripts execut\u00e1veis.<\/p>\n
A segunda linha tem v\u00e1rios comandos juntos.<\/p>\n
O comando date >> historico.log grava a data de in\u00edcio do backup no arquivo hist\u00f3rico.log.<\/p>\n
Os caracteres && servem para executar o pr\u00f3ximo comando somente ap\u00f3s terminar o anterior, ou seja, s\u00f3 come\u00e7ar o backup ap\u00f3s gravar a data no arquivo.<\/p>\n
O comando dd cria uma c\u00f3pia do HD de origem if=\/dev\/sda para o HD de destino of=\/dev\/sdb.<\/p>\n
O comando date >> historico.log repetido ap\u00f3s a c\u00f3pia dos HDs, serve para gravar a data de t\u00e9rmino da c\u00f3pia.<\/p>\n<\/div>\n
Como enfatizei no in\u00edcio, n\u00e3o defendo esta alternativa de backup como a melhor ou muito menos como a \u00fanica que se adequa a este caso. Esta alternativa foi a que usei em meio a tantas outras op\u00e7\u00f5es e sei que sua aplica\u00e7\u00e3o s\u00f3 \u00e9 vi\u00e1vel numa situa\u00e7\u00e3o como a que ilustrei no in\u00edcio. Em outros casos s\u00e3o aconselhados espelhamentos simult\u00e2neos, ou apenas backups dos arquivos importantes.<\/p>\n
As \u00fanicas desvantagens que vejo neste backup s\u00e3o que ela n\u00e3o oferece nenhuma op\u00e7\u00e3o de progresso, como uma barra que indique o quanto ainda falta para terminar o processo e a outra \u00e9 que demora muito. Um HD sata de 80GB demora 2 horas.<\/p>\n
A grande vantagem \u00e9 que a c\u00f3pia \u00e9 feita id\u00eantica ao HD de origem, com sistema de arquivos, parti\u00e7\u00f5es, etc. Em caso de um problema, basta substituir um HD pelo outro e pronto. As outras vantagens s\u00e3o a facilidade, afinal, n\u00e3o precisa nem montar a parti\u00e7\u00e3o do novo HD e nem reinstalar todo o sistema com m\u00e9todos de espelhamentos complexos, al\u00e9m de ser tudo automatizado, sem a possibilidade de esquecimentos dos usu\u00e1rios.<\/p>\n
Vale lembrar tamb\u00e9m, que pelo fato da c\u00f3pia ser feita cluster por cluster, o HD de destino deve ser maior ou de mesmo tamanho do HD de origem.<\/p>\n
Agrade\u00e7o a quem puder contribuir com relatos de experi\u00eancias pr\u00f3prias, ou com outras alternativas a esta situa\u00e7\u00e3o. Agrade\u00e7o tamb\u00e9m a quem puder enriquecer este artigo com dicas, coment\u00e1rios, cr\u00edticas ou sugest\u00f5es.<\/p>\n
O comando echo “###########” >> historico.log serve apenas para colocar caracteres delimitadores para separar as datas de um dia para outro. Pode n\u00e3o parecer t\u00e3o \u00fatil, mas quando tivermos um arquivo com mais de um m\u00eas de hist\u00f3ricos, estes caracteres far\u00e3o diferen\u00e7a no visual da an\u00e1lise.<\/p>\n
Para que este script possa ser executado \u00e9 necess\u00e1ria a linha de comando abaixo. Ela n\u00e3o s\u00f3 transforma em execut\u00e1vel, como d\u00e1 permiss\u00e3o para qualquer usu\u00e1rio executar o arquivo.<\/p>\n
$ chmod a=rwx nome_do_script<\/b><\/p>\nAgendando a execu\u00e7\u00e3o di\u00e1ria do script<\/h1>\n
No meu caso, usei um agendamento di\u00e1rio, de madrugada, onde n\u00e3o havia nenhuma atividade na empresa. Agendei para as 23:00 todos os dias.<\/p>\n
Para abrir o crontab para edi\u00e7\u00e3o use:<\/p>\n
$ crontab -e<\/b><\/p>\n
Para agendar a execu\u00e7\u00e3o digite a seguinte linha no crontab:<\/p>\n