Copia dati corrotti i conti non tornano

Area di discussione libera.

Moderatore: Staff

Regole del forum
1) Rispettare le idee altrui.
2) Evitare le offese dirette.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2671
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Copia dati corrotti i conti non tornano

Messaggioda joe » mer ago 30, 2017 11:24

Metto qua in sezione "libera" perchè il problema potrebbe riguardare non solo linux.

Allora, sto facendo la copia di circa 700GB di dati da un HD vecchio da 1TB ad un nuovo disco da 2TB.
Sul vecchio c'erano 3 partizioni e la seconda era quella "sorgente" da cui copiare i dati, filesystem ext3.
Sul nuovo ho creato 3 partizioni, di cui la seconda da utilizzare come destinazione l'ho fatta da 800GB, in modo da stare un po' più abbondante rispetto alla sorgente e l'ho formattata in ext4.

la copia l'ho eseguita con rsync:

Codice: Seleziona tutto

rsync -av /mnt/green2 /mnt/red2


La nomenclatura deriva dal fatto che il vecchio disco era un wd caviar green che ho estratto dal suo box usb-2 wd-elements e per sveltire la copia l'ho sistemato nel PC via SATA.
Il nuovo disco invece è un WD Red da 2TB. Così ho creato le directory di montaggio chiamate come vedete sopra, in modo da orientarmi meglio.

Veniamo al problema:
Ad un certo punto mi accorgo che i dati copiati sulla destinazione sono più dei dati di partenza. Il che non è possibile.
La copia sembra incantarsi e voler copiare un messaggio email da 500GB e passa, il che non ha senso.
Andando a controllare che roba era quella, vedo che si tratta di un backup di fortuna di una SDcard corrotta. Per scrupolo avevo backuppato la SDcard e poi se ricordo bene, l'avevo resettata. Dentro se non ricordo male c'era roba del netbook di un amico che la usava come memoria di "espansione" su un acer aspire one con solo 4GB o 8GB di disco interno.

Penso che il fatto che fossero dati corrotti, in qualche modo manda in panne la copia sulla stima precisa delle dimensioni....
Al primo giro si incantava su un'imamgine jpg che risultava anch'essa di 500GB. Ma aprendola ho visto che era praticamente una jpg in qualità ultrbassa, e comunque sacrificabile, così l'ho cancellata e ho riavviato rsync, al chè si è bloccato su quel messaggio email che sarà si e no 1 KB e invece anche qui risulta di 500GB.

Cosa consigliate di fare?
Elimino quella directory e pace? Tanto penso che sia ormai roba di scarso interesse e poco importante. Anche perchè anche l'amico poi mi aveva detto di non averci sopra roba importante.

Oppure consigliate altre vie per portare a termine la copia senza problemi e poi in un secondo momento eventualmente controllare e cancellare quella roba?
Perchè può capitare questo paradosso secondo voi?

Grazie in anticipo!

Avatar utente
Delcaran Lëdeloth
Linux 2.0
Linux 2.0
Messaggi: 116
Iscritto il: mar mag 27, 2008 8:24
Nome Cognome: Matteo Paoluzzi
Slackware: 14.2 - 64bit
Kernel: 4.4.75 generic
Desktop: i3
Località: ud.fvg.it
Contatta:

Re: Copia dati corrotti i conti non tornano

Messaggioda Delcaran Lëdeloth » gio ago 31, 2017 10:10

Solo una ipotesi, non è che il disco sorgente sia difettoso o il file system si è danneggiato? Hai provato a fare un fsck (o equivalente) e magari anche un test di integrità (tipo con CrystalDisk)? Perché da come la racconti sembra che la cosa sia independente dal file, quindi magari dipende da quel punto in particolare (hardware o software) del disco...
Find me at Keybase
Slackware user since 1997.

