1-BACKUP

Os backups são uma parte importante da administração de qualquer servidor nas empresas.
Ao contrário de um desktop, onde podemos fazer uma imagem do HD usando o partimage,
Ghost ou outro programa que podemos adquirir na internet, em um servidor os backups
precisam, quase sempre, serem feitos com o servidor em operação com rotinas pré- definidas
pelo admministrador de rede, sem atrapalhar o acesso dos usuários, geralmente os bakups são
feitos após o expedinete. O nível de dificuldade também é um pouco maior, além dos arquivos
e pastas, é necessário salvar também arquivos de configuração, bases de dados do MySQL e
assim por diante.
Sem os backups regulares, aumentam a possibilidade que você tenha problemas e perca dados
importantes da empresa.
As principais pastas com as quais você precisa se preocupar em 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ãoca maior parte dos arquivos dos usuários

/var/lib/mysql: Diretório padrão das bases de dados do MySQL, 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 caso seja necessário reconfigurar o servidor após algum problema.

/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,.

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.
Os Utilitários como o TAR foram desenvolvidos para facilitarem os backups em fita, gerando
um único arquivo contendo todos os dados, que era gravado na fita de forma sequêncial. 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), era usado o comando

# tar -cvf /dev/st0 /var/www

Era 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. Temos possibilidade dividir o
backup em vários volumes e salvá-lo em fitas separadas, mas o processo se torna
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 mas, elas são bastante caras tornando os HDs uma
opção muito mais atrativa, já que já existem no mercado HDs de 1 TB a preços bem
competitivos.

Surge então a figura do NAS, um servidor de arquivos dedicado, que 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.

Temos casos em que o volume de dados paraa armazenar é pequeno, tornando viável utilizar
DVDs ou mesmo CD-ROMs para realizar os backups. A vantagem nesse caso é que as mídias
são baratas e podendo 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

Na década de 70, foram desenvolvidos vários utilitários para fazer backup de arquivos
armazenados em servidores Linux. Na época os computadores 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.
×oram desenvolvidos então os 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 utilizados ao longo do
tempo e, por incrível que pareça, são usados sem grandes modificações até os dias hoje.

Existem muitos utilitários amigáveis de backup, como o Amanda, mas, internamente, eles
continuam utilizando como base o o dump, tar, gzip e outros trigenários 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 usado para compactar uma pasta é similar ao "tar -zxvf" usado 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á 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.

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

Um dos grandes problemas em utilizar arquivos compactados é que é muito difícil recuperar o
conteúdo do arquivo caso ele seja corrompido. Diferente de em uma pasta com diversos
arquivos, onde um ou mais badblocks apenas fariam com que alguns dos arquivos ficassem
danificados, 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

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

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.

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

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" 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:

mont= /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

3-BACKUP AUTOMÁTICO EM DVD OU CD

Existe a possibilidade de gravar o backup em DVD, ao invés salvar em uma pasta, você pode
usar o "growisofs" para gravá-lo na mídia.

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 seja especificado 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 adicionando a opção "-M" a partir da segunda gravação, que adiciona novas seções
no DVD, até que o espaço se acabe.

O "/dev/dvd" indica o dispositivo do drive de DVD, 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 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, será necessário 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 |
, 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 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".
Uma 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 excelente opção é o backup em servidor remoto externo, de preferência um servidor

remoto, situado em outro estado ou país. Usar dois servidores em locais diferentes elimina a
possibilidade de desastres (como incêndios ou inundações) destrírem servidores e backups.

Outra forma simples a transferência de arquivos automaticamente no final do processo vis

script é utilizar um par de chaves do SSH sem passphrase, fazendo que o script transfira
arquivos usando o comando "scp", sem solicitar a senha ou a passphrase ao realizar cada
cópia. Essa opção é menos segura que usando chaves protegidas por passphrase, já que caso
alguém obtenha acesso ao arquivo ".ssh/id_rsa" dentro no home do usuário, poderá ter acesso
ao servidor. Entretanto, é uma situação de risco aceitável, principalmente se o backup é feito
diretamente entre dois servidores protegidos, pois o risco é reduzido caso você utilize uma
conta limitada no segundo servidor.

Primeiro criar-se um usuário no segundo servidor, usado para permitir o acesso do script.
Ajuste o diretório home, especificando a pasta que será usada para armazenar os backups,
como em:

# adduser --home /mnt/sdb1/backups bkuser

Depois criamos o par de chaves, usados para o acesso no primeiro servidor com o comando
"ssh-keygen -t rsa", que deve ser executado usando o usuário que será usado para executar o
script de backup. Se executado pelo root, então o comando é também executado como root:

# ssh-keygen -t rsa

Precisamos que a chave possa ser usada para login automático, então pressione Enter quando
o ssh-keygen perguntar pela passphrase, deixando-a em branco.

A gora é instalar a chave gerada no segundo servidor ("backup.gdhn.com.br" no exemplo),

com o comando "ssh-copy-id", especificando o usuário criado anteriormente e o endereço do
segundo servidor, como em:

# ssh-copy-id -i ~/.ssh/id_rsa.pub bkuser@backup.gdhn.com.br

Assim o primeiro servidor terá acesso direto ao segundo via usuário "bkuser" que usaremos
para transferir os arquivos pelo scp. ×aça um teste transferindo um arquivo do primeiro para o
segundo, como em:

# scp arquivo.tar.gz bkuser@backup.gdhn.com.br:/mnt/sdb1/backups/

Perceba que o comando será executado sem pedir senha. Depois adicione o comando para
transferir o arquivo no seu script de backup, 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

O script gerará o arquivo com o backup, copia para o segundo servidor via scp e, depois da
deleta a cópia local, evitando acabar com o espaço em disco.

×inalmente automatizamos a execução do script, adicionando uma entrada no arquivo

"/etc/crontab" (do primeiro servidor):

59 4 * * * root /usr/local/bin/script-backup

Esta entrada faz o script executar todos os dias às 4:59 AM, gerando um novo arquivo com a
data de execução e copiando-o para o segundo servidor, arquivando os backups.

5-USANDO O RSYNC

O rsync é usado para fazer backups ou para sincronizar duas pastas com muitos arquivos. Ele
permite sincronizar o conteúdo de duas pastas, e transfere apenas as modificações. E não
apenas compara arquivo por arquivo, mas também compara o conteúdo de cada um. Se uma
pequena parte do arquivo foi alterada, ele transfe apenas ela.

É uma forma simples de fazer grandes backups incrementais, ou partições inteiras, mantendo
uma única cópia atualizada total em um HD externo ou servidor remoto. Este backup
incremental pode ser atualizado todo dia e complementado por um backup completo (em caso
de desastre), feito uma vez por semana ou mês.

Para a instalação procure o 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, informe a pasta de origem e a de destino, como em:

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

A opção "-a" (archive) faz manter todas as permissões e atributos dos arquivos, e ao criar os
arquivos com o tar, e o "v" (verbose) mostra o progresso na tela.

A cópia inicial demora um pouco, porém a segunda vez a operação é muito mais rápida, pois
são copiadas apenas as mudanças.

Neste comando estamos copiando a pasta "trabalho" recursivamente para dentro da

"/mnt/backup", criando 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". A barra final é importante dentro da sintaxe do
rsync.
Se algum desastre acontecer, 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, assim:

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

O rsync é prático para automatizar backups locais, como quando o servidor possui dois HDs e
você deseja que o segundo armazene a cópia completa dos arquivos do primeiro para qualquer
eventualidade. Um exemplo de script de backup simples para esta função:

#! /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

No 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 indicado, podendo verificar as mensagens no dia
seguinte, em busca de erros.
O "--delete" faz com que arquivos apagados na pasta original sejam apagados na pasta do
backup, mantendo uma cópia fiel. A opção pode ser removida do comando se o objetivo é
fazer com que o backup mantenha arquivos antigos para um recuperação posterior caso
necessário.

O detalheé que do script é que a partição é montada no início e desmontada no final. O

objetivo é que o segundo HD seja usado apenas para o backup e fique desativado no restante
do tempo, de forma que o desgaste ou 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 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 diariamente usando o cron, para que você tivesse sempre um
backup do dia anterior, para recuperar qualquer arquivo deletado acidentalmente. Este backup
local deveria ser complementado por algum backup remoto, que permitisse recuperar os
arquivos se necessário, então você poderia complementá-lo com um backup completo feito
usando o tar e o scp.

6-BACKUPS INCREMENTAIS COM O RSYNC

É possível também fazer backups incrementais com o rsync em combinação com o comando
"cp -al". O comando "cp -a" permite copiar a pasta, e todo o seu conteúdo, mantendo todas as
permissões de acesso, mas 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 (comando "ln -s"), os hard links são atalhos que apontam os inodes
dos arquivos de destino dentro do sistema de arquivos. Eles são vistos pelo sistema da mesma
forma que os arquivos reais, com exceção de que não ocupam espaço (com exceção dos bytes
usados pelo atalho). Ao usar o comando "cp -al", criamos uma cópia exata da pasta original.

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

Executando diariamente, este script criaria um conjunto de 7 pastas, numeradas de 0 a 6,

usadas para armazenar os backups. 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

# ×az 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. A principal
limitação desse processo é que existe apenas uma cópia do arquivo, quando é atualizado todos
hard links passam a apontar para a versão mais recente.

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. 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, 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. 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". 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. 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

8-×AZENDO 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 "(
(( ". 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 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

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

9-MONITORANDO A SAUDE DO HD VIA SMART

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

No Linux, este recurso é disponibilizado através do "



", um pacote disponível
nos repositórios da maioria das distribuições.
O smartmontools é baseado no "smartsuite", um pacote mais antigo, que ainda é ncluído em
algumas distribuições (como no Debian), mas que oferece menos funções e não é mais
desenvolvido ativamente.

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.