Eu tenho 3 discos rígidos, nos parágrafos seguintes chamados /dev/sda, /dev/sdb e /dev/sdc, o mais novo veio primeiro. Nota: /dev/sdc tem uma partição primária /dev/sdc1, uma partição estendida /dev/sd2 e 3 partições lógicas /dev/sdc5, /dev/sdc6 e /dev/sda7.
Criei um dispositivo RAID 5 degradado /dev/md0 com /dev/sda5 e /dev/sdb5 (planejei adicionar /dev/sdc5 ao RAID para colocá-lo no estado normal) e usei /dev/md0 como o único pv do LVM e criei um lv com sistema de arquivos ext4 /dev/mapper/vg0-lv0.
Infelizmente, ao explorar e brincar com o LVM, corri dd if=/dev/zero of=/dev/sdc1 bs=64M count=10após excluir /dev/sdc1. Então, na verdade, os zeros foram gravados em/dev/sdc2 e parte quebrada da tabela de partição armazenada em/dev/sdc2 e a parte inicial de/dev/sdc5.
Quando percebi isso, imediatamente criei uma imagem de /dev/sdc via dd assim: dd if=/dev/sdc of=/mount-point-of-vg0-lv0/sdc.img.
Vários dias depois, finalmente tenho tempo para tentar recuperar os dados em/dev/sdc, na verdade apenas/dev/sdc7, já que é a única partição sem backup. Executei o testdisk com o arquivo de imagem sdc.img, usei seu recurso Quick Search para reconstruir a tabela de partições e fiz a configuração para /dev/loop0. /dev/loop0p7 (que é a imagem de /dev/sdc7) estava de volta e montável, e todos os arquivos parecem OK. Então corri find /mount-point-of-loop0p7 -type f -exec md5sum {} \; > sdc7_img.md5sumpara construir a lista de soma de verificação MD5 para todos os arquivos em/dev/loop0p7.
Ao lidar com o dispositivo físico /dev/sdc, a Pesquisa Rápida do testdisk não encontra todas as partições, mas a Pesquisa Profunda o faz. Em seguida, criei a lista de soma de verificação MD5 sdc7.md5sum para todos os arquivos no /dev/sdc7 físico com comando semelhante. Quando comparado com sdc7_image.md5sum, descobri que 4 arquivos são diferentes. Depois de compará-los manualmente, percebi que cada arquivo tem apenas 1 byte de diferença. E como um arquivo tem CRC32 em seu nome, posso confirmar que aquele do /dev/sdc7 físico está correto.
Então, minha pergunta é: por que essa coisa estranha aconteceu? Já corri fsck.ext4 -c -c /dev/mapper/vg0-lv0para confirmar que não tem bad blocks. As diferenças de 4 bytes em dados de 1,2 TB são uma porcentagem tão pequena, mas isso me faz não ter confiança em armazenar dados em /dev/mapper/vg0-lv0 no futuro.
Atualização: Devo mencionar que todas as operações foram feitas no ArchLinux mais recente rodando no VirtualBox 4.1.16, que roda no Windows 7. /dev/sda, /dev/sdb e /dev/sdc estão todos vinculados a discos rígidos físicos, através da VBoxManage internalcommands createrawvmdk. O VirtualBox relatou apenas o erro VERR_ACCESS_DENIED durante md5sums feitos para /dev/sdc7 físico, após offline o disco físico via diskpartWin7, nenhum erro adicional foi gerado.
Responder1
Há algumas coisas que poderiam ter acontecido. Primeiro, você não mencionou a desmontagem do sdc7 antes de criar a imagem do disco, então pode ser que os dados estivessem sendo gravados no momento. Vou adivinhar que não foi o caso, ou você não estaria perguntando. Não posso culpar sua reação de "primeira coisa, crie uma imagem do disco", é uma reação muito boa. Embora eu note que antes de você reiniciar, o kernel ainda tinha a tabela de partição na memória, verifique /proc/partitions.
A primeira coisa a verificar é se há erros de memória. Você pode ter RAM ruim. Seus dados, sem dúvida, passaram pela RAM várias vezes. Presumo que você não tenha memória ECC, o que provavelmente detectaria isso.
Os discos rígidos também apresentam erros. Procurando uma folha de especificações de alguns discos rígidos de consumo aleatórios, eles dizem 1 por 100 Tbit. Você copiou 1,2 TB pelo menos algumas vezes (lido da origem, lido do destino), então isso é algo como 19 Tbit lidos. Ter um pequeno erro nisso é verossímil. (Infelizmente, eles não fornecem uma taxa de erro para gravações nas folhas de especificações).
Houve alguma rima ou razão por trás das corrupções de byte único? cmp -lpode informar os bytes que variam. Por exemplo, se fosse sempre o mesmo deslocamento em uma página (o tamanho da página provavelmente é 4K) e sempre o mesmo bit, isso apontaria quase conclusivamente para RAM com defeito. Mesmo que seja sempre o mesmo bit ou o mesmo deslocamento, isso seria bastante conclusivo (e você tinha CRC32 para todos os quatro arquivos ou apenas um?)