1-BACKUP

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.

2-ESCREVENDO SCRIPTS DE BACKUP

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.hardware.com.br/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.

3-BACKUP AUTOMÁTICO EM DVD OU CD

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

4-BACKUP AUTOMÁTICO EM UM SERVIDOR

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

5-USANDO O RSYNC
O rsync é um grande aliado na hora de fazer backups ou quando é necessário sincronizar duas
pastas com um grande volume de arquivos. 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.

6-BACKUPS INCREMENTAIS COM O RSYNC

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

7-COMANDOS REMOTOS COM RSYNC

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

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

É possível monitorar os erros de leitura do HD (mesmo antes dos badblocks começarem a

aparecer) usando o SMART, um recurso de monitoramento disponível em todos os HDs modernos,
onde a própria controladora monitora o status do HD e disponibiliza um log numa área reservada,
que pode ser lida pelo sistema operacional.

9-MONITORANDO A SAUDE DO HD VIA SMART

No Linux, este recurso é disponibilizado através do "smartmontools", um pacote disponível nos
repositórios da maioria das distribuições e também no http://smartmontools.sourceforge.net/.
O smartmontools é baseado no "smartsuite", um pacote mais antigo, que ainda é incluído em
algumas distribuições (como no Debian), mas que oferece menos funções e não é mais
desenvolvido ativamente.

A maior parte das funções podem ser acessadas usando o utilitário "smartctl", incluído no pacote.
Comece usando a opção "-i", seguida do device do HD (como em "smartctl -i /dev/hda") para ver
informações sobre o drive:

Note que neste caso, embora o SMART seja suportado pelo drive, ele está desativado. Antes de
mais nada, precisamos ativá-lo, usando o comando:

# smartctl -s on /dev/hda

Para um diagnóstico rápido da saúde do drive (fornecido pela própria controladora), use o
parâmetro "-t short", que executa um teste rápido, de cerca de dois minutos, e (depois de alguns
minutos) o parâmetro "-l selftest" que exibe o relatório do teste:

# smartctl -t short /dev/hda

Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.

# smartctl -l selftest /dev/hda

Este comando exibe um relatório de todos os autotestes realizados e o status de cada um. Num
HD saudável, todos reportarão "Completed without error".

Você pode executar também um teste longo (que dura cerca de uma hora) usando o parâmetro "-
t long". Ambos os testes não interferem com a operação normal do HD, por isso podem ser
executados com o sistema rodando. Em casos de erros, o campo "LBA_of_first_error" indica o
número do primeiro setor do HD que apresentou erros de leitura, como em:

Status Remaining LBA_of_first_error

Completed: unknown failure 90% 0xfff00000
Nestes casos, execute novamente o teste e verifique se o erro continua aparecendo. Se ele
desaparecer no teste seguinte, significa que o setor defeituoso foi remapeado pela controladora,
um sintoma benigno. Caso o erro persista, significa que não se trata de um badblock isolado, mas
sim o indício de um problema mais grave.

O parâmetro "-H" (health) exibe um diagnóstico rápido da saúde do drive, fornecido pela própria
controladora:

# smartctl -H /dev/hda

SMART overall-health self-assessment test result: PASSED

Neste caso, o SMART informa que não foi detectado nenhum problema com o drive. Em casos de
problemas iminentes, ele exibirá a mensagem "FAILING". Este diagnóstico da controladora é
baseado em várias informações, como erros de leitura, velocidade de rotação do disco e
movimentação da cabeça de leitura.

Um disco "FAILING" não é um local seguro para guardar seus dados, mas em muitos casos ainda
pode funcionar por alguns meses. Se ainda não houver muitos sintomas aparentes, você pode
aproveitá-los em micros sem muita importância, como estações que são usados apenas para
acessar a Web, que não armazenam dados importantes. Note que, embora relativamente raro, em
muitos casos o drive pode realmente se perder menos de 24 horas depois de indicado o erro, por
isso transfira todos os dados importantes imediatamente.

Você pode ver mais detalhes sobre o status de erro do HD usando o parâmetro "-A", que mostra
todos os atributos suportados pelo HD e o status de cada um. Na sexta coluna (Type) você pode
verificar a importância de cada um; os marcados como "Old_age" indicam sintomas de que o HD
está no final de sua vida útil, mas não significam por si só problemas iminentes. Os mais graves
são os "Pre-Fail", que indicam que o HD está com os dias contados.

Na coluna "WHEN_FAILED" (a mais importante), você vê o status de cada opção. Num HD

saudável, esta coluna fica limpa para todas as opções, indicando que o HD nunca apresentou os
erros:
O número de setores defeituosos no drive (não remapeados) pode ser visto nos atributos "197
Current_Pending_Sector" e "198 Offline_Uncorrectable", onde o número de badblocks é informado
na última coluna. Em situações normais, os badblocks não remapeados contém pedaços de
arquivos, que a controladora muitas vezes tenta ler por muito tempo antes de desistir.

Em casos extremos, onde existam vários badblocks não marcados, você pode usar o truque de
encher o HD com zeros, usando o comando "dd if=/dev/zero of=/dev/hda" para forçar a
controladora a escrever em todos os blocos e assim remapear os setores (perdendo todos os
dados, naturalmente).

O número de setores defeituosos já remapeados, por sua vez, pode ser acompanhado através dos
atributos "5 Reallocated_Sector_Ct" e "196 Reallocated_Event_Count".

Naturalmente, não basta executar estes testes apenas uma vez, pois erros graves podem
aparecer a qualquer momento. Você só terá segurança se eles forem executados periodicamente.

Para automatizar isso, existe o serviço "smartd" ("smartmontools" no Debian), que fica
responsável por executar o teste a cada 30 minutos e salvar os resultados no log do sistema, que
você pode acompanhar usando o comando "dmesg".

No caso do Debian, além de configurar o sistema para inicializar o serviço no boot, você precisa
configurar também o arquivo "/etc/default/smartmontools", descomentando a linha
"start_smartd=yes".

O padrão do serviço é monitorar todos os HDs disponíveis. Você pode também especificar
manualmente os HDs que serão monitorados e os parâmetros para cada um através do arquivo
"/etc/smartd.conf".

Comece comentando a linha "DEVICESCAN". O arquivo contém vários exemplos de configuração

manual. Uma configuração comum é a seguinte:

/dev/hda -H -l error -l selftest -t -I 194 -m tux@gmail.com

Esta linha monitora os logs do "/dev/hda" (erros e testes realizados) e monitora mudanças em
todos os atributos (incluindo a contagem de badblocks e setores remapeados), com exceção da
temperatura (que muda freqüentemente), e envia e-mails para a conta especificada sempre que
detectar mudanças. Para que ele use apenas o log do sistema, sem enviar o e-mail, remova a
opção "-m".

Para que os relatórios via e-mail funcionem, é preciso que exista algum MTA instalado na
máquina, como o Sendmail ou o Postfix. O smartd simplesmente usa o comando "mail" (que
permite o envio de e-mails via linha de comando) para enviar as mensagens. No Debian (além do
MTA) é necessário que o pacote "mailutils" esteja instalado.

Depois de alterar a configuração, lembre-se de reiniciar o serviço, usando o comando:

# /etc/init.d/smartd restart
ou:
# /etc/init.d/smartmontools restart
Caso o SMART indique algum erro grave e o HD ainda esteja na garantia, você pode imprimir o
relatório e pedir a troca.

A vida útil média de um HD IDE é de cerca de dois anos de uso contínuo. HDs em micros que não
ficam ligados continuamente podem durar muito mais, por isso é saudável trocar os HDs dos
micros que guardam dados importantes anualmente e ir movendo os HDs mais antigos para
outros micros.

Normalmente, os fabricantes dão um ano de garantia para os HDs destinados à venda direta ao
consumidor e seis meses para os HDs OEM (que são vendidos aos integradores, para uso em
micros montados, mas que freqüentemente acabam sendo revendidos). Uma dica geral na hora de
comprar HDs é nunca comprar HDs com apenas três meses de garantia, que normalmente é dada
só para HDs remanufaturados.