Recuperação de HD Seagate 7200.11

Autor: diakonov

Fonte: http://forum.clubedohardware.com.br/recuperacao-hd-seagate/696794

 

Resolvi postar esse tópico pois meu HD de 750GB da Seagate, série 7200.11 pifou por defeito do firmware dessa série e com muito esforço e ansiedade consegui reverter o dano através de fóruns da internet. Infelizmente, mesmo para as séries mais recentes de HDs de alta capacidade de todas as marcas, temos relatos terríveis de HDs morrendo depois de poucos meses de uso o que nos obriga a fazer backup de centenas de gigabytes com centenas de DVDs de 4.5Gb.

A solução que colocarei aqui foi obtida de diversos fóruns na internet, em português e em inglês, mas com partes mal explicadas e conflitantes ou faltando e por isso resolvi postar esse tópico.

Temos basicamente 2 tipos de defeitos possíveis devido ao firmware. Eu irei postar APENAS a solução que eu testei para o MEU problema específico para evitar erros. Também eu NAO garanto que esse meu procedimento dê certo, temos inúmeros relatos de erros e sucessos. Para mais informações técnicas dos defeitos consulte os links abaixo.

Os fóruns de internet pesquisados foram os seguintes:

http://www.overclock.net/hard-drives...-fix-pics.html
http://www.msfn.org/board/index.php?...128807&st=1000
http://www.guiadohardware.net/comuni...ml#post4373693
http://sites.google.com/site/seagatefix/

SUGIRO FORTEMENTE QUE você LEIA também OS FORUNS ACIMA PARA SE INFORMAR MAIS E DETECTAR EVENTUAIS DIVERGENCIAS DESSE POST COM OUTROS FORUNS. AS DIVERGENCIAS PERTINENTES EU COMENTEI DURANTE ESSE POST. CASO HAJA ALGUMA OUTRA DUVIDA, PESQUISE NOS FORUNS ANTES DE TENTAR REALIZAR ESSE PROCEDIMENTO. NÃO REALIZE ESSE PROCEDIMENTO ANTES DE TER 100% DE CERTEZA QUE COMPREENDEU TODAS AS ETAPAS.

Seguir o roteiro dos links acima apresenta inúmeras dificuldades, evitadas pelo guia que escrevo aqui. Primeiro há a dificuldade de se conseguir um conversor eletrônico Rs232-TTL no Brasil já montado certinho, segundo há discrepâncias sobre o procedimento entre os diferentes links. No final, o guia do www.msfn.org cujo link está acima é o mais confiável e completo mas não trata da solução usando um cabo de dados para celular do tipo CA-42.

Tente seguir solução postada aqui APENAS se o seu HD da seagate apresentar o seguinte defeito abaixo. Para o outro tipo de defeito, pesquise nos links acima (no total são apenas 2 tipos de defeito relacionados ao firmware da série 7200.11, e nesse guia eu trato de apenas 1 deles).

Também é importante testar se seu HDD de fato precisa de uma atualização do firmware. Veja isso no link abaixo:
http://seagate.custkb.com/seagate/cr...p?DocId=207931

O meu problema com HD da Seagate 7200.11

1) HD não é mais detectado na BIOS ao se ligar o computador, embora o HD ligue o motor dele e faça algum barulho no começo. A BIOS fica travada por um tempo e os dados do HD são inacessíveis. Isso nos outros fóruns se chama de problema do tipo BUSY. Tudo se passa como se o HDD não existisse.

-------------A Solução-----------------------------------------------

-------------Materiais necessários e onde comprar---------------------

*******Todos os endereços abaixo são de São Paulo - SP*********

1) Chave de fenda tipo TORX T6. O jogo de chave de fenda custa 20 reais e é encontrado facilmente em lojas de eletrônicos na rua Timbiras, perpendicular à R. Sta Ifigênia. É usado para desparafusar a placa verde do HD.

2) Cabo de dados para celular do tipo CA-42, você acha isso por 20 reais na rua Sta Ifigenia 261 Box 43. Ele substituirá o conversor RS232-TTL mencionado em outros fóruns. É possível também utilizar um cabo DKU-5 mas é bem mais complicado usar esse cabo porque ele tem mais fios e exige uso de multímetro para identificar a função de cada um dos fios. Recomendo fortemente comprar somente o cabo CA-42.

3) Conjunto de fios com conector MUDU na ponta (é o mesmo conector usado para conectar os botões do Gabinete na placa mãe). você pode usar os fios de um gabinete antigo ou comprar um set pronto em alguma loja. Poucas lojas vendem cabos desse tipo prontos e é irrelevante se os conectores mudu estão juntos ou separados pois iremos retirar os conectores MUDU da ponta, deixando apenas o revestimento metálico que fixa o fio ao conector MUDU. Comprei um conjunto de 3 fios prontos por 3 reais.

Fig.1 Essa foto mostra os fios com os conectores mudu

Fig. 2 Essa foto mostra os fios sem os conectores mudu

4) Soldador de 7 reais mais solda de 7 reais. É necessário para ligar os fios do cabo de dados CA-42 com os fios de conectores MUDU.

5) Fita isolante preta.

------------------------------------------------------------------------

---------------A confecção do cabo-------------------------------------

1) O cabo de dados CA-42 tem 2 pontas, uma ponta é USB que deixaremos intacta e a outra ponta é a do celular. Corte a ponta que conecta ao celular. Veja que o cabo tem 3 fios. Um deles chamaremos de RX, outro é o TY e por fim o GND (ground). Irei posteriormente explicar como identificar cada um desses fios.

