Il file è misteriosamente vuoto. Opzioni da recuperare?


9

Ho visto diversi post sul recupero di file cancellati, ma questa situazione è diversa. Mia moglie aveva un file chiamato Journal.odt in cui conservava molte informazioni personali importanti come ricordi speciali sui nostri figli. L'altro giorno quando ha provato ad aprirlo in OpenOffice si è lamentato del formato. Le ho fatto cancellare e tornare indietro. Quando ho catil file è completamente vuoto. lsdice che il file è 0 byte.

Se avesse accidentalmente selezionato tutto il testo nel file, colpito backspace e salvato, ci sarebbero comunque le meta informazioni di OpenOffice nel file.

Ho immediatamente spento il suo laptop per evitare di apportare ulteriori modifiche al disco fino a quando non riesco a pensare a qualcosa da fare.

Ho fatto alcune cose complicate in passato come l'uso ddper recuperare testo non elaborato dal disco, ma non ho idea di cosa fare qui. Dato che i file odt non sono testo semplice, non posso semplicemente reindirizzare l'intero disco attraverso grep.

Ogni suggerimento sarà molto apprezzato.

Inoltre, se qualcuno ha qualche idea su cosa potrebbe essere andato storto, mi piacerebbe ascoltarlo.

Grazie


1
Sarebbe diverso se il file fosse accidentalmente cancellato o qualcosa del genere, ma quando si trovava in un editor di testo, ecc. Il salvataggio del file spesso scrive "sul posto" cancellando efficacemente tutto ciò che avrebbe potuto essere recuperato con il recupero della forza forense. Sarebbe stato meglio se non avessi spento immediatamente il sistema, scommetto che un paio di pressioni di control + z (funzione "annulla" integrata in Open Office) avrebbero risolto il problema.
Tim

@Tim vedo il tuo punto, ma sfortunatamente il file era stato svuotato giorni prima. L'ora dell'ultima modifica sul file era alcuni giorni prima. Nella mia descrizione quando l'ha aperto in OO era già vuoto. Grazie comunque.
jcbwlkr,

2
Non cercare di sconfiggere un cavallo morto o di dare un calcio a un uomo quando è a terra, ma sospetto che questa esperienza ti farà guardare in una soluzione di backup. Dai un'occhiata a "Areca Backup" per un'applicazione di backup semplice e compatibile con Linux.
Tim

Disco pieno forse? Verificare condf -h
jippie il

@Tim Se il file è 0 byte, non è un documento OO; Ctrl+Znon avrebbe fatto nulla, poiché il file non è stato salvato come da OO. @ Jacobwalker0814 I file ODT sono file zip, quindi gli strumenti di recupero come testdisk hanno la possibilità di trovarli; ma non c'è alcuna garanzia, e anche se i dati sono ancora lì potresti dover sfogliare molti altri file zip. E per il futuro, fai un backup!
Gilles 'SO- smetti di essere malvagio' il

Risposte:


3

Se si utilizza il file system ext3, provare a seguire l' HOWTO di Carlo Wood

In poche parole,

  • Usa ext3grep $ IMAGE --ls --inode 2 | grep your_file per trovare il file che stai cercando (dove $ IMAGE è la tua partizione, ad esempio / dev / sda2)
  • Trova il blocco del file system che contiene il journal di spazio non allocato.
  • Trova tutti i descrittori di giornale che fanno riferimento al blocco che sono stati trovati in precedenza.
  • Copia il blocco con dd.
  • Modifica il file per eliminare gli zeri finali.
  • cat il file dove vuoi

Dalla fonte:

"Il capitolo Esempio di recupero manuale

Nel seguente esempio recupereremo manualmente un piccolo file. Viene fornito solo un output parziale per risparmiare spazio e rendere l'esempio più leggibile.

Usando ext3grep $ IMAGE --ls --inode troviamo il nome del file che vogliamo recuperare:

$ ext3grep $ IMMAGINE --ls --inode 2 | grep carlo 3 end d 195457 D 1202352103 gio 7 feb 03:41:43 2008 drwxr-xr-x carlo

$ ext3grep $ IMMAGINE --ls --inode 195457 | grep 'bin $' | head -n 1 34 35 d 309540 D 1202352104 gio 7 feb 03:41:44 2008 drwxr-xr-x bin

