Em Dom, 2007-05-13 às 11:03 -0300, Joao Emanuel escreveu: > Em 11/05/07, Fernando Faria Mariano<[EMAIL PROTECTED]> escreveu: > > > > 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<[EMAIL PROTECTED]> 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 > > > > > > > > Fernando só um alerta, o hamacker não está comentando sobre o rsync, > mas sim sobre a flag sync que tem no NFS para fazer a sincronia entre > os dispositivos, ok? >
Ok, atualmente estou usando async... qual seria melhor no ponto de vista de confiança no backup? sync ou async? Fernando Faria