2) Utilizando um estilete (não use tesoura), descasque o cabo que envolve os fios com finos cortes paralelos ao fio, até você conseguir enxergar um dos fios. A partir desse ponto, você pode com a mão puxar e cortar com uma tesoura o resto do encapamento revelando os 3 fios sem lesionar eles com o estilete. Quando os 3 fios estiverem expostos, faça um pequeníssimo corte com uma tesoura e puxe o encapamento deles para fora com a mão e unha.

3) Em seguida pegue os fios com os conectores mudu. Utilizando um estilete, é possível levantar uma fina aba do conector mudu a fim de liberar o fio preso a ele. Levante essa aba e puxe o fio gentilmente, fazendo isso com o restante dos fios, no total de 3.

4) Utilize o soldador e a solda com muito cuidado, seguindo as instruções do soldador, a fim de unir cada um fio desencapado do cabo de dados CA-42 com os fios do cabo que tinha os conectores mudu. Quando a solda esfriar, isole os fios soldados com uma fita isolante. No final, você terá 3 fios independentes devidamente soldados. Isso é importante para garantir um bom contato.

Agora iremos testar o cabo confeccionado e determinar quais terminais são RX, TY e GND.

-----------------------------------------------------------------------

-------------Testando o cabo------------------------------------------

1) Ligue o computador, conecte o cabo CA-42 no windows XP e instale os drivers necessários utilizando o cd que veio com o cabo de dados CA-42.

2) Vá ao painel de controle --> sistema ---> hardware --> gerenciador de dispositivos --> portas (COM & LPT) e ache qual porta COM está instalado o cabo CA-42.

3) Ligue o Hyperterminal (ausente no windows vista, consulte os links dos fóruns para uso de programas alternativos). Ignore as janelas que talvez apareçam clicando em ok ou cancelar. Vá em arquivos --> propriedades e escolha a porta COM correta em que está instalado o cabo CA-42. Depois vá em configurações e coloque BAUD 38400, Data BITs 0, Stop Bits 0, Parity none, Flow Control none. Clique em ok e saia da janela de configuração.

4) O objetivo agora é definir a função de cada fio, ou seja, qual fio é o RX, TY ou GND.

Quando o fio RX e TY são unidos, e algo é digitado no teclado, a janela do Hyperterminal mostra exatamente o que é escrito no teclado. Isso significa que o fio que sobrou é necessariamente o GND. Anote no papel qual fio é o GND.

Quando o fio GND encosta no fio RX caracteres estranhos aparecem na janela do Hyperterminal. Portanto sabemos qual fio é o RX. O fio que sobrou acaba sendo o TY. Anote tudo em um papel.

5) Isole os conectores metálicos na ponta com fita isolante, para evitar contato entre eles ao plugar eles no HD.

Portanto a partir desse ponto, fizemos a etapa mais trabalhosa do processo, que é comprar os materiais e confeccionar e testar o cabo. É muitíssimo importante que o cabo esteja funcionando exatamente como descrito acima e que ele esteja bem soldado para evitar perda de contato.

--------------------------------------------------------------------------

------------Preparando o HD----------------------------------------------

1) Primeiro se esfregue em uma superfície de metal para tirar a eletricidade estática do seu corpo. Vire o HD, você verá uma placa verde parafusada em diversos pontos (olhe as fotos). Desparafuse usando a chave de fenda TORX T6, retire a placa verde, arrume novamente a almofada que fica embaixo da placa verde. você verá que tem um conector metálico retangular na foto. Isole esse conector com um cartão comercial como mostrado na foto (recorte o cartão para diminuir o tamanho) e parafuse os 3 parafusos mais distantes desse conector como mostrado na foto.

2) Com o computador desligado, conecte os cabos RX, TY, GND no HD como mostrado na foto, conecte também o cabo de energia sata no HD. NAO conecte o cabo de dados sata no HD. O HD deve estar de cabeça para baixo, devidamente fixo com fita isolante para evitar que ele se mexa e deve estar com fácil acesso e fora do gabinete.

Em um determinado momento futuro do processo, iremos retirar o cabo de força do HD SEM RETIRAR o cabo RX, TY e GND e portanto é importante que os fios não estejam enroscados entre si, assim como retiraremos posteriormente o pedaço de papel que colocamos embaixo da placa verde.

-------------------------------------------------------------------------

-----------------Inserindo os comandos no Hyperterminal------------------

Todos os comandos a serem digitados no Hyperterminal estão em vermelho! Note que é importante colocar os comandos exatamente como estão escritos aqui, tomando cuidado em usar letras maiúsculas ou minúsculas de acordo com o comando.

1) Ligue o computador, entre no windows, ligue e configure o hyperterminal da mesma forma quando o cabo foi testado, colocando as devidas configurações numéricas mencionadas antes e selecionando a porta COM correta como explicado antes. Se tudo estiver correto, ao se pressionar no teclado crtl+z você verá na janela do programa o seguinte prompt:

F3 T>

Caso você não veja nada é provável que os cabos RX e TY não estejam colocados da forma correta, talvez estejam invertidos ou com mal contato. Desligue o computador e rearrange os cabos da forma correta ou procure mal contatos etc e tente novamente.

Se tudo deu certo, então digite o comando em vermelho:

F3 T>/2 [tecle ENTER]
F3 2>Z [tecle ENTER]

Espere sair a mensagem:

Spin Down Complete
Elapsed Time 0.147 msecs
F3 2>

