[FUG-BR] [OFF-TOPIC] Prevenção contra arquivos apagados

[Patrick Tracanelli]

Alexandre Biancalana wrote:
> On 8/2/07, Patrick Tracanelli <eksffa em freebsdbrasil.com.br> wrote:
>> Alexandre, muito bem lembrado. Na verdade acho que é a melhor idéia até
>> o momento.
>>
>> Testei num pequeno servidor, tambem de hosting, com `iostat -w1`
>> marcando 1.3MB/s de throughput em disco (producao), deu:
>>
>> # /usr/bin/time -h mksnap_ffs /usr/home snap01
>>          47.40s real             0.00s user              0.59s sys
>>
>> O sistema de arquivos nao e grande:
>>
>> # df -h /usr/home/
>> Filesystem     Size    Used   Avail Capacity  Mounted on
>> /dev/ad0s1g     83G     25G    57G    30%    /usr/home
>>
>> Mas consideraria aceitavel, da pra fazer um snap a cada 15 minutos, sem
>> comprometer o uso em producao (um nice +20 na tarefa agendada ajudaria a
>> evitar queda de performance tambem).
>>
>> Bem pensado =)
> 
> 
> 
> Obrigado! ;-)
> 
> Só acho  vale a pena ser testado no ambiente final dele, em horário de pico,
> em fim, um "teste real", eu nunca usei snapshot desta forma, mas nas listas
> la fora teve gente reclamando de "congelamento" momentaneo do SO durante o
> snapshot em versões passadas (final do ano passado), e o Kris Kennaway
> comentou na época que isso poderia mesmo acontecer.

Sem duvida. Eu tenho problema de congelamento com dump -L por exemplo, 
em producao. Porem, se o sistema de arquivos nao for muito grande ou o 
uso em producao tambem nao, muda muito o comportamento. Isso porque o 
acesso a disco ainda nao pode ser controlado como prioridade no 
escalonador por exemplo, entao um processo de baixa prioridade pode 
gerar acesso em disco maior que outros, ao ponto de prejudicar os mais 
privilegiados.

O ideal seria uma forma de definir prioridade de operacao em disco. O 
PJD comentou sobre estar implementando isso como modulo geom, mas nao 
sei da "prioridade" disso pra esse desenvolvedor.

> Silmar, testa ai e fala pra gente se funcionou, se puder com alguns detalhes
> de tamanho do filesystem, tempo de execuçao, etc...

Tamanho do FS, metodo de acesso a disco e vazao em producao, vao fazer a 
diferenca entre a viabilidade ou nao. Senao, implementar na aplicação 
volta a ser a opcao.

> 
> Eu tenho a idéia de implementar isso nos novos servidores de arquivos aqui
> da empresa, pois está cada vez mais frequente os cabecinhas
> apagarem/alterarem oque não devem e ficarem pedindo pra restaurar planilhas,
> etc... só não testei... teremos pelo menos 2 servidores com 2 TB cada um...

Desse tamanho, acho que fora do horario comercial soh. E' servidor de 
arquivos com o que? Samba tem o vfs recycle que gera a lixeira (com 
politica configuravel) e appletalk tem o drestore, menos flexivel que o 
recycle do samba mas ainda assim funcional. Se for NFS, bom, ai so com 
coisa experimental (NFS4 com o "newnfsd" permite chamar scripts externos 
pra certos tipos de operacoes).

> 
> Alexandre
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


-- 
Patrick Tracanelli

FreeBSD Brasil LTDA.
(31) 3281-9633 / 3281-3547
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"