Avatar utente
ponce
Iper Master
Iper Master
Messaggi: 2144
Iscritto il: mer mar 05, 2008 16:45
Nome Cognome: Matteo Bernardini
Slackware: slackware64-current
Kernel: 4.13.0
Desktop: lxde
Località: Pisa
Contatta:

Re: Copia dati corrotti i conti non tornano

Messaggioda ponce » gio ago 31, 2017 10:14

in caso di dischi danneggiati vale la pena fare un dd di tutta la partizione e poi lavorare sul file immagine: lo strumento dedicato e' ddrescue.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2671
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Copia dati corrotti i conti non tornano

Messaggioda joe » gio ago 31, 2017 11:26

Non è da escludere che vi siano problemi hardware.
Anche in termini di filesystem, anni fà si era corrotto e ci avevo messo una pezza con fsck grazie agli inodes di backup, se si dice così.

Adesso siccome quella partizione è quasi piena e siccome ho avvertito qualche rumorino sospetto quando quel disco esterno era anche solo alimentato senza collegamento al PC, ho deciso di prendere il nuovo disco da 2TB.
Volevo salvare tutti i dati del vecchio sul nuovo in modo da analizzare poi con calma il contenuto del vecchio HDD, tenere la roba importante e farne ulteriore backup. Poi volevo rasare completamente quel vecchio disco, appunto testarlo anche a livello hardware per capire quanto sia affidabile. E quindi ripartizionarlo ecc..

Il problema è che appunto, la copia dei dati si ferma lì.
Problema hardware? Spero vivamente di no!
Problema di corruzione filesystem o dati corrotti? Quasi sicuro, in primis perchè quei dati come ho detto erano il contenuto di una SD card corrotta, copiati forze forzando un po' la mano...

Mi sa che la copia con dd invece che rsync sia preferibile, se non l'unica alternativa.
Tanto per fare una prova potrei istruire rsync ad escludere la directory contenente il recupero di quella sdcard. Se funziona penso di potermi anche accontentare, tanto era tutta roba praticamente inaccessibile e comunque non importante.

Cosa ne dite?
O forse è meglio buttarsi prima su ddrescue...?
ddrescue lo conosco poco, ho sempre usato dd liscio. Mi informo un po' su come si fa la copia della partizione su file immagine.

Grazie dei consigli! :D

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2671
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Copia dati corrotti i conti non tornano

Messaggioda joe » gio ago 31, 2017 11:44

Tra l'altro ho notato anche un altro problema: alcune subdir non riesco a copiarle per mancanza di permessi. E sto lavorando come root...
In particolare erano dirs relative al recupero del filesystem cui vi ho accennato. È tutta roba ancora contenuta in lost+found e nominata numericamente...
Vi riporto un pezzo del rsync in qui lamenta la cosa:

Codice: Seleziona tutto

rsync: opendir "/mnt/wd2/lost+found/#46825336" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#47959298" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48006879" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48027743" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48048668" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48056914" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48086034" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48112539" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48122353" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48218362" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48325225" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48405505" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48460240" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48464737" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48466563" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48513617" failed: Permission denied (13)
rsync: opendir "/mnt/wd2/lost+found/#48554371" failed: Permission denied (13)

Se vado a controllare gli attributi di quelle directory ecco ad esempio cosa leggo:

Codice: Seleziona tutto

ls -ld /mnt/wd2/lost+found/#46825336
d--S--Sr-T 2 joe users 4096 mag 24  1912 /mnt/wd2/lost+found/#46825336/


Anche qui come spuò risolvere?
banalmente con chroot modificando i permessi ricorsivamente su "lost+found", potrebbe funzionare?

Avatar utente
ponce
Iper Master
Iper Master
Messaggi: 2144
Iscritto il: mer mar 05, 2008 16:45
Nome Cognome: Matteo Bernardini
Slackware: slackware64-current
Kernel: 4.13.0
Desktop: lxde
Località: Pisa
Contatta:

Re: Copia dati corrotti i conti non tornano

Messaggioda ponce » gio ago 31, 2017 12:10