Nesse momento, com muito cuidado e com o HD ligado e todos os fios conectados, retire o pedaço de papel do HD que colocamos embaixo da placa verde e em seguida parafuse cuidadosamente os parafusos soltos que sobraram SEM QUE OS PARAFUSOS ENCOSTEM EM QUALQUER OUTRO LUGAR DA PLACA. Sugiro que use uma fita isolante de forma a fixar o parafuso na chave de fenda para evitar que o parafuso entre em contato com qualquer outra parte da placa verde. É normal que ao se retirar o papel, a almofada que fica embaixo da placa verde saia um pouco de lugar. Se preocupe em ajeitar a almofada somente depois que tudo terminar.

Depois, insira os comandos abaixo:

F3 2>U [tecle ENTER]

Espere a mensagem:

Spin Up Complete
Elapsed Time 7.093 secs
F3 2>

F3 2>/1 [tecle ENTER]
F3 1>N1 [tecle ENTER]

Cuidadosamente nesse ponto retire o cabo de força sata do HD com cuidado, SEM retirar os cabos RX, TY, GND, espere 10 segundos e reconecte de novo. Esse é um ponto em que os vários fóruns divergem, alguns não mencionam a necessidade de tirar o cabo de força nesse ponto o que eu considero um erro.
Isso deve ser feito SEM desligar o computador ou o windows e SEM sair do Hyperterminal.

Com o cabo de força do HD reconectado, pressione crtl+z e aparecera o prompt abaixo:

F3 T>

Digite o comando final em vermelho:

F3 T>m0,2,2,0,0,0,0,22 [tecle enter] [note que o "0" é zero e não a vogal o]

Depois de alguns segundos a um minuto, você deverá ver a mensagem abaixo:

Max Wr Retries = 00, Max Rd Retries = 00, Max ECC T-Level = 14, Max Certify Rewrite Retries = 00C8

User Partition Format 10% complete, Zone 00, Pass 00, LBA 00004339, ErrCode 00000080, Elapsed Time 0 mins 05 secs

User Partition Format Successful - Elapsed Time 0 mins 05 secs

Somente depois dessa mensagem você pode desligar o computador, desconectar todos os cabos, reinstalar os HD normalmente na placa mãe e ver se o problema foi resolvido.

Antes de atualizar o firmware de seu HDD, faça backup com DVDs, pois a atualização do firmware pode falhar, anulando todo o esforço de recuperar o HDD.

Caso não tenha sido resolvido, consulte os links dos fóruns acima para qualquer problema. Existe procedimentos extras para caso esse problema persista, mas não mencionarei nesse post porque eu não precisei realizar eles.

 

 

Comprei no camelô o "suposto" cabo CA-42, o qual foi reconhecido pelo WinXP como DKU-50 com 6 fios!!!... Fiquei meio preocupado, achando que não funcionaria, mas, como já havia retirado o conector, resolví prosseguir com o trabalho. Seguindo a dica de outro colega aqui do fórum, desmontei o conector que já havia retirado e identifiquei os fios soldados, separando-os para testes e identificação de RX, TX e GND.

Observação: Como não achei na configuração do HyperTerminal os valores "0" para Bit de Dados nem "0" para Bit de Parada, usei os populares "8", "N", "1" e "Nenhum" para Controle de Fluxo.

Bastou seguir o restante dos procedimentos para o HD Maxtor DiamondMax 22 - 500GB - STM3500320AS voltar a ser reconhecido pela BIOS e funcionar normalmente.

Quanto à possível dificuldade em "espetar" os 3 terminais MODU nos 3 pinos do HD, sugiro isolar apenas os dois terminas das extremidades, ficando o do meio sem isolamento e, portanto, ocupando menos espaço. (Claro que é necessário garantir que não haja contato entre eles)

Enfim, encorajo a qualquer um que tenha o mesmo tipo de "problema" com HD a seguir o conteúdo do tópico do Diakonov!

 

Mais links sobre este assunto:

http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207951&NewLang=en

http://forum.clubedohardware.com.br/erro-hd-seagate/699482

http://forum.clubedohardware.com.br/recuperacao-hd-seagate/696794

http://www.overclock.net/hard-drives-storage/457286-seagate-bricked-firmware-drive-fix-pics.html

http://www.msfn.org/board/topic/128807-the-solution-for-seagate-720011-hdds/page__st__1000

http://www.guiadohardware.net/comunidade/hd-problema/966710/1.html#post4373693

http://www.guiadohardware.net/comunidade/hd-problema/966710/9.html#post4490690

http://sites.google.com/site/seagatefix/

Read More

Acertando data/hora no Linux

Para alterar data e hora no GNU/Linux, basta digitar o comando abaixo com seus respectivos valores:

# date MMDDhhmmyyyy

O significado de cada conjunto de caracteres é:

• MM: mês
• DD: dia
• hh: hora
• mm: minuto
• yyyy: ano

Ex: #date 072810452010

10:45 horas de 28 de Julho de 2010

Read More

O Que Todos os Programadores de Software Precisam Saber Sobre Unicode e Conjuntos de Caracteres

Autor: Joel Spolsky

Link: http://local.joelonsoftware.com/wiki/

Introdução

Há muita gente que se pergunta o que são aquelas misteriosas tags “Content-Type”. Sabe, aquelas que aparecem no HTML e ninguém sabe o que significam? Quem já não recebeu um e-mail de seus amigos da Bulgária em que a linha de assunto é “???? ?????? ??? ????”?

