Tengo 3 discos duros, en los siguientes párrafos llamados /dev/sda, /dev/sdb y /dev/sdc, el más nuevo fue primero. Nota: /dev/sdc tiene una partición primaria /dev/sdc1, una partición extendida /dev/sd2 y 3 particiones lógicas /dev/sdc5, /dev/sdc6 y /dev/sda7.
Creé un dispositivo RAID 5 degradado /dev/md0 con /dev/sda5 y /dev/sdb5 (planeé agregar /dev/sdc5 al RAID para volverlo al estado normal), luego usé /dev/md0 como único pv de LVM y creó un lv con el sistema de archivos ext4 /dev/mapper/vg0-lv0.
Desafortunadamente, al explorar y jugar con LVM, ejecuté dd if=/dev/zero of=/dev/sdc1 bs=64M count=10después de eliminar /dev/sdc1. Entonces, en realidad, los ceros se escribieron en /dev/sdc2 y la parte rota de la tabla de particiones se almacenó en /dev/sdc2 y la parte inicial de /dev/sdc5.
Cuando me di cuenta de esto, inmediatamente hice una imagen de /dev/sdc a través de dd como esta: dd if=/dev/sdc of=/mount-point-of-vg0-lv0/sdc.img.
Varios días después, finalmente tengo tiempo para intentar recuperar los datos en /dev/sdc, en realidad solo /dev/sdc7 ya que es la única partición sin respaldo. Ejecuté testdisk con el archivo de imagen sdc.img, utilicé su función de búsqueda rápida para reconstruir la tabla de particiones y la configuré en /dev/loop0. /dev/loop0p7 (que es la imagen de /dev/sdc7) estaba nuevamente y se podía montar, y todos los archivos parecen estar bien. Luego corrí find /mount-point-of-loop0p7 -type f -exec md5sum {} \; > sdc7_img.md5sumpara crear una lista de suma de verificación MD5 para todos los archivos en /dev/loop0p7.
Cuando se trata del dispositivo físico /dev/sdc, la búsqueda rápida de testdisk no encuentra todas las particiones, la búsqueda profunda sí lo hace. Luego construí la lista de suma de verificación MD5 sdc7.md5sum para todos los archivos en /dev/sdc7 físico con un comando similar. Cuando lo comparé con sdc7_image.md5sum, encontré 4 archivos diferentes. Después de compararlos manualmente, noté que cada archivo solo tiene 1 byte de diferencia. Y debido a que un archivo tiene CRC32 en su nombre, puedo confirmar que el del archivo físico /dev/sdc7 es correcto.
Entonces mi pregunta es, ¿por qué sucedió esto tan extraño? Ya corrí fsck.ext4 -c -c /dev/mapper/vg0-lv0para confirmar que no tiene bloques defectuosos. Las diferencias de 4 bytes en datos de 1,2 TB son un porcentaje muy pequeño, pero esto me hace no tener confianza en almacenar datos en /dev/mapper/vg0-lv0 en el futuro.
Actualización: debo mencionar que todas las operaciones se realizaron en la última versión de ArchLinux ejecutándose en VirtualBox 4.1.16, que se ejecuta en Windows 7. /dev/sda, /dev/sdb y /dev/sdc están todos vinculados con discos duros físicos. a través de VBoxManage internalcommands createrawvmdk. VirtualBox solo ha informado el error VERR_ACCESS_DENIED durante las sumas md5 realizadas para /dev/sdc7 físico, después de desconectar el disco físico a través diskpartde Win7, no se generaron más errores.
Respuesta1
Hay un par de cosas que podrían haber pasado. Primero, no mencionaste desmontar sdc7 antes de crear la imagen del disco, por lo que podría ser que los datos se estuvieran escribiendo en ese momento. Sin embargo, supongo que ese no fue el caso, o no lo preguntarías. No me puedo quejar de tu reacción de "primero, crear una imagen del disco", es una reacción bastante buena. Aunque observo que antes de reiniciar, el kernel todavía tenía la tabla de particiones en la memoria, verifique /proc/partitions.
Lo primero que hay que comprobar es si hay errores de memoria. Podrías tener mala RAM. Sin duda, sus datos pasaron por la RAM varias veces. Supongo que no tienes memoria ECC, lo que probablemente detectaría esto.
Los discos duros también tienen errores. Al buscar una hoja de especificaciones para algunos discos duros de consumo aleatorios, dicen 1 por 100 Tbit. Copiaste 1,2 TB al menos varias veces (leído desde el origen, leído desde el destino), por lo que es algo así como 19 Tbit de lectura. Tener un pequeño error en eso es creíble. (Desafortunadamente, no dan una tasa de error para las escrituras en las hojas de especificaciones).
¿Hubo alguna rima o razón detrás de las corrupciones de un solo byte? cmp -lPuede indicarle los bytes que varían. Por ejemplo, si siempre fuera el mismo desplazamiento en una página (el tamaño de su página probablemente sea 4K) y siempre el mismo bit, eso indicaría casi de manera concluyente que la RAM es defectuosa. Incluso si siempre es el mismo bit o el mismo desplazamiento, eso sería bastante concluyente (¿Y tenía CRC32 para los cuatro archivos, o solo uno?)