Da un settore danneggiato a un "file danneggiato" - fatto per Linux / ext3, posso farlo per Windows / NTFS?

Quando un controllo SMART su un disco segnala un settore danneggiato, è importante essere in grado di identificare il file che ha il settore danneggiato e ripristinarlo dai backup. Di seguito, mostro come ho fatto questo per il mio server VMware Linux / ext3 - ma qualcuno sa se questo può essere fatto per Windows / NTFS?

Ecco come l'ho fatto per Linux / ext3: per prima cosa ho chiesto all'unità di eseguire una scansione della superficie dell'hardware (sotto il livello del sistema operativo, con i circuiti SMART sull'unità):

vserver:~# smartctl -t long /dev/sdc

Ho guardato i risultati:

vserver:~# smartctl -a /dev/sdc
...
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       1
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       9
...
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     27679         591363172

Quindi, un settore era già contrassegnato come non valido, 9 erano contrassegnati per essere sostituiti dallo spazio del settore "stadiazione". Ancora più importante, il primo indirizzo di blocco logico (LBA) che è illeggibile, era 591363172.

Ho trovato la partizione (e l'offset al suo interno) che questo numero ha "tradotto" in:

vserver:~# fdisk -lu /dev/sdc
Device Boot      Start         End      Blocks   Id  System
/dev/sdc1           32   976773119   488386544   83  Linux

La partizione è iniziata nel settore 32. Quindi, il settore danneggiato era ...

vserver:~# bc -l
591363172-32+1
591363141

... con un offset di 591363141 settori dall'inizio della partizione.

Ora sono riuscito a trovare quale file è stato "hosed":

vserver:~# tune2fs -l /dev/sdc1 | grep Block\ size
Block size:               4096

La dimensione del blocco di questo filesystem EXT3 era 4096 byte, quindi il settore danneggiato ha distrutto questo blocco nel filesystem:

vserver:~# bc -l
591363141*512/4096
73920392.62500000000000000000

E il numero di blocco (73920392) corrispondeva a questo file:

vserver:~# debugfs
debugfs 1.41.3 (12-Oct-2008)
debugfs:  open /dev/sdc1
testb 73920392
debugfs:  testb 73920392
Block 73920392 marked in use
debugfs:  icheck 73920392
Block           Inode number
73920392        18472967
debugfs:  ncheck 18472967
Inode           Pathname
18472967        /path/to/filewithbadsector

E ho ripristinato quel file dai miei backup.

Esiste una procedura equivalente che posso seguire per Windows / NTFS?

— ttsiodras
fonte

Cordiali saluti: l'attuale conteggio in sospeso di 9 significa che ci sono 9 settori danneggiati, non solo uno. L'autotest esteso si interrompe appena al primo rilevato. Prima di eseguire il ripristino dal backup, è necessario gestire anche il settore danneggiato scrivendogli degli zeri dd. Ciò costringerà l'unità a ripararla o riallocarla.

— psusi,

Sì, hai ragione. Dopo il ripristino, ho fatto un altro controllo SMART e ho scoperto che tutto era OK, quindi la scrittura del file apparentemente ha scritto sui settori danneggiati 9 + 1 (e l'area di gestione temporanea ha fornito sostituti). Ma per quanto riguarda Windows? :-)

— ttsiodras,

Penso che il tuo calcolo per l'offset del settore in una partizione sia errato. I numeri di settore (altro che fisico, noto anche come CHS) sono tutti a base zero, poiché il settore 32 è il settore di partizione 32-32 == 0, non 1.

Incredibilmente nessuno lo ha ancora detto su una domanda di un anno o più: quando inizi a vedere settori danneggiati sul disco, significa che hai così tanti rimappature interne automatiche del blocco difettoso del disco che non possono più compensare. Invece di ripristinare dai backup su un'unità morente, è necessario sostituire l'unità e ripristinare la nuova unità.

— voretaq7,

So che hai un FS NTFS ed esegui Windows su quel FS. Non so se "potresti" avviare un live Linux per funzionare su quel driver o no.

Se è possibile avviare Linux da CD o USB, è possibile utilizzare ntfsprogs. guarda a -

ntfscluster 

ntfsinfo

Credo che ntfscluster ti dica quale file memorizza un determinato cluster. Spero che questo ti metta nella giusta direzione.

— JM Becker
fonte

Ho trovato questo post sul forum che ha un wrapper di utilità per farlo su diversi filesystem e usa anche ntfscluster. ubuntuforums.org/showthread.php?t=1943721

— Lethargy

Sì, funzione ddrutility: trova i file relativi a settori danneggiati, può anche utilizzare un file con un elenco di settori, forse potremmo usare "badblocks -nvs" + "ddrutility"

— diyism