Fico desanimado quando descubro quantos desenvolvedores de software nada entendem de conjuntos de caracteres, codificação, nem de Unicode. Há alguns anos, um testador beta imaginava se o FogBugz poderia tratar e-mails vindo do Japão. Japonês? E existe e-mail em japonês? Eu não sabia. Ao olhar mais detidamente os controles ActiveX que adquirimos no mercado e que usávamos para analisar conteúdo MIME de e-mails, descobri que eles tratavam de forma completamente errada os conjuntos de caracteres, por isso tínhamos que escrever códigos heróicos para desfazer as conversões erradas e refazê-las correctamente. Quando investiguei outra biblioteca comercial, esta, também, possuía uma implementação do conjunto de caracteres completamente sem nexo. Contactei o desenvolvedor desta biblioteca e ele meio que disse que “não poderia fazer nada”. Como muitos programadores, ele desejava que o problema, de alguma forma, sumisse, fosse varrido para debaixo do tapete.

Mas, não, não sumia. Quando descobri que a ferramenta PHP de desenvolvimento para web era quase completamente ignorante dos problemas de codificação de caracteres e fazia uso irresponsável de 8 bits por carácter, o que tornava quase impossível desenvolver aplicações web adequadas ao uso internacional, pensei, basta!

Pois é, tenho que anunciar: se o leitor é um programador que não sabe o básico de caracteres, conjunto de caracteres, codificação e Unicode e eu o pegar, vou castigá-lo e fazê-lo descascar cebolas por 6 meses num submarino. Juro. E mais uma coisa:

Não é tão difícil

Neste artigo eu vou explicar exactamente o que todo programador deve saber. Todas aquelas coisas sobre "plain text = ascii = caracteres são 8 bits" não estão apenas erradas, estão totalmente erradas e quem ainda programa dessa maneira, não é muito melhor do que um médico que não acredita em germes. Por favor, não escreva nenhuma linha de código até terminar de ler este artigo. Antes de começar, devo avisar que se o leitor é uma daquelas raras pessoas que entende de internacionalização, vai achar simples demais o que digo. Estou somente tentando estabelecer uma base mínima, de modo que todos possam entender o que acontece e escrever códigos que tenham pelo menos alguma possibilidade de funcionar com texto em outras línguas que não o subconjunto do inglês sem palavras com acentos. Devo alertar que isso é apenas uma pequena parte do trabalho de criar software para o mercado mundial. Como só posso escrever sobre um tópico de cada vez, então hoje é sobre conjuntos de caracteres.

Uma Perspectiva Histórica

O jeito mais fácil de entender essas coisas é ir cronologicamente. O leitor provavelmente está pensando que vou falar sobre antigos conjuntos de caracteres como EBCDIC. Bem, não vou! EBCDIC não é relevante para a sua vida. Não temos de ir tão longe no passado.

Outrora nos quase-antigos dias, quando Brian Kernighan e Dennis Ritchie trabalhavam na invenção do Unix e escreviam o livro “C: a Linguagem de Programação”, tudo era muito simples. EBCDIC caía em desuso. Os únicos caracteres que interessavam eram as letras sem acento do bom e velho inglês e existia um código para elas, denominado ASCII, que podia representar cada uma destas letras por números entre 32 e 127. O espaço era 32, a letra “A” era 65 e assim por diante. Isto podia ser convenientemente gravado em 7 bits. Naquela época a maioria dos computadores era de bytes de 8 bits, assim, podia-se representar todos os possíveis caracteres ASCII e ainda sobrava um bit inteiro, que, se o programador fosse malvado, podia ser usado para propósitos inconfessáveis: os ingênuos do WordStar usaram o bit mais alto para indicar a última letra de uma palavra. Isto condenou o WordStar a ser um processador de texto que servia apenas para a língua inglesa. Códigos abaixo de 32 eram chamados não-imprimíveis e eram usados para xingamentos. Brincadeirinha. Eles eram usados como caracteres de controle, o 7 fazia seu computador apitar e o 12 fazia com que a página corrente fosse cuspida da impressora e uma nova fosse alimentada.

E tudo estava bem, desde que se falasse inglês.

Já que os bytes tinham espaço para até oito bits, um bocado de gente começou a pensar: “caramba, posso usar os códigos 128 a 255 do jeito que quiser.” O problema foi que muita gente teve a mesma idéia ao mesmo tempo e cada um teve suas próprias idéias do que colocar naquele espaço. O IBM-PC tinha algo que era conhecido como o conjunto de caracteres OEM (Original Equipment Manufacturer) que fornecia alguns caracteres acentuados das línguas européias e uma porção de caracteres para desenhar linhas...barras horizontais, barras verticais, barras horizontais com pequenos enfeites no lado direito, etc. e podiam-se usar estes caracteres no desenho de lindas caixas e linhas na tela, ainda se pode vê-las nos computadores 8088 das secadoras de roupa das lavanderias. Na realidade, assim que as pessoas começaram a comprar PCs fora dos Estados Unidos, começou a pipocar todo tipo diferente de conjuntos de caracteres OEM, que usavam, cada um a seu modo, os 128 caracteres restantes. Por exemplo, em alguns PCs o código 130 aparecia como “é”(sem as aspas), mas nos computadores vendidos em Israel aparecia a terceira letra do alfabeto hebreu , oguimel (ג), deste modo quando os americanos enviavam seus “résumés” para Israel eles chegavam como “rגsumגs.” Em muitos casos, como na Rússia, houve um monte de idéias do que fazer com os 128 caracteres superiores, com isto não havia como intercambiar, de forma confiável, documentos com os russos.