se e' un problema hardware dovresti avere gli errori in dmesg e /var/log/syslog.

comunque, ripeto, non conviene toccare il disco: come prima operazione fai la copia su un file con ddrescue e poi lavora su quella.

puoi anche usare dd, se te ne freghi di perdere tempo per provare recuperare i settori danneggiati: io, per esempio, qualche tempo fa l'ho usato su un disco danneggiato cosi'

Codice: Seleziona tutto

dd if=/dev/sdb8 of=/path/immagine_disco conv=noerror,sync status=progress

ovviamente cosi' gli errori sono completamente ignorati: se non vuoi questo comportamento ddrescue, secondo me, e' la tua unica opzione.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2671
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Copia dati corrotti i conti non tornano

Messaggioda joe » gio ago 31, 2017 13:17

Sì, con rsync, anche escludendo la directory "sdcardcorrupted" che sicuramente aveva problemi di sorruzione di files o giù di lì, i conti non tornano e ritrovo rsync intento a copiare più dati di quelli di partenza.
Non ho incluso però opzioni tipo remove-before, per rimuovere dalla destinazione eventuali cose in più... che per qualche santo possono essere la presenti.

Tuttavia, visto che il comando non è riuscito, meglio fare come hai detto tu ed eseguire una copia della partizione raw con ddrescue.
Ho dato un'occhiata alla documentazione e non ho ben capito perchè includono sempre la dicitura "mapfile" negli esempi.
Un comando come il seguente potrebbe andare bene secondo voi?

Codice: Seleziona tutto

ddrescue -d /dev/sdb2 /mnt/red1/20170731-green2.img

Grazie mille per il supporto! :)

EDIT
Ho letto meglio l'help e il mapfile serve praticamente a supportare anche il resume, quindi vista la mole dei dati è meglio aggiungerlo.
Rilancio allora col seguente comando:

Codice: Seleziona tutto

ddrescue -d /dev/sdb2 /mnt/red1/20170731-green2.img mapfile

Può andare? Confermate? L'accendiamo? :roll:

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2671
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Copia dati corrotti i conti non tornano

Messaggioda joe » ven set 01, 2017 0:31

Alla fine ho lanciato ddrescue senza aspettare conferme:

Codice: Seleziona tutto

# ddrescue -d /dev/sdb2 /mnt/red1/20170831-green2.img 20170831-mapfile-green2.log
GNU ddrescue 1.21
Press Ctrl-C to interrupt
Initial status (read from mapfile)
  rescued:    2870 MB,     errsize:        0 B,  errors:       0

Current status
     ipos:  800204 MB, non-trimmed:        0 B,  current rate:   7015 kB/s
     opos:  800204 MB, non-scraped:        0 B,  average rate:  67910 kB/s
non-tried:        0 B,     errsize:        0 B,      run time:  3h 15m 41s
  rescued:  800204 MB,      errors:        0,  remaining time:         n/a
percent rescued: 100.00%      time since last successful read:          0s
Finished

Il comando sopra mostra che l'operazione era stata precedentemente lanciata e interrotta. Infatti l'avevo fatto apposta per capire se funziona il resume: quindi è supportato e dipende dal "mapfile" che quindi deve essere esplicitamente definito la prima volta che si esegue il comando, a quel punto si può anche interrompere, ma per farla ripartire da dove si era interrotto è necessario indicare come terzo argomento lo stesso mapfile di prima che contiene le info per ripartire dal punto giusto.

Intanto non sono stati registrati errori e questo fa ben sperare rispetto alle condizioni dell'hardware, comunque vedremo successivamente come testarlo in modo più mirato.
Inoltre osservo che l'operazione è stata tutto sommato ragionevolmente rapida 3 ore e un quarto per circa 750 GB. Non so cosa vi pare? Siamo su motherboard che supporta solo SATAII.