$ ext3grep $ IMMAGINE --ls --inode 309540 | grep start_azureus 9 10 r 309631 D 1202351093 gio 7 feb 03:24:53 2008 rrwxr-xr-x start_azureus

Ovviamente, l'inode 309631 viene cancellato e non abbiamo numeri di blocco per questo file:

$ ext3grep $ IMMAGINE --print --inode 309631 [...] Inode è non allocato Gruppo: 19 ID generazione: 2771183319 uid / gid: 1000/1000 modalità: rrwxr-xr-x dimensione: 0 numero di collegamenti: 0 settori: 0 (-> 0 blocchi indiretti).

Inode Times: Accesso: 1202350961 = Gio 7 feb 03:22:41 2008 File modificato: 1202351093 = Gio 7 feb 03:24:53 2008 Inode modificato: 1202351093 = Gio 7 feb 03:24:53 2008 Tempo cancellazione: 1202351093 = Gio 7 febbraio 03:24:53 2008

Blocchi diretti:

Pertanto, proveremo a cercarne una copia precedente nel diario. Innanzitutto, troviamo il blocco del file system che contiene questo inode:

$ ext3grep $ IMMAGINE --inode-to-block 309631 | grep risiede Inode 309631 risiede nel blocco 622598 all'offset 0xf00.

Quindi troviamo tutti i descrittori di giornale che fanno riferimento al blocco 622598:

$ ext3grep $ IMAGE --journal --block 622598 [...] Descrittori di giornale blocco di riferimento 622598: 4381294 26582 4381311 28693 4381313 28809 4381314 28814 4381321 29308 4381348 30676 4381349 30986 4381374 4381 4381 7081 4381 4382137 6672 4382138 7536 4382139 7984 4382140 8931

Ciò significa che la transazione con il numero progressivo 4381294 ha una copia del blocco 622598 nel blocco 26582 e così via. Il numero di sequenza più grande, in fondo, dovrebbe essere l'ultimo dato scritto sul disco e quindi il blocco 8931 dovrebbe essere lo stesso del blocco corrente 622598. Per trovare l'ultima copia non cancellata, si dovrebbe iniziare dal basso e lavorare verso l'alto.

Se provi a stampare un tale blocco, ext3grep riconosce che è un blocco da una tabella di inode e stampa il contenuto di tutti i 32 inode in esso. Desideriamo solo vedere l'inode 309631; quindi usiamo un grep intelligente:

$ ext3grep $ IMMAGINE --print --block 8931 | grep -A15 'Inode 309631' -------------- Inode 309631 ----------------------- ID generazione: 2771183319 uid / gid: 1000/1000 modalità: rrwxr-xr-x dimensione: 0 numero di collegamenti: 0 settori: 0 (-> 0 blocchi indiretti).

Inode Times: Accesso: 1202350961 = Gio 7 feb 03:22:41 2008 File modificato: 1202351093 = Gio 7 feb 03:24:53 2008 Inode modificato: 1202351093 = Gio 7 feb 03:24:53 2008 Tempo cancellazione: 1202351093 = Gio 7 febbraio 03:24:53 2008

Blocchi diretti:

Questo è effettivamente lo stesso che abbiamo visto nel blocco 622598. Successivamente esaminiamo i numeri di sequenza più piccoli fino a quando non ne troviamo uno con un tempo di eliminazione 0. Il primo che troviamo (dal basso verso l'alto) è il blocco 6073:

$ ext3grep $ IMMAGINE --print --block 6073 | grep -A15 'Inode 309631' -------------- Inode 309631 ----------------------- ID generazione: 2771183319 uid / gid: 1000/1000 modalità: rrwxr-xr-x dimensione: 40 num di collegamenti: 1 settori: 8 (-> 0 blocchi indiretti).

Inode Times: Accesso: 1202350961 = Gio 7 feb 03:22:41 2008 File modificato: 1189688692 = Gio 13 set 15:04:52 2007 Inode modificato: 1189688692 = Gio 13 set 15:04:52 2007 Tempo cancellazione: 0

Blocchi diretti: 645627

Quanto sopra è automatizzato e può essere fatto molto più velocemente con l'opzione della riga di comando --show-journal-inodes. Questa opzione trova il blocco a cui appartiene l'inode, quindi trova tutte le copie di quel blocco nel journal e successivamente stampa solo l'inode richiesto da ciascuno di questi blocchi (ognuno dei quali contiene 32 inode, come sai), eliminando i duplicati :

$ ext3grep $ IMMAGINE --show-journal-inodes 309631 Numero di gruppi: 75 Blocco journal minimo / massimo: 1115/35026 Caricamento descrittori journal ... completato La transazione journal 4381435 si avvolge, alcuni blocchi di dati potrebbero essersi persi con questa transazione. Numero di descrittori nel giornale: 30258; numeri di sequenza min / max: 4379495/4382264 Copie dell'inode 309631 trovate nel journal:

-------------- Inodo 309631 ----------------------- ID generazione: 2771183319 uid / gid: 1000/1000 modalità: rrwxr-xr-x dimensione: 0 numero di collegamenti: 0 settori: 0 (-> 0 blocchi indiretti).

Inode Times: Accesso: 1202350961 = Gio 7 feb 03:22:41 2008 File modificato: 1202351093 = Gio 7 feb 03:24:53 2008 Inode modificato: 1202351093 = Gio 7 feb 03:24:53 2008 Tempo cancellazione: 1202351093 = Gio 7 febbraio 03:24:53 2008

Blocchi diretti:

-------------- Inodo 309631 ----------------------- ID generazione: 2771183319 uid / gid: 1000/1000 modalità: rrwxr-xr-x dimensione: 40 numero di collegamenti: 1 settori: 8 (-> 0 blocchi indiretti).

Inode Times: Accesso: 1202350961 = Gio 7 feb 03:22:41 2008 File modificato: 1189688692 = Gio 13 set 15:04:52 2007 Inode modificato: 1189688692 = Gio 13 set 15:04:52 2007 Tempo cancellazione: 0

Blocchi diretti: 645627

Il file è davvero piccolo: solo un blocco. Copiamo questo blocco con dd come mostrato prima:

$ dd se = $ IMMAGINE bs = 4096 conteggio = 1 salto = 645627 di = blocco.645627 1 + 0 registra in 1 + 0 registra 4096 byte (4,1 kB) copiato, 0,0166104 secondi, 247 kB / s

e quindi modificare il file per eliminare gli zeri finali o copiare i primi 40 byte (la dimensione data del file):

$ dd if = blocco.645627 bs = 1 conteggio = 40 di = start_azureus 40 + 0 registra in 40 + 0 registra 40 byte (40 B) copiati, 0,000105397 secondi, 380 kB / s

$ cat start_azureus cd / usr / src / azureus / azureus ./azureus &

Recuperato!"


Mi piacerebbe dare un'occhiata a quello, ma il collegamento sembra morto.
jcbwlkr,

3
Non mi sembra morto.
Lister

sì, posso accedervi anche io.
java_xof

Ora funziona bene. Sicuramente non era prima. Chissà? Grazie, Java. Lo guarderò.
jcbwlkr,

Nessun problema, spero che questo ti aiuti, senza offesa ma so qualcosa sull'interazione moglie <-> computer;)
java_xof

2

Prova testdisk e photorec , ma il modo in cui capisco la tua scrittura è probabilmente il modo più difficile per imparare il valore dei backup regolari. Inoltre, potrebbe essere necessario eseguire l'avvio da CD per impedire che il disco rigido venga ulteriormente modificato. Personalmente mi piace System Rescue Disk per questo, ma è in gran parte basato sulla riga di comando.


1

Usa Caine una distribuzione linux speciale per la medicina legale digitale. È pieno di strumenti per il recupero di file e hard disk.


Grazie. Guarderò in quella distro e vedrò se ha qualcosa. Hai qualche consiglio su strumenti specifici o su come affrontare il problema? Il problema qui è che il file non è stato eliminato a cui molti strumenti sembrano indirizzare; ha appena perso i suoi contenuti.
jcbwlkr,

1
Open Office a volte crea un file nascosto che contiene il precedente documento salvato. Se sei fortunato puoi provare a recuperarlo usando ad esempio "extundelete" o " testdisk
PsyStyle il

Cerca in ~ / .openoffice.org / 3 / user / backup / o ~ / .libreoffice.org / 3 / user / backup / Ho scritto uno script per cancellare queste directory in modo che le cose sensibili che ho cancellato non fossero ancora lì.
Joe,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.