Ao fim e ao cabo, esta situação foi codificada no padrão ANSI. Nesse padrão todos concordaram com o que fazer abaixo de 128 era essencialmente o que tinha sido padronizado em ASCII, mas havia diferentes formas de lidar com os caracteres do 128 para cima, dependendo de onde se vivia. Esses sistemas diferentes foram denominados página de código. Por exemplo, em Israel usava-se o código de página 862, já os gregos usavam o 737. Todos eram iguais abaixo de 128, mas diferentes do 128 para cima onde todas as letras engraçadas residiam. As versões nacionais do MS-DOS tinham dezenas destes códigos de página, que lidavam com qualquer coisa desde o inglês até ao islandês e havia até alguns códigos de página multilíngüe que podiam lidar com o esperanto e o galego no mesmo computador! Uau! Mas ter, digamos, hebreu e grego na mesma máquina era uma impossibilidade completa a menos que o interessado escrevesse seu próprio software para exibi-los como gráficos bitmap, pois hebreu e grego precisavam de códigos de página com interpretações diferentes dos valores altos.

Enquanto isso, na Ásia, coisas mais estranhas ainda aconteciam para lidar com o fato de que os alfabetos asiáticos têm milhares de letras, que não cabem em 8 bits. A forma de resolver isto era através do uso de um sistema confuso chamado DBCS, o “double byte character set” no qual algumas letras eram armazenadas em um byte e outras em dois. Era fácil mover-se para frente numa seqüência de caracteres, mas próximo do impossível mover-se para trás. Os programadores eram estimulados a não usar s++ e s-- para se movimentar para trás e para frente, mas sim usar funções tais como AnsiNext e AnsiPrev do Windows que sabiam como lidar com aquela confusão toda. Mas, ainda assim, a maioria das pessoas fazia de conta que um byte era um caractere e um caractere eram 8 bits e desde que jamais se transportaria uma seqüência de caracteres de um computador para outro ou se falaria mais de uma língua, isto sempre funcionava. Foi só a Internet aparecer que ficou comum uma seqüência de caracteres ser passada de um computador para outro e a construção começou a desmoronar. Por sorte inventaram o Unicode.

 

Unicode

O Unicode foi um imenso esforço para criar um conjunto único de caracteres que incluísse todos os sistemas de escrita do planeta e até mesmo alguns de ficção como klingon. Algumas pessoas cometem erro quando pensam que o Unicode é simplesmente um código de 16-bits onde cada caractere ocupa 16 bits e assim podem existir 65.536 caracteres possíveis. Na realidade, isto não é verdade. Este é o mais comum dos mitos sobre o Unicode, por isso ninguém precisa se sentir mal se pensava assim.

De fato, o Unicode possui uma forma diferente de encarar os caracteres, os programadores têm que entender esta forma do Unicode tratar os caracteres ou nada vai fazer sentido. Até agora assumimos que uma letra é mapeada para alguns bits que podem ser guardados em disco ou memória:

A -> 0100 0001

No Unicode uma letra é mapeada para um negócio chamado ponto de código que é apenas um conceito teórico. Como este ponto de código é representado em memória ou disco já é outra estória. Em Unicode a letra A é um ideal platônico. Ela simplesmente flutua no céu:

A

Este A platônico é diferente do B e diferente do a, mas é o mesmo que A e A e A. A idéia que A na fonte Times New Roman é o mesmo caractere que o A na fonte Helvetica, mas diferente do “a” minúsculo, isto não parece muito controverso, mas em algumas línguas entender o que é uma letra pode ser controverso. A letra alemã ß é uma letra de verdade ou apenas uma forma elegante de escrever ss? Se a forma da letra muda no fim da palavra, ela se torna uma letra diferente? Em hebreu sim, em árabe não. O pessoal do consórcio Unicode elaborou o assunto por quase toda década passada, houve um intenso debate político e, por isso, o leitor não precisa mais se preocupar.

O assunto já foi resolvido.

A cada letra platônica em cada alfabeto foi associado, pelo consórcio Unicode, um número mágico que é escrito como: U+0639. Este número mágico é conhecido como um ponto de código. O U+ quer dizer “Unicode” e os números são hexadecimais. U+0639 é a letra arábica “Ain”. A letra A do inglês é U+0041. No web site do Unicode ou com o utilitário charmap do Windows 2000/XP pode-se ver todos os códigos e letras associadas.

Não há qualquer limite ao número de letras que o Unicode pode definir e de fato o consórcio foi além do limite de 65.536, assim nem toda letra do Unicode pode ser representada por dois bytes, mas, como já disse, isto era um mito.

Vamos lá, a seguinte seqüência:

Hello

seria representada em Unicode pelos cinco pontos de código:

U+0048 U+0065 U+006C U+006C U+006F.

Isto é somente uma porção de pontos de código. Na realidade, números. Nada foi dito ainda sobre como armazenar estes números na memória nem como representá-los num e-mail.

 

Codificações

Agora é que as codificações aparecem. A primeira idéia para a codificação Unicode, que gerou o mito sobre os dois bytes, foi, ei! vamos armazenar estes números em dois bytes cada. E aí Hello se torna:

00 48 00 65 00 6C 00 6C 00 6F

Certo? Bem, nem tanto! Não poderia ser também:

48 00 65 00 6C 00 6C 00 6F 00 ?

Tecnicamente, sim, acredito que poderia, e, de fato, os primeiros implementadores desejavam ter a capacidade de armazenar seus pontos de código Unicode no modo big-endian ou little-endian, dependendo de qual deles possibilitava a maior rapidez ao seu particular CPU e, veja só, passou a manhã e foi-se a noite e já existiam duas formas de armazenar o Unicode. Foi por isso que apareceu a convenção bizarra de armazenar um FE FF no início de cada seqüência Unicode; a isto deu-se o nome de Marca de Ordem de Byte do Unicode e se trocarmos os bytes altos pelos baixos a seqüência fica FF FE e quem ler a seqüência vai saber que tem de permutar, alternadamente, cada byte. Eca! Nem toda seqüência Unicode possui uma marca de ordem de byte no seu começo.

Por um instante pareceu que isso seria suficiente, mas os programadores reclamavam. “Veja todos estes zeros!” diziam, pois, eram norte-americanos e viam texto em inglês que raramente utilizava pontos de código acima de U+00FF. Também, eles eram hippies liberais da Califórnia que queriam economizar (desprezo). Se fossem texanos não se incomodariam de beber duas vezes o número de bytes. Mas os californianos, mais fracotes, não suportavam a idéia de dobrar o tamanho da memória necessária para as seqüências, e, de qualquer modo, havia todos aqueles malditos documentos que usavam os conjuntos de caracteres ANSI e DBCS e quem é que iria convertê-los? Moi? Por isso é que se ignorou o Unicode por vários anos e com o passar do tempo as coisas pioraram.

Aí inventaram o conceito brilhante do UTF-8 que era outro sistema de armazenamento de seqüências de pontos de código Unicode, aqueles números mágicos U+, na memória em bytes de 8 bits. Em UTF-8 cada ponto de código de 0 a 127 é armazenado em um único byte. Só os pontos de código 128 e além são armazenados em 2, 3 e, na realidade, até 6 bytes.

Isso resultou no elegante efeito de os textos em inglês terem exatamente a mesma aparência em UTF-8 ou em ASCII, com isto os americanos nem notaram que havia algo errado. Só o resto do mundo é que tinha que dançar o miudinho. Por exemplo, Hello, que era U+0048 U+0065 U+006C U+006C U+006F, seria armazenado como 48 65 6C 6C 6F, o que, pasmem! era o mesmo tanto em ASCII quanto em ANSI e em todos conjuntos de caracteres OEM do planeta. Agora, se precisasse usar letras acentuadas ou gregas ou klingon, seria necessário usar vários bytes para armazenar um único ponto de código, mas os americanos não notariam. (Uma propriedade adicional do UTF-8 é que os velhos códigos processadores de cadeias de caracteres que usam um único byte 0 como terminador nulo não truncam as cadeias).

Até aqui expliquei três formas de codificação Unicode. O método tradicional de codificação em dois bytes conhecido como UCS-2 (porque usa dois bytes) ou UTF-16 (porque usa 16 bits) e ainda temos que decidir se é UCS-2 big-endian ou UCS-2 little-endian. Temos também o novo padrão popular UTF-8 com a elegante propriedade de funcionar bem se por uma feliz coincidência a pessoa trabalhar com texto em inglês e programas idiotas que não sabem que existe outra coisa além do ASCII.

Há uma porção de outras formas de codificação para o Unicode. Há um negócio chamado UTF-7, que se parece com o UTF-8, mas garante que o bit mais alto vai ser sempre zero, pois, se seus e-mails Unicode precisassem passar por algum tipo de sistema de guarda de fronteira draconiana que ache que 7 bits são mais do que suficientes, ainda podem se infiltrar e saírem ilesos. Há o UCS-4, que guarda cada ponto de código em 4 bytes, o que propicia o divino atributo de garantir que todos pontos de código podem ser armazenados no mesmo número de bytes, mas, Deus do céu, nem os texanos seriam tão afoitos a ponto de gastar tanta memória.

E agora, já acostumados a pensar em termos das letras platônicas ideais representadas pelos códigos de ponto Unicode, afirmo que esses códigos de ponto Unicode podem ser codificados em qualquer esquema de codificação antigo! Por exemplo, podemos codificar a seqüência para Hello (U+0048 U+0065 U+006C U+006C U+006F) em ASCII ou na antiga codificação OEM do grego ou na codificação ANSI do hebreu ou qualquer um das centenas de codificações que foram inventadas até hoje, com uma pegadinha: algumas letras podem não ser mostradas! Se não houver um equivalente para o código de ponto Unicode que queremos representar na codificação que usaremos, vamos conseguir apenas um ponto de interrogação: ? Ou, se trabalharmos bem, uma caixa. Qual apareceu? -> �

Há centenas de codificações tradicionais que armazenam corretamente somente alguns códigos de ponto, e trocam todos os outros códigos de ponto para pontos de interrogação. Algumas codificações populares de textos em inglês são Windows-1252 (o padrão do Windows 9x para as línguas da Europa Ocidental) e o ISO-8859-1, também conhecido como Latin-1 (útil também para as línguas da Europa Ocidental). Mas se tentarmos armazenar as letras russas ou hebréias nestes esquemas de codificação, vamos conseguir um monte de pontos de interrogação. Os UTF 7, 8, 16 e 32 têm, todos, a capacidade de armazenar corretamente qualquer ponto de código.

 

O Fato Mais Importante Sobre Codificação

Se esquecer tudo sobre que falamos acima, lembre pelo menos um fato importante. Não faz sentido uma seqüência de caracteres sem se saber que codificação ela utiliza. Não podemos mais enfiar a cara na areia e achar que texto “puro” é ASCII.

Não Existe Este Tal de Texto Puro

Se tivermos uma seqüência de caracteres na memória, num arquivo ou num e-mail, temos que saber que codificação usa ou não poderemos interpretá-lo ou mostrá-lo corretamente no monitor.

Quase toda afirmação estúpida como “minha página na Internet aparece como lixo” ou “ela não consegue ler meus e-mails quando uso acentos” pode ser atribuída a um programador ingênuo que não entendeu ainda que se ele não disser que uma certa cadeia de caracteres foi codificada em UTF-8 ou ASCII ou isso 8859-1 (Latin 1) ou Windows 1252 (europeu ocidental), não se conseguirá exibi-la corretamente ou mesmo entender onde ela termina. Há mais de uma centena de codificações acima do código de ponto 127, uma pequena bobagem muda tudo. Como se guarda a informação sobre qual codificação uma cadeia de caracteres usa? Bem, há uma forma padrão de fazer isto. Num e-mail espera-se que contenha uma certa cadeia no seu cabeçalho no formato

Content-Type: text/plain; charset="UTF-8"

Para uma página na Internet, a idéia original era que os servidores web enviariam um cabeçalho http similar ao Content-Type junto com a página web -- não no corpo HTML, mas como um dos cabeçalhos de resposta enviados antes da página HTML.

Isto causava problemas. Suponha-se que um grande servidor web com muitos sítios e centenas de páginas criadas por muitas pessoas em muitas e diferentes línguas e com qualquer codificação que a versão pessoal do Microsoft FrontPage fosse capaz de produzir. O servidor web por si só não saberia em que codificação cada arquivo fora escrito, então, não poderia enviar o cabeçalho Content-Type.

Seria conveniente colocar o cabeçalho Content-Type do arquivo HTML no próprio arquivo HTML, com algum tag especial. Claro isto enlouqueceu os puristas... como se faria para ler o arquivo HTML sem saber que codificação ele usava?! Afortunadamente, quase toda codificação em uso trata do mesmo modo os caracteres entre 32 e 127, assim podemos iniciar a página HTML sem utilizar as letras engraçadas:

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Mas esta meta-tag tem que ser a primeira coisa da seção <head>, pois, assim que o navegador web encontra esta tag pára de analisar a página e reinicia, depois de reinterpretar toda página, com a codificação especificada.

O que fazem os navegadores se não encontram um Content-Type no cabeçalho http nem na meta-tag? O Internet Explorer age de forma muito interessante: tenta adivinhar, baseado na freqüência de aparição dos diversos bytes em textos típicos codificados em várias línguas, que língua e codificação foram usadas. Como os diversos códigos de página de 8 bits tendem a colocar as letras nacionais em intervalos diferentes entre 128 e 255 e, como, cada língua tem histogramas de uso de letras com características diferentes, este método tem uma boa probabilidade de funcionar. É muito bizarro, mas, parece funcionar com tal freqüência que desenvolvedores ingênuos, que nunca souberam que o navegador procuraria por um cabeçalho Content-Type na sua página, viam que sua página aparecia OK no seu navegador e, então, estava tudo bem, até que um dia, escreviam algo que não se conformava à freqüência de distribuição de uso de letras de sua língua nativa, então, o Internet Explorer decidia que a língua era o coreano e exibia a página nesta língua, isto provaria, pensava eu, que a Lei de Postel: “seja conservador com o que você emite e liberal no que você aceita” não é um bom princípio de Engenharia. De qualquer modo, o que poderia fazer o pobre leitor daquela página web, escrita em búlgaro, mas que era exibida em coreano (e nem mesmo um coreano puro)? Usar o menu Exibir | Codificação e tentar algumas codificações (há pelo menos uma dúzia para as línguas da Europa Oriental) até acertar a sua. Isto se ele conhecesse o assunto, o que não ocorre com a maioria das pessoas.

No CityDesk, software de gerência de sítios web, publicado por minha empresa, decidimos que sua codificação interna seria toda em Unicode UCS-2 (dois bytes), que é o que o Visual Basic, o COM e o Windows NT/2000 usam na sua cadeia nativa de caracteres. No código C++ as cadeias são declaradas como wchar_t ("wide char") ao invés de char e utilizam as funções wcs ao invés das str (por exemplo wcscat e wcslen ao invés de strcat e strlen). Para criar uma cadeia literal em código C basta pôr um L antes como em: L"Hello".

Ao publicar uma página web, o CityDesk a converte para a codificação UTF-8 que é bem suportada por navegadores há muitos anos. Esta é a forma em que todas as línguas do Joel on Software são codificadas e não temos registro de qualquer reclamação de pessoas com dificuldade de exibi-las.

Este artigo ficou comprido, tenho claro que não poderia esgotar o assunto de codificação de caracteres e Unicode nele, mas espero que se o leitor chegou até aqui, aprendeu o suficiente para retornar, usando agora antibiótico em vez de sanguessuga e magia, a programar, trabalho para o qual os deixo e volto agora.

Read More

Agendando tarefas com o cron

Autor:Carlos E. Morimoto
Fonte:http://www.guiadohardware.net/dicas/cron.html
O agendamento de tarefas é um recurso essencial em servidores. No Linux, o daemon responsável pela tarefa é o cron. Ele é o responsável por diversas funções executadas automaticamente na maioria das distribuições, tais como o rotacionamento dos logs e pode ser programado para executar operações diversas, tais como scripts de backup.

O arquivo principal de configuração é o "/etc/crontab" e o script responsável pelo serviço é o "/etc/init.d/cron" (ou "/etc/init.d/crond" no Fedora e no CentOS). A configuração do cron pode parecer indigesta à primeira vista, mas na verdade ela é bastante lógica e, dependendo do ponto de vista, até mesmo simples.

Você pode criar um agendamento simples adicionando a linha abaixo no final do arquivo:

* * * * * root date >> /tmp/testedata

Ela faz com que o sistema execute o comando "date >> /tmp/testedata" uma vez a cada minuto. O comando "date" mostra o horário atual do sistema e as duas setas direcionam a saída do comando para o arquivo especificado.

Depois de salvar o arquivo, você precisa apenas esperar um minuto ou dois e verificar o conteúdo do arquivo para checar se o agendamento está funcionando. Ele conterá várias linhas com a saída do comando, como em:

Qui Jun 19 04:36:38 BRT 2008

Qui Jun 19 04:36:39 BRT 2008

O cron checa o conteúdo do arquivo uma vez a cada minuto, de forma que não é necessário reiniciar o serviço para que a alteração entre em vigor. Para desativar o agendamento, basta remover ou comentar a linha.

Os cinco campos separados por espaço no início da linha permitem definir o horário ou a periodicidade em que uma determinada tarefa será executada. O primeiro campo especifica os minutos, o segundo especifica as horas, o terceiro especifica o dia, o quarto o mês e o quinto especifica o dia da semana. A princípio essa designação parece muito confusa, mas na verdade ela é bastante prática.

Para que o comando fosse executado todos os dias às 6:20 da manhã, usaríamos:

20 06 * * * root date >> /tmp/testedata

Os dois campos especificam a hora, como você pode ver. Os outros três (dia, mês e dia da semana) permanecem com o asterisco, o que faz com que o comando seja executado todos os dias. Se a idéia fosse fazer com que ele fosse executado nessa mesma hora, mas apenas aos domingos (imagine o caso de um script de backup que precisasse desativar temporariamente o banco de dados, deixando o servidor fora do ar, por exemplo), você usaria:

20 06 * * 0 root /usr/local/bin/script-de-backup

Veja que agora usamos o número 0 no último campo, que indica o dia da semana. Na sintaxe do cron, os dias da semana são numerados de 0 a 6, onde o "0" representa o domingo e o "6" o sábado.

É possível também especificar mais de um valor em um mesmo campo, fazendo com que o script seja executado duas vezes por dia, ou duas vezes por semana, sem precisar incluir duas linhas diferentes. Se deseja que um script seja executado tanto aos domingos quanto às quartas-feiras, sempre às 4:00 da manhã, você usaria:

00 04 * * 0,3 root /usr/local/bin/script-de-backup

A vírgula no campo do dia da semana permite especificar mais de um valor, ela é interpretada pelo cron como um "e", de forma que "0,3" é lido como "aos domingos e às quartas feiras".

É possível também usar a "/" para indicar um período. Para fazer com que o script seja executado a cada 5 minutos, você usaria:

*/5 * * * * root /usr/local/bin/verificar-servidor

O mesmo pode ser feito para os demais campos. Para que o script fosse executado a cada 3 horas (1:15, 4:15, 7:15, etc.), por exemplo, você usaria:

15 */3 * * * root /usr/local/bin/verificar-servidor

Continuando, temos os campos com o dia e o mês. Para executar um script às 6:20 da manhã, no primeiro dia de cada mês, você usaria:

00 06 1 * * root /usr/local/bin/gerar-folha-de-pagamento

Para executar apenas no dia primeiro de janeiro, uma vez por ano, usaria:

00 06 1 * * root /usr/local/bin/feliz-ano-novo

O cron executa a tarefa apenas se todas as condições especificados nos campos sejam satisfeitas. Isso permite especificar condições bastante específicas. Para executar um comando às 00:15 toda vez que uma sexta feira cair no dia 13 (imagine que você seja supersticioso e queira fazer um backup extra, por exemplo :), você usaria:

15 00 13 * 5 root /usr/local/bin/backup-extra

Naturalmente, você pode também fazer com que os scripts sejam executados usando outros logins de usuário em vez do root, o que é o ideal do ponto de vista da segurança. Para isso, basta substituir o "root" pelo login desejado. Com isso, o script é executado dentro das permissões do usuário, o que limita qualquer possível dano ou brecha de segurança que possa ser aberta pelo script.

Em quase todas as distribuições atuais, o arquivo "/etc/crontab" vem pré-configurado para que o sistema execute os scripts incluídos nas pastas "/etc/cron.hourly", "/etc/cron.daily", "/etc/cron.weekly" e "/etc/cron.monthly", executados, respectivamente, uma vez a cada hora, dia, semana e mês:

01 * * * * root run-parts /etc/cron.hourly

02 4 * * * root run-parts /etc/cron.daily

22 4 * * 0 root run-parts /etc/cron.weekly

42 4 1 * * root run-parts /etc/cron.monthly

Esta configuração facilita o agendamento de tarefas, já que para fazer com que um script seja executado todos os dias, por exemplo, você precisa apenas colocá-lo dentro da pasta "/etc/cron.daily". Olhando o conteúdo da pasta, você notará a presença de diversos scripts de manutenção do sistema, como o logrotate, encarregado de rotacionar e compactar os arquivos de log, evitando que eles cresçam indefinidamente.

Os scripts incluídos na programação do cron são arquivos de texto simples, contendo os comandos que você deseja que sejam executados. Aqui temos um exemplo de script simples de backup, que usa o rsync para salvar uma cópia do conteúdo da partição "/var/www" na pasta "/mnt/sdb1", que corresponderia a um HD separado, salvando a saída do comando, em um arquivo de texto, que você pode examinar posteriormente em busca de erros:

#! /bin/sh

/usr/bin/rsync -av --delete /var/www/ /mnt/sdb1 >> /var/log/backup-www.log

Para que o script fosse executado todos os dias, você precisaria apenas copiá-lo para a pasta "/etc/cron.daily" e marcar a permissão de execução (chmod +x). Outra opção seria simplesmente adicionar uma nova linha no arquivo "/etc/crontab", especificando a hora em que você deseja que ele seja executado.

Read More

Escrevendo scripts de Backup (2008)

Autor:Carlos E. Morimoto
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.

Read More