Adesso cosa consigliate per verificare l'integrità dei dati contenuti nell'immagine della partizione backuppata?
Diciamo almeno per verificare che immagine e partizione siano identici...
Un calcolo del md5 di partizione e immagine?
oppure un:

Codice: Seleziona tutto

diff /dev/sdb2 /mnt/red1/20170831-green2.img


Grazie per le dritte! :D

Avatar utente
ponce
Iper Master
Iper Master
Messaggi: 2144
Iscritto il: mer mar 05, 2008 16:45
Nome Cognome: Matteo Bernardini
Slackware: slackware64-current
Kernel: 4.13.0
Desktop: lxde
Località: Pisa
Contatta:

Re: Copia dati corrotti i conti non tornano

Messaggioda ponce » ven set 01, 2017 12:55

secondo me non hai bisogno di fare nessuna verifica.
l'md5sum o il diff non hanno senso perche' saranno sicuramente diversi.

come prima cosa, per evitare di dover far girare di nuovo ddrescue, io mi farei una copia del file immagine.
dopo farei girare fsck sul file immagine, poi lo monterei e copierei i file sul nuovo disco che dovrebbe sostituire il vecchio tramite rsync.
fine.

se vuoi testare il vecchio disco usa smartctl e leggiti l'output di dmesg e /var/log/syslog.

in bocca al lupo!

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2671
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Copia dati corrotti i conti non tornano

Messaggioda joe » ven set 01, 2017 13:28

l'md5sum o il diff non hanno senso perche' saranno sicuramente diversi.

La partizione /dev/sdb2 non è più stata montata dopo il backup.
Neanche la sua immagine copiata.
A quel punto mi chiedo, perchè dovrebbe differire il checksum?
Chiedo per ignoranza ovviamente...

Grazie dei consigli, penso che farò così anche se effettivamente lo spazio necessario per queste cose ingombranti è un po' un problema:
se faccio una copia dell'immagine e poi ne copio i dati sulla partizione finale che li ospiterà servono:

750 GB per l'immagine, già occupati
750 GB per la copia dell'immagine
circa 680/700 GB per contenere i dati finali
In totale servirebbero più dei 2TB del mio nuovo disco... 2.2 TB almeno. È un problema...

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2671
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Copia dati corrotti i conti non tornano

Messaggioda joe » ven set 01, 2017 19:04

Alla fine ho eseguito il calcolo degli hash md5 (che ho letto essere meno dispendioso rispetto a al SHA1 e compagnia).

Codice: Seleziona tutto

# cat /tmp/*green*.md5   
a18ba807ae25648e3f5a31b85b3393be  /mnt/red1/20170831-green2.img
a18ba807ae25648e3f5a31b85b3393be  /dev/sdb2

Ok, allora adesso abbiamo una copia senza ombra di dubbi fedele della partizione, di partenza.
Il tutto stoccato sul nuovo HDD in una partizione da 1TB circa. /mnt/red1/20170831-green2.img.

Adesso tu ponce dicevi:
- farne un'ulteriore copia di backup dell'immagine, chiamiamola "green2", da non toccare
- quindi eseguire fsck su "green2".

Per la precisione sono 746 GB di immagine. Il che ci riporta al problema iniziale dello spazio mancante, per fare poi la copia finale dei dati, dall'immagine controllata con fsck all filesystem del disco nuovo.
Pensavo che ppotrei fare una cosa del genere.

    - Intanto posso fare la copia. di sicurezza: green2.bk
    - poi fare tutti i vari check sulla copia green2
    - infine posso continuare a lavorare sull'immagine green2 montandola in loop e rimuovendo tutti i dati che non mi servono più, la roba da buttare, diciamo.
    - a quel punto i dati che conterrà l'immagine forse riescono a stare nel disco nuovo insieme all'immagine green2 e green2.bk
Non so se è il modo di fare corretto in questi casi...
Cosa ne pensate?
Grazie mille ancora! :)


Torna a “Libera”

Chi c’è in linea

Visitano il forum: Nessuno e 12 ospiti