Estoy en el proceso de recuperar datos de una unidad defectuosa de 1 TB (me preguntaron al respecto en¿Procedimiento para reemplazar un disco duro?). Lo he hecho ddrescuedesde un USB de rescate del sistema con un tamaño de error resultante de 557568 B en 191 errores, probablemente todos incluidos /home(supongo que lo que llama "errores" no son sectores defectuosos, sino secuencias consecutivas de ellos).
Ahora, las diversas guías que he visto sugieren hacerlo e2fscken el nuevo disco, y esperaba que de alguna manera encontrara que a algunos archivos se les habían asignado "sectores/bloques en blanco", con el fin de saber al menos qué archivos no se pudieron guardar. entero. Pero no se encontró ningún error (lo ejecuté sin -ypara asegurarme de no perderme nada). Ahora lo estoy ejecutando nuevamente con -c, pero al 95% no se encontraron errores hasta ahora; Supongo que tengo un disco nuevo con algunos archivos de apariencia normal con piezas cero o aleatorias en su interior, indetectables hasta que un día los abro con el software correspondiente, o Linux Mint los necesita.
¿Puedo hacer algo con las unidades antiguas/nuevas para obtener una lista de archivos posiblemente dañados? No sé cuántos podrían ser, ya que 191 podrían abarcar archivos, pero al menos el tamaño total no es grande; Lo que más me preocupa es una gran cantidad de fotos y videos familiares antiguos (más de 1 MB cada uno), el resto probablemente sea irrelevante o se haya realizado una copia de seguridad recientemente.
Actualización: el nuevo pase de e2fsck dio algo nuevo del cual no entiendo nada:
Block bitmap differences: +231216947 +(231216964--231216965) +231216970 +231217707 +231217852 +(231217870--231217871) +231218486
Fix<y>? yes
Free blocks count wrong for group #7056 (497, counted=488).
Fix<y>? yes
Free blocks count wrong (44259598, counted=44259589).
Fix<y>? yes
Respuesta1
Necesitará los números de bloque de todos los bloques defectuosos encontrados ( ddrescuedebería haberle dado una lista, espero que la haya guardado), y luego necesitará averiguar qué archivos utilizan estos bloques (ver, por ejemploaquí). Es posible que desees escribir esto si hay muchos bloques defectuosos.
e2fsckno ayuda, simplemente verifica la coherencia del sistema de archivos en sí, por lo que solo actuará si los bloques defectuosos contienen información "administrativa" del sistema de archivos.
Los bloques defectuosos en los archivos simplemente estarán vacíos.
Editar
Ok, averigüemos el tamaño del bloque. Hagamos un sistema de archivos de prueba con bloques de dispositivos de 512 bytes:
$ dd if=/dev/zero of=fs bs=512 count=200
$ /sbin/mke2fs fs
$ ll fs
-rw-r--r-- 1 dirk dirk 102400 Apr 27 10:03 fs
$ /sbin/tune2fs -l fs
...
Block count: 100
...
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Entonces, el tamaño del bloque del sistema de archivos es 1024 y tenemos 100 de esos bloques del sistema de archivos (y 200 bloques de dispositivos de 512 bytes). Rescátalo:
$ ddrescue -b512 fs fs.new fs.log
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued: 102400 B, errsize: 0 B, current rate: 102 kB/s
ipos: 65536 B, errors: 0, average rate: 102 kB/s
opos: 65536 B, run time: 1 s, successful read: 0 s ago
Finished
$ cat fs.log
# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue fs fs.new fs.log
# Start time: 2017-04-27 10:04:03
# Current time: 2017-04-27 10:04:03
# Finished
# current_pos current_status
0x00010000 +
# pos size status
0x00000000 0x00019000 +
$ printf "%i\n" 0x00019000
102400
Entonces, las unidades hexadecimales ddrescueestán en bytes, no en bloques. Finalmente, veamos qué debugfsusos. Primero, cree un archivo y busque su contenido:
$ sudo mount -o loop fs /mnt/tmp
$ sudo chmod go+rwx /mnt/tmp/
$ echo 'abcdefghijk' > /mnt/tmp/foo
$ sudo umount /mnt/tmp
$ hexdump -C fs
...
00005400 61 62 63 64 65 66 67 68 69 6a 6b 0a 00 00 00 00 |abcdefghijk.....|
00005410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Entonces la dirección de bytes de los datos es 0x5400. Convierta esto en bloques de sistema de archivos de 1024 bytes:
$ printf "%i\n" 0x5400
21504
$ expr 21504 / 1024
21
y probemos también el rango de bloques mientras estamos en ello:
$ /sbin/debugfs fs
debugfs 1.43.3 (04-Sep-2016)
debugfs: testb 0
testb: Invalid block number 0
debugfs: testb 1
Block 1 marked in use
debugfs: testb 99
Block 99 not in use
debugfs: testb 100
Illegal block number passed to ext2fs_test_block_bitmap #100 for block bitmap for fs
Block 100 not in use
debugfs: testb 21
Block 21 marked in use
debugfs: icheck 21
Block Inode number
21 12
debugfs: ncheck 12
Inode Pathname
12 //foo
Eso funciona como se esperaba, excepto que el bloque 0 no es válido, probablemente porque los metadatos del sistema de archivos están ahí. Entonces, para su dirección de bytes 0x30F8A71000de ddrescue, suponiendo que trabajó en todo el disco y no en una partición, restamos la dirección de bytes del inicio de la partición.
210330128384 - 7815168 * 512 = 206328762368
Divida eso por el tune2fstamaño del bloque para obtener el bloque del sistema de archivos (tenga en cuenta que, dado que varios bloques físicos, posiblemente dañados, forman un bloque del sistema de archivos, los números no necesitan ser múltiplos exactos):
206328762368/4096 = 50373233,0
y ese es el bloque con el que debes probar debugfs.
Respuesta2
NTFS, ext3, ext4
Después de copiar los datos de su unidad defectuosa con ddrescue, useddrutilitypara encontrar los nombres de archivos afectados.
Conseguí que enumerara los archivos NTFS afectados en una partición de 1 TB con un ddrescuearchivo de mapa en menos de 20 segundos.
Escribe su archivo de registro en el directorio actual.
La página vinculada menciona soporte para NTFS, ext3 y ext4.
btrfs, zfs
Estos sistemas de archivos tienen su propia función incorporada scrub.
Respuesta3
Recomendaría una utilidad ya implementada llamada ddrutility. Eso eliminaría los tediosos cálculos manuales.
Deberías ejecutarlo en tu clonado.Copiar(no el original) dispositivo de unidad así:
ddru_findbad /dev/sdb /ddrescue-disk-copy.map
El uso del archivo de mapa (segundo argumento) es obligatorio aquí.
La utilidad es bastante inteligente, admite diferentes sistemas de archivos (incluso NTFS) y también tiene la funcionalidad de probar sectores erróneos aún por dividir (marcándolos como temporales incorrectos), por lo que debería poder estimar si necesita todo el ddrescueprocedimiento . por terminar. También tenga en cuenta que /dev/sdbaquí se utiliza como un disco completo (no como una partición como /dev/sdb1), ya que todo el disco se clonó originalmente.
La utilidad está disponible en los repositorios de Debian y se puede instalar con:
sudo apt install ddrutility
La wiki del proyecto:https://sourceforge.net/p/ddrutility/wiki/Home
Respuesta4
Utilicé Filezilla simple y solucioné mi problema. Utilice Filezilla normal para hacer una copia de seguridad de todos los datos buenos. Noto que un archivo grande no se estaba copiando correctamente (deteniéndose en el medio y reiniciando la transferencia). Por suerte tengo una copia de seguridad anterior del mismo archivo. Para duplicar el disco, tuve que encontrar los bloques defectuosos en el disco usando este procedimiento:
Primero, descubra el disco problemático identificando la información HD usandofdisk-l
Segundo, si digamos que su disco es/dev/sdbentonces necesitas ejecutar el comando bloques malos -v /dev/sdbenumerará todos los bloques defectuosos en el disco. Por suerte serán unos cuantos. Si no se encuentran bloques defectuosos, entonces los bloques de su unidad están bien y necesitan resolver algo más. El tamaño de mi bloque es 512, así que uso ese número predeterminado para ejecutar DD
El tercero, cada bloque tiene un tamaño de 512, así que lo que hice fue establecer bs=512
Cada vez que ejecuto DD regularmente como siempre lo hago, mis datos, después de los errores, saldrán dañados. Entonces uso los parámetros como se explica en la página.https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.htmlbusque la parte "Para discos defectuosos".
dd if=/dev/sdb of=/dev/sda bs=512 conv=noerror,sync iflag=fullblock
Se tomó un tiempo. Cada bloque defectuoso encontrado suena como un golpe en la unidad defectuosa. Copia bloque por bloque y, a través de todos mis bloques defectuosos, hace el mismo ruido. La cantidad de veces que hizo ruido se debió a que encontró otro bloque defectuoso y le informa sobre un mensaje de error en la pantalla. Que'conv=sin error,sincronización'lo que hace es rellenar las malas lecturas con NUL, mientras que'iflag=bloque completo'atiende a lecturas breves, pero mantiene sincronizados sus datos hasta el final. No hay ningún daño, simplemente no copia los bloques defectuosos y los llena con NUL vacíos.
Una vez realizada la copia con DD, simplemente reemplacé ese archivo defectuoso, revirtiendo Filezilla de una copia de seguridad anterior y todo funcionó bien. Espero que esto sea útil para otras personas que intentan realizar copias de seguridad de unidades defectuosas.
NOTA: Mis bloques defectuosos estaban bastante cerca uno del otro. Aproximadamente 4 cuadras a la vez juntas en grupos donde se detectó mal. Si sus bloques están por todo el disco, varios archivos podrían verse afectados. Afortunadamente, en mi caso, un archivo de 4 GB de base de datos grande solo se vio afectado.