Prima di tutto, non fare nulla di più sul disco (almeno non scrivergli mai ). Il disco non riconosciuto (invece di "essere riconosciuto e trovato vuoto o con dati illeggibili") sembra indicare un disco completamente distrutto, cosa che chkdsknon è da fare, o qualcosa di sbagliato nella tabella delle partizioni o nella geometria del disco o il modo in cui la custodia USB lo gestisce. È anche possibile un errore hardware.
Questo può e succederà quando i contenitori USB tentano di negoziare tra il disco e il computer a cui sono collegati. Quindi la prima cosa da fare sarebbe prendere un'immagine del disco su un disco (ovviamente più grande) al livello più vicino possibile al fisico, usando ddsotto Linux. Quindi puoi giocherellare con una copia dell'immagine per il contenuto del tuo cuore, senza il rischio di ulteriori danni al disco reale.
Aggiornamento: riconoscimento del dispositivo in Linux
Abbiamo non meno di tre entità nel nostro "disco esterno". L'hardware del contenitore USB, esposto come un dispositivo a blocchi. Il disco fisico all'interno del contenitore. Il dispositivo fisico, ovvero la sequenza dei settori LBA dal primo all'ultimo. E infine zero o più partizioni di dati, che ospitano i file system. Per essere "riconosciuti" e visualizzati su un desktop, tutti i collegamenti delle catene devono funzionare. Ma per scattare un'immagine del dispositivo fisico sono necessari solo i primi due. Se colleghi il dispositivo ed esegui la riga di comando dmesg(come root), dovresti vedere qualcosa del genere:
[4984939.028491] usb 8-6: new high speed USB device using ehci_hcd and address 3
[4984939.166658] usb 8-6: configuration #1 chosen from 1 choice
[4984939.170660] scsi7 : SCSI emulation for USB Mass Storage devices
[4984939.172003] usb-storage: device found at 3
[4984939.172005] usb-storage: waiting for device to settle before scanning
... che è il recinto che viene riconosciuto e quindi identifica se stesso e il suo contenuto:
[4984939.170660] usb 8-6: New USB device found, idVendor=1058, idProduct=1021
[4984939.170660] usb 8-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[4984939.170660] usb 8-6: Product: Ext HDD 1021
[4984939.170660] usb 8-6: Manufacturer: Western Digital
[4984939.170660] usb 8-6: SerialNumber: 574D43305431303831303734
[4984944.400970] usb-storage: device scan complete
Successivamente vedrai il driver che informa della sua geometria, natura e implicitamente il suo nodo del dispositivo, qui sdd(per SCSI Disk Four, da allora sda, sdbe sdcsono già stati presi):
[4984944.404739] scsi 7:0:0:0: Direct-Access WD Ext HDD 1021 2021 PQ: 0 ANSI: 4
[4984944.404739] sd 7:0:0:0: [sdd] 1953519616 512-byte hardware sectors (1000202 MB)
[4984944.407367] sd 7:0:0:0: [sdd] Write Protect is off
[4984944.407369] sd 7:0:0:0: [sdd] Mode Sense: 17 00 10 08
[4984944.407371] sd 7:0:0:0: [sdd] Assuming drive cache: write through
[4984944.408741] sd 7:0:0:0: [sdd] 1953519616 512-byte hardware sectors (1000202 MB)
Quindi il kernel riconosce che esiste una partizione (se non la vedi, la partizione non è presente o non è valida):
[4984944.411497] sdd: sdd1
Ora Linux ha tutto ciò di cui ha bisogno e riporta un allegato riuscito:
[4984944.416739] sd 7:0:0:0: [sdd] Attached SCSI disk
[4984944.416739] sd 7:0:0:0: Attached scsi generic sg4 type 0
E così inizia la ricerca della partizione dati, ovvero OK, abbiamo sdd1, ma cosa c'è lì? e la risposta è:
[4984997.498613] NTFS driver 2.1.29 [Flags: R/W MODULE].
[4984997.554613] NTFS volume version 3.1.
[4984997.568859] NTFS-fs error (device sdd1): load_system_files(): $LogFile is not clean. Mounting read-only. Mount in Windows.
[4985390.027808] NTFS-fs error (device sdd1): ntfs_remount(): Volume has errors and is read-only. Cannot remount read-write.
[4985442.423299] NTFS volume version 3.1.
[4985442.425032] NTFS-fs error (device sdd1): load_system_files(): $LogFile is not clean. Mounting read-only. Mount in Windows.
Questa sopra era una "buona" cavalcatura. Ma solo sapere che il dispositivo è sdd, o sdco sdb, mi permette di fare una copia binaria (supponendo che abbia abbastanza spazio libero su /mnt/backupdisk): file di input /dev/sdd, file di output DiskImage.raw, dimensione del blocco 1 MB :
# dd if=/dev/sdd of=/mnt/backupdisk/DiskImage.raw bs=1M
Si noti che il file di input è /dev/sdd e non /dev/sdd1
(o qualsiasi altro numero). Ora, se avessi voluto, avrei potuto scoprire l'offset della partizione dati all'interno DiskImage.rawe montarla con l'aiuto di un dispositivo loop. Qui troverai i dettagli sporchi.
Primo tentativo di recupero
La seconda cosa da fare sarebbe inserire il disco fisico in un altro contenitore, assicurando così che il contenitore sia buono e avere la possibilità che il nuovo contenitore interpreti correttamente il disco. Se il disco riappare, potrebbe essere stato il contenitore precedente a essere rotto. Nel caso, esegui il backup di tutti i contenuti dell'unità ritrovata, verifica il backup, azzera il disco con un'utilità di sovrascrittura del disco in modo che diventi completamente stupido (non puoi avere due dispositivi con opinioni diverse in una catena di dispositivi), riformattarlo nativamente da Windows e ripristinare i dati. È uno scatto fortunato, ma l'ho visto accadere; e il tentativo non è troppo costoso, buoni contenitori per circa $ 19,99 nuovi.
Nel caso in cui l'involucro originale fosse danneggiato, non sarà possibile riformattare il disco o il disco non sarà accessibile. Puoi riprovare il nuovo recinto e, se funziona, sostituire il vecchio recinto o continuare a utilizzare il nuovo (ma questo vale la pena se il nuovo recinto è piuttosto migliore di un El Cheapo da $ 19,99).
Recupero professionale
Servizi di recupero professionali, quelli che puoi trovare con Google. Un modo non troppo onesto di procedere sarebbe inviare sul disco fisico e, nel caso in cui si ottenga un "Sì, non ci sono danni all'hardware e possiamo recuperare tutti i tuoi dati per soli $ US $, $ $$!" risposta - beh, allora sapresti che i dati erano ancora recuperabili. Quindi potresti provare a farlo da solo gratuitamente sul backup dell'immagine che hai eseguito e pagare solo la diagnosi e il disco S&H. Se hai fallito, l'opzione di tossire l'impasto richiesto sarebbe ancora lì. Se non v'è un danno hardware, il servizio professionale è fondamentalmente la vostra unica opzione. Esistono diversi trucchi voodoo che ripristineranno (temporaneamente) un disco "morto", spesso abbastanza a lungo per recuperare almeno i dati più importanti,nessuno è garantito per funzionare ogni volta (riscaldando il disco, raffreddandolo, "volteggiandolo" - ho persino visto suggerito di rapparlo con intelligenza contro una superficie dura). Tutti loro faranno più danni, vale a dire, devi essere sicuro di usare l'unico trucco che funzionerà la prima volta, o avrai ucciso il disco per sempre. Ho appena aggiunto questo per spiegare perché vedrai storie di successo sui dischi rianimati: ci sono storie del genere. Ma se vuoi essere (per lo più) sicuro che accadrà a te , assumi un professionista.
Se sei sicuro che l'hardware sia OK - giri del disco, nessun sonaglio, nessun suono o ronzio strano, nessuna ricalibrazione di clacson - quindi "tutto" quello che è successo è che ha chkdskincasinato alcuni dati.
Recupero fai da te
Il ripristino "Home" di solito andrebbe così (sostanzialmente la stessa cosa che farebbero i professionisti dopo che il danno hardware è stato scontato), lavorando sulla copia dell'immagine del disco:
controlla se il primo settore dell'immagine del disco è una tabella delle partizioni valida. In caso contrario, scansionare l'immagine del disco alla ricerca di una tabella delle partizioni valida o di un settore di avvio riconoscibile NTFS o FAT32, a seconda di quale FS fosse presente sull'unità (per un'unità da 1 TB, NTFS sembra l'unica possibilità logica). Ad ogni modo, dovresti trovare qualcosa nei primi megabyte.
se viene trovata la tabella delle partizioni, verificare che la partizione dati sia dove la tabella delle partizioni dice che dovrebbe essere. In caso contrario, questa è un'ottima notizia: probabilmente la tabella delle partizioni è tutto ciò che è sbagliato. Risolvere il problema è semplice (diversi editor di partizioni Linux lo faranno) e ci si può aspettare che il disco abbia un recupero del 100%. Solo per essere al sicuro, prova a montare la partizione dati in Linux con un dispositivo loop in modalità di sola lettura per vedere se è leggibile. In tal caso, il borking della partizione è confermato e il disco potrebbe essere pronunciato sulla sua strada per un recupero sicuro e completo. In caso contrario, probabilmente la partizione è corretta e una (parte di) una partizione di dati è stata riscritta. Questo non va bene; vedi sotto sotto "le cose vanno male".
se viene trovato e valido, verificalo con la geometria dell'unità e, se non corrispondono, è anche una buona cosa, dal momento che potresti aver trovato la causa principale del problema. È possibile forzare la geometria fisica nel kernel (e ottenerla all'avvio di Linux ). Verifica se la nuova geometria porta al riconoscimento del disco in Linux. In tal caso, eseguire il backup dei dati, verificare che il backup sia corretto e azzerare il disco con dd( sdsono sufficienti un paio di megabyte di zero sul dispositivo appropriato ). Spegni il computer (non solo riavviare; OK, è paranoico, ma costa poco e può realizzare qualcosa), quindi avviare Windows e farlo formattare il disco ormai privo di conoscenza in quello che pensa sia il formato migliore. Ciò garantisce che non vi siano conflitti con Windows. Ripristina i dati sul disco. Godere.
se il trucco della geometria non funziona, o la partizione non può essere trovata, o una volta trovata sembra vuota, le cose vanno male. È necessario uno strumento di recupero in grado di scansionare l'immagine del disco alla ricerca delle aree dati (MFT, ecc.) Dei dati persi. E una volta trovato, interpretali per ottenere i dati. Questo è un lavoro difficile e non può sempre essere completamente automatizzato. A un livello più basso e più disperato, ciò comporta la ricerca delle firme dei singoli file, nella speranza che si trovino in blocchi contigui nel disco. Tuttavia, questo tipo di operazione lascerei volentieri ai professionisti. L'ho fatto più volte, sempre con successo, con vecchi dischi FAT. L'ho fatto di nuovo, circa il 50% con successo, con dischi FAT32 più recenti, più grandi e più frammentati. Ci ho provato un paio di volte, con scarsi risultati (ma ho avuto backup completi e non mi davo davvero tutto), sui filesystem NTFS ed ext4 molto più complicati.
Ripristino manuale da Linux
OK, quindi provi a montare la partizione in Linux e ottieni errori ( notalo /dev/sdc e sono cose diverse - l'immagine si riferisce a )./dev/sdcN /dev/sdc
# mount -t ntfs /dev/sdc1 /mnt/recovery
ntfs_mst_post_read_fixup_warn: magic: 0x00000000 size: 1024 usa_ofs: 0 usa_count: 65535: Invalid argument
Record 1 has no FILE magic (0x0)
Failed to open inode $MFTMirr: Input/output error
... questo sembra indicare che la partizione, come ritiene il sistema , sia errata o gravemente danneggiata. Diamo un'occhiata prima alla prima opzione:
# fdisk /dev/sdc
Ottieni qualcosa del genere:
Disk /dev/sdc: 1000.2 GB, 1000204885504 bytes
1 heads, 63 sectors/track, 31008335 cylinders, total 1953525167 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9d2b7596
Device Boot Start End Blocks Id System
/dev/sdc1 63 1953520127 976760032+ 7 HPFS/NTFS/exFAT
Il prossimo passo sarà controllare l'inizio effettivo della partizione. Cercando nel file di immagine (o /dev/sdc) cercheremo la firma NTFS:
00000000:EB 52 90 4E 54 46 53 20 -20 20 20 00 02 08 00 00 .R.NTFS ........
00000010:00 00 00 00 00 F8 00 00 -3F 00 FF 00 3F 00 00 00 ........?...?...
00000020:00 00 00 00 80 00 80 00 -4A F5 7F 00 00 00 00 00 ........J.......
# dd if=/dev/sdc bs=512 count=1 skip=63 2>/dev/null | hexdump -C | head -n 1
... con i dati sopra ci aspettiamo che l'avvio NTFS sia nel settore 63, ecco perché abbiamo impostato skip. Inoltre, proveremo con ogni settore nel primo (diciamo) megabyte ...
# dd if=/dev/sdc bs=512 count=2000000 2>/dev/null | hexdump -C | grep "00:EB 52 90 4E 54 46 53"
... solo per essere sicuro che c'è solo un settore di avvio (mi è successo questo. Su un disco FAT32, ma comunque ) e che non ci sono errori di lettura da nessuna parte.
Il tuo risultato
00007e00 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|
è esattamente quello che ci aspetteremmo: il settore 63 fornisce un offset di 63 × 512 = 32256 = 7e00 esadecimale. Il settore di avvio NTFS è presente e la tabella delle partizioni sembra essere corretta .
Quindi ora possiamo copiare un grosso pezzo di /dev/sdc1su, diciamo, /tmp/mydisk.imge tentare di risolverlo da Linux. Ciò non danneggerà il disco fisico, che sarà comunque disponibile invariato per altri tentativi. E poiché ora sappiamo che il PT è corretto, possiamo usare /dev/sdc1per la copia e intrattenere le speranze che non potevamo prima:
# dd if=/dev/sdc1 of=/tmp/mydisk.img bs=1G count=10
...after copying 10 gigabytes...
# ntfsfix /tmp/mydisk.img
Se NTFSfix non funziona, beh, siamo nei guai. Tuttavia, ci sono utilità più accurate che possono essere provate. E se hai bisogno di recuperare file di immagine JPEG e il file system non è stato frammentato, questo può essere fatto automaticamente cercando le intestazioni JPEG. Lo stesso, quasi, vale per PDF, documenti TIFF e Office, solo che io non so come riconoscerle (per JPEG, vorrei :-)). Come opzione finale ho trovato questi ragazzi - non li conosco, non sono imparentato con loro e non accetterò alcuna colpa. Tuttavia, come vanno queste cose, il prezzo è molto ragionevole.
