E' capitato ancora una volta. Qualcuno ha una pendrive che all'improvviso risulta vuota e Windows chiede se sia il caso di formattarla.
No! Alt! Stop!
Niente panico, proviamo a recuperare il contenuto
Se il danno hardware non è esteso (e spesso non lo è, anzi, mi è sempre capitato il caso che ad essere "persa" è stata la parte di disco relativa al boot sector/partition table/FAT) è possibile recuperare se non tutto almeno buona parte dei files presenti.
Ma procediamo con ordine.
No! Alt! Stop!
Niente panico, proviamo a recuperare il contenuto
Se il danno hardware non è esteso (e spesso non lo è, anzi, mi è sempre capitato il caso che ad essere "persa" è stata la parte di disco relativa al boot sector/partition table/FAT) è possibile recuperare se non tutto almeno buona parte dei files presenti.
Ma procediamo con ordine.
- Scopriamo su quale device è presente la pendrive (che ovviamente non viene montata, non potendo trovare alcun filesystem valido al suo interno).
Per prima cosa inseriamo il pendrive in una porta USB e poi da terminale diamo:
[tuxmal@work ~]# dmesg
ottenendo:
usb 1-6: new high speed USB device using ehci_hcd and address 7
usb 1-6: New USB device found, idVendor=0457, idProduct=0151
usb 1-6: New USB device strings: Mfr=0, Product=2, SerialNumber=3
usb 1-6: Product: USB Mass Storage Device
usb 1-6: SerialNumber: 73971bc79344b6
usb-storage 1-6:1.0: Quirks match for vid 0457 pid 0151: 80
scsi5 : usb-storage 1-6:1.0
scsi 5:0:0:0: Direct-Access 1.0 PQ: 0 ANSI: 2
sd 5:0:0:0: Attached scsi generic sg3 type 0
sd 5:0:0:0: [sdc] 983808 512-byte logical blocks: (503 MB/480 MiB)
sd 5:0:0:0: [sdc] Write Protect is off
sd 5:0:0:0: [sdc] Mode Sense: 00 00 00 00
sd 5:0:0:0: [sdc] Assuming drive cache: write through
sd 5:0:0:0: [sdc] Assuming drive cache: write through
sdc: unknown partition table
sd 5:0:0:0: [sdc] Assuming drive cache: write through
sd 5:0:0:0: [sdc] Attached SCSI removable disk
quindi il device è sdc. Alternativamente avremmo potuto leggere queste info con:
[tuxmal@work ~]# tail /var/log/messages - Creiamo un file contenente i dati del pendrive, per le varie prove di recupero (pendrv è il nome del file utilizzato per i test), l'opzione bs specifica la grandezza dell'intero pendrive (in questo caso 512MB):
[tuxmal@work ~]# dd bs=512M if=/dev/sdc of=./pendrv - Copiamo il file appena creato (per sicurezza, potremo ritornare sui nostri passi senza più toccare il pendrive, che anzi, rimuoviamo dalla porta USB):
[tuxmal@work ~]# cp pendrv pendrv.bkup - Adesso, passiamo all'azione, controlliamo se si riesce a leggere qualcosa all'interno del pendrive:
[tuxmal@work ~]# parted ./pendrv
Nel caso in esame non risulta presente alcuna partizione. Possiamo provare ancora così:
[tuxmal@work ~]# fdisk ./pendrv
e, poiché non otteniamo alcun risultato interessante, ancora:
[tuxmal@work ~]# fdisk -u -l ./pendrv
oppure
[tuxmal@work ~]# fdisk -l ./pendrv - Se ancora non si hanno riscontri positivi, come nel mio caso, proviamo con:
[tuxmal@work ~]# gpart -g -i ./pendrv
che continua a visualizzare partizioni errate:
Begin scan...
Possible partition(DOS FAT), size(486mb), offset(0mb)
End scan.
Checking partitions...
* Warning: partition(Primary 'big' DOS (> 32MB)) starts beyond disk end.
Partition(Primary 'big' DOS (> 32MB)): invalid primary
Ok.
Guessed primary partition table:
Primary partition(1)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(2)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(3)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(4)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r - Proviamo comunque a montare il nostro pendrive:
[tuxmal@work ~]# mount -t vfat -o loop ./pendrive /mnt/usbdrv/
Se nulla si è risolto, otterremo ancora errori del genere:
mount: tipo fs errato, opzione non valida, superblocco su /dev/loop0 danneggiato,
codepage o programma ausiliario mancante, o altro errore
In alcuni casi si possono trovare informazioni utili in syslog. Provare
ad esempio 'dmesg | tail'
# dmesg | tail
FAT: invalid media value (0x01)
VFS: Can't find a valid FAT filesystem on dev loop0.
FAT: invalid media value (0x01)
VFS: Can't find a valid FAT filesystem on dev loop0.
FAT: invalid media value (0xa5)
VFS: Can't find a valid FAT filesystem on dev loop0.
FAT: invalid media value (0xa5)
VFS: Can't find a valid FAT filesystem on dev loop0.
FAT: invalid media value (0xa5)
VFS: Can't find a valid FAT filesystem on dev loop0. - Proviamo ad utilizzare, allora,
[tuxmal@work ~]# testdisk ./pendrive
seguendo i menù riusciremo a correggere boot sector e partition table ed a visualizzare i file (menù [Advanced]). Proprio da quest'ultimo menù, tramite [Image Creation], creo una nuova immagine del pendrive (dal nome di default image.dd). - Adesso proviamo a vedere dentro il pendrive recuperato:
[tuxmal@work ~]#mount -t vfat -o loop ./image.dd /mnt/usbdrv/ -o codepage=850,iocharset=utf8
montando l'immagine ottenuta, questa volta riuscimo a leggere tutti i file presenti. Per una corretta visualizzazione dei nomi dei file è stato necessario specificare le opzioni
codepage=850,iocharset=utf8
poiché le operazioni sono state svolte su di una linuxbox che usa UNICODE come charset di default.
- Partition-Rescue HOWTO
- Per una occhiata veloce sul problema.
- "Invalid or incomplete multibyte or wide character" Issue
- Mi ha ispirato per inserire le opzioni di mount relative al set di caratteri.
Powered by ScribeFire
Certo, i danni constatati sono sostanzialmente di tipo logico, ma mi permetto di parlare di danno hardware in quanto la riscrittura sulle pennette in esame mi è risultata sempre impossibile (anche una successiva formattazione terminava con un fallimento); nondimeno il danno hardware deve essere limitato. Per questo motivo, oltre che per non compromettere ulteriormente il dispositivo, tutte le operazioni sono effettuate su di una copia dei dati trascritti in un file su disco.
RispondiEliminaSono d'accordo sul considerare i vari danni hardware come diceva appunto @TuxmAL. Va detto che molto spesso quando c'è un guasto (di tipo elettrico intendo) la pen drive non è più funzionante e quindi non è in grado di comunicare con il PC. Ne consegue che qualsiasi operazione effettuata con metodi software non avrà alcun effetto. Il metodo descritto è certamente validissimo quando c'è un danneggiamento di tipo "logico" quindi la pen drive funziona ancora ma non si può accedere ai dati. Per casi di danneggiamenti invece derivati da urti, shock elettrici o guasti ai componenti non c'è altra soluzione che un approccio diretto sull'hardware. Le ditte specializzate in recupero dati infatti utilizzano strumentazioni che consentono di lavorare direttamente sui chip di memoria . Si può trovare qualche informazione in proposito (in italiano) qui www.sosdati.it
RispondiElimina