Vale a pena usar o vdmfec para backups em discos rígidos SATA / IDE externos?

5

Eu tenho alguns gabinetes de disco rígido SATA / IDE que eu uso para backups. As unidades para formatadas com VFAT, já que preciso compartilhá-las com máquinas Windows e OS / X.

Os scripts de backup canalizam a saída por meio de vdmfec para fornecer correção de erros para os arquivos . (Eu comecei a fazer isso quando descobri que alguns arquivos de backup antigos estavam danificados.)

O exemplo na página de manual refere-se a discos de "disquete" de 1,44 MB. / p>

Então, minha pergunta é: vale a pena usar o vdmfec para discos rígidos (como ouvi dizer que os mais novos têm correção de erros incorporada)? E, se assim for, devo usar configurações diferentes do padrão?

Além disso: existem ferramentas melhores para o Linux do que o vdmfec para correção de erros?

    
por Rob 10.04.2011 / 13:37

1 resposta

4

Adicionar Error Correcting Codes (ECC) aos seus backups é definitivamente uma coisa boa. Você troca alguma quantidade de espaço extra para ganhar alguma robustez na forma de redundância de dados.

vdmfec parece uma boa ferramenta. Por padrão, ele assume um tamanho de bloco de b = 1024 bytes e grava N = 18 blocos para cada K = 14 blocos de entrada. Isso significa que, por padrão, o tamanho da saída é inflado por N-K = 4 blocos para cada 14 blocos, para um aumento de tamanho de aproximadamente 29%. Você pode brincar com os parâmetros K e N para obter mais ou menos redundância, embora eu ache que os padrões provavelmente são bons para a maioria dos usos.

Você precisa estar ciente de algumas dicas em potencial, no entanto. Primeiro, de acordo com a página man:

Note that the N, K, and blocksize parameters are NOT written to the output! You must specify the same parameters when you run the decoder. (Actually, the decoder is capable of explicitly detecting an invalid K value, but incorrect blocksize or N values will result in bad blocks and decode failure.)

Portanto, lembre-se de documentar os parâmetros específicos que você usa para cada um dos seus backups. Mesmo se você sempre usar os padrões, pode ser uma boa ideia documentar explicitamente esses valores, já que os padrões podem mudar em versões mais recentes do programa.

Em segundo lugar, a página man diz isso:

The decoder is capable of reading from non-seekable media such as pipes, however, buffer underruns are not detected and will result in failure. Also, when reading from a pipe the entire file must be read. Reading from a seek-able stream can be faster because only K good blocks out of N need to be read.

Isso significa que é melhor (e mais seguro) colocar vdmfec por último no pipeline de comando ao criar seus backups. Por exemplo:

tar -cf - /data | gzip | vdmfec > /backups/data.tgz.vdm

Ao fazer a codificação vdmfec por último ao fazer backup, isso significa que você pode usar o decodificador vdmfec em um arquivo pesquisável em vez de em um canal não pesquisável ao restaurar e, assim, evitar os possíveis problemas que podem surgir ao usar canos. Por exemplo:

vdmfec_decode /backups/data.tgz.vdm | zcat | tar -xf -

Em resumo, eu diria que vdmfec é uma boa ferramenta para tornar seus backups mais robustos em relação à perda de dados devido a erros causados pela degradação da mídia. Os discos rígidos de hoje estão usando densidades de bits cada vez maiores para alcançar suas capacidades cada vez maiores de vários terabytes, então acho que definitivamente vale acrescentar alguma redundância extra aos backups, apenas por segurança.

E finalmente: Outra ferramenta que tem uma função semelhante a vdmfec é par2 ( man page ), mas funciona de uma maneira totalmente diferente. par2 pode ser uma ferramenta mais adequada se você precisar split dos seus arquivos, pois par2 foi desenvolvido para adicionar ECC a arquivos grandes divididos em vários arquivos menores (por exemplo, para postar em grupos binários USENET). / p>     

por 10.04.2011 / 22:14