Intendo di provare a riparare il nuovo, che ha qualche byte finale mancante, ma magari NTFS e’ contento lo stesso e riesce ad aggiustarlo.
Non so se fsck da linux sia “potente” abbastanza, magari da windows e’ meglio, non so.
Ah, interessante, se dite che non rischio di fare danni perché non provarci…
Beh, fare danni sul nuovo direi di no, tanto per ora non lo stai usando. E hai ancora il vecchio casomai per fare delle prove di ripristino.
[root@localhost ~]# fsck /dev/sdc
fsck da util-linux 2.36.2
e2fsck 1.45.6 (20-Mar-2020)
ext2fs_open2: Valore magic non corretto nel super-blocco
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Valore magic non corretto nel super-blocco nell'aprire /dev/sdc
The super-blocco could not be read or does not describe a valid ext2/ext3/ext4
file system. If the device is valid and it really contains an ext2/ext3/ext4
file system (and not swap or ufs or something else), then the super-blocco
is corrupt, and you might try running e2fsck with an alternate super-blocco:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
Found a dos partition table in /dev/sdcMmm fsck non ha riconosciuto il disco come NTFS.
Riprova usando fsck.ntfs (se non ce l’hai dovresti installare ntfsprogs prima).
Oppure meglio ancora, hai un windows sotto mano a cui attaccare il disco e dare un chkdsk da prompt? Anche su macchina virtuale volendo (sara’ probabilmente piu’ lento, ma meglio che niente)
La differenza è appunto di 512 bytes, ma dato che hai usato ddrescue proprio perchè il disco di origine era “problematico” io non mi preoccuperei molto se gli ultimi 512 bytes non sono stati copiati! La copia è comunque andata a buon fine… Il problema è capire se i dati copiati sono accessibili e soprattutto se la tabella delle partizioni è leggibile!
l’fsck (file system check) va fatto sulla partizione, non sul disco! /dev/sdc1, /dev/sdc2…
1 Mi Piace
Grazie Zod e bebo-sudo, scusate per il silenzio, ma sono stato in giro e poi sempre preso da altro. Mi ci rimetto.
Intanto provo sulla partizione (che ora vede come sdb1)
[root@localhost ~]# fsck /dev/sdb1
fsck da util-linux 2.36.2
e2fsck 1.45.6 (20-Mar-2020)
ext2fs_open2: Valore magic non corretto nel super-blocco
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Valore magic non corretto nel super-blocco nell'aprire /dev/sdb1
The super-blocco could not be read or does not describe a valid ext2/ext3/ext4
file system. If the device is valid and it really contains an ext2/ext3/ext4
file system (and not swap or ufs or something else), then the super-blocco
is corrupt, and you might try running e2fsck with an alternate super-blocco:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>Finalmente l’ho fatto: ha macinato ore, mentre ero fuori casa, al ritorno ho visto che aveva finito e l’ho scollegato. Ho un chilometrico file di log che non vi copio qui, se necessario posso accludere informazioni.
Guardando da Fedora, cioè montando l’hd, ho una sequenza di oltre trecento nuove cartelle (in gran parte chiamate “dir???.chk”) e un centinaio di files sparsi. Mi sembra però che includano solo una parte dei files del vecchio hd.
Quel che mi premeva era avere l’albero delle vecchie directory per capire se nell’hd fossero finite cose in copia unica (specialmente video) e per ricostruire il futuro backup: è recuperabile?
Il chilometrico file di log dopo il chkdsk contiene messaggi minatòri come blocchi non ricostruibili, etc?
Mi pare di capire che le 300 nuove cartelle sono le uniche cose che vedi, cioe’ non c’e’ piu’ l’albero delle cartelle che c’era sul vecchio hdd.
Non conosco NTFS, ma penso che se si sono fritti i primi settori del disco in cui c’e’ la tabella dei metadati (che ti permette di visualizzare il contenuto di una partizione come fosse un “albero”) ci sia poco da fare.
Se i nomi dei file nelle 300 cartelle sono ancora “corretti”, puoi usare find per trovare i file video, oppure cercando per dimensione, oppure usando file /percorso/al/file per ottenere piu’ informazioni sul file ispezionandone il contenuto.
Grazie bebo_sudo per la pronta replica!
Non trovo (ctrl+f) messaggi “minatòri” nel log, che ha questa struttura:
Fase 1: analisi della struttura del file system di base in corso… (varie eliminazioni, righe 5-92)
Fase 2: analisi del collegamento dei nomi file in corso… (varie correzioni, righe 93-1508, con creazione nuova radice etc, indice, id oggetto fino 1566)
Fase 3: analisi dei descrittori di sicurezza in corso… (1568-1600)
Fase 4: ricerca di cluster danneggiati nei dati dei file utente in corso… (poche righe)
Fase 5: ricerca di cluster liberi danneggiati in corso… (fino a 1639)
Ultime righe:
Citazione Correzioni apportate al file system.
Non sono necessarie ulteriori azioni.
976760407 KB di spazio totale su disco.
12628232 KB in 5159 file.
2472 KB in 589 indici.
0 KB in settori danneggiati.
185939 KB in uso dal sistema.
65536 KB occupati dal file registro.
963943764 KB disponibili su disco.
4096 byte in ogni unità di allocazione.
244190101 unità totali di allocazione su disco.
240985941 unità di allocazione disponibili su disco.
L’albero non c’è più, le cartelle hanno nomi esotici. Mi sono fatto un file txt con l’elenco di file e cartelle e il “trova” restituiva pochi files musicali e video. Direi di chiudere il primo tentativo, quello interrotto per la differenza di pochi byte fra il vecchio disco danneggiato e quello nuovo su cui fare il rescue, e passare al secondo tentativo…
1 Mi Piace
Cari fedoriani,
mi sono accorto che, nella stizza…, non vi ho mai dato conto dell’esito del secondo tentativo: uguale al primo. Anche la copia sul disco esterno più grande ha dato lo stesso risultato.
Grazie comunque per l’appoggio indispensabile!