Obrigado cara... vou procurar algumas opções de montagem pra ver se consigo
deixar esse backup mais estavel...
ou talvez utilizar estas ferramentas... como o rsync q vc citou...
Em Sex, 2007-05-11 às 13:19 -0300, hamacker escreveu:
Não sei se foi DHCP, provavelmente não.
Mas pode ter caído momentaneamente sua rede, ou a placa de rede
pipocou por alguns instantes no lado server/client causando
instabilidade na rede NFS e o backup foi para as "cucuias".
Não gosto muito do NFS por causa disso, talvez com algumas opções
extras na montagem ele funcione melhor, mas nas opções simples de
montagem ele é muito sensivel à rede. Após perder muito backup em
discos USBs eu aprendí a usar a opção de montagem "sync" que apesar de
tornar o backup mais lento na unidade USB, tornou bem (e bota "bem"
nisso) confiável o backup, talvez no NFS seja a mesma coisa, basta
descobrir algum parametro na montagem que torna-o menos sensivel à
rede.
Também faço backup remoto, mas neste caso tenho usando o rsync e o
sshfs+tar.gz
A proposito o bzip(tar -j) é isso mesmo, ele estrangula a CPU. Ou voce
usa um nice com prioridade mais baixa ou troca por gzip (tar -z). A
diferença é pouca se voce levar em conta que o bzip demora muito para
ganhar talvez nem 1%.
Em 11/05/07, Fernando Faria Mariano<fernando@kachan.com.br> escreveu:
>
> Bom dia.
>
> A minha rotina de backup de meu servidor de arquivos está da seguinte
> forma. Ela é executada todas as madrugadas.
>
> tar jcvpf /compartilhamento/nfs/em/outro/servidor
> /diretorio/de/origem
>
> tenho este script para várias pastas, e todo dia quando chego pela manhã
> todo o backup já foi realizado com sucesso. Mas hoje na segunda pasta a
ser
> realizado o backup, especificamento a pasta (/var), o programa bzip2 usado
> para compactação estava travado com uso de aproximadamente 95% da cpu e
> aumentando a carga do sistema.
> O micro onde está sendo realizada a cópia de segurança obtem seu endereço
> ip apartir de meu servidor de arquivos (que é a máquina que está
executando
> o script de backup citado acima que travou o bzip2 e apresentou carga
alta)
> Procurei nos logs do servidor onde está ativo o compartilhamento nfs e
> encontrei uma mensagem suspeita sobre o obtenção do endereço por dhcp.
Segue
> alguns logs abaixo...
>
>
> (todos os logs abaixo foram retirados da máquina onde está ativo o
> compartilhamento nfs).
> /var/log/daemon.log
> May 11 05:00:09 ka006 dhclient: DHCPREQUEST on eth0 to 192.169.3.2 port 67
> May 11 05:00:09 ka006 dhclient: DHCPACK from 192.169.3.2
> May 11 05:00:09 ka006 dhclient: bound to 192.169.3.6 -- renewal in 257492
> seconds.
>
> /var/log/syslog
> May 11 04:49:47 ka006 -- MARK --
> May 11 05:00:09 ka006 dhclient: DHCPREQUEST on eth0 to 192.169.3.2 port 67
> May 11 05:00:09 ka006 dhclient: DHCPACK from 192.169.3.2
> May 11 05:00:09 ka006 dhclient: bound to 192.169.3.6 -- renewal in 257492
> seconds.
>
> arquivo onde aconteceu o erro
> -rw-r--r-- 1 root root 75M 2007-05-11 05:01
> /backup/fileserver/10-05-2007/var-10-05-2007.tar.bz2
>
> Esta hora do arquivo var-10-05-2007.tar.bz2 está coincidindo com a hora em
> que a máquina renovou seu endereço ip. Será que pode ter sido está a causa
> do travamento do programa bzip2 que está sendo executado no servidor de
> arquivos? ou seja... neste pequeno intervalo de tempo da renovação ouve
uma
> queda de conexão o e progrmaa travou??? ou isto é apenas coincidencia...
>
> pergunto isto, porque certa vez li que o protocolo dhcp ao chegar no meio
> do periodo de sua concessão renova sua concessão automaticamente...
fazendo
> com que não exista queda de conexão...
>
> obs: após ter detectado que o programa bzip2 estava travado finalizei-o
com
> o comando kill e enviando o sinal 9. Depois disso todo o script está sendo
> executado sem problemas...
>
>
> Agradeço desde já a atenção de todos...
> Fernando Faria Mariano