Come recuperare un file rimosso su Linux?


65

Per caso, ho usato rmun file che non volevo cancellare. C'è un modo per riaverlo sotto Linux?


@Nav, rmè un comando "pericoloso" UNIX / Linux (leggi $ man rm). Usalo con estrema cautela . Detto questo, è un modo rapido per eliminare i file di cui sei sicuro. I moderni ambienti desktop Linux e Unix offrono una soluzione di "cestino" , in modo che l'utente possa facilmente recuperare file cancellati accidentalmente.
Jose Elera,

1
alcune risposte più aggiornate: unix.stackexchange.com/questions/122305/…
Ben Crowell,

Non utilizzare "rm" se si desidera ripristinare i file in futuro
Utilizzare

Risposte:


51

Di seguito sono riportati i passaggi generici per ripristinare i file di testo.

  1. Per prima cosa usa il comando wall per dire all'utente che il sistema sta funzionando in modalità single user:

    # wall
    System is going down to .... please save your work.
    

    Premi CTRL + D per inviare un messaggio.

  2. Quindi utilizzare il comando init 1 per portare il sistema in una modalità utente singolo:

    # init 1
    
  3. Utilizzo di grep (tradizionale modo UNIX) per recuperare file

    Usa la seguente sintassi grep:

    grep -b 'search-text' /dev/partition > file.txt
    

    O

    grep -a -B[size before] -A[size after] 'text' /dev/[your_partition] > file.txt
    

    Dove,

    -i : Ignore case distinctions in both the PATTERN and the input files i.e. match both uppercase and lowercase character.
    -a : Process a binary file as if it were text
    -B Print number lines/size of leading context before matching lines.
    -A: Print number lines/size of trailing context after matching lines.
    

    Per recuperare il file di testo che inizia con la parola "nixCraft" su / dev / sda1 puoi provare il seguente comando:

    # grep -i -a -B10 -A100 'nixCraft' /dev/sda1 > file.txt
    
  4. Quindi usa vi per vedere file.txt.

    Questo metodo è utile SOLO se il file eliminato è un file di testo. Se si utilizza il file system ext2, provare a recuperare il comando.

Trovato su http://www.cyberciti.biz/tips/linuxunix-recover-deleted-files.html


16
Vale la pena notare che NON PUOI FARE QUESTA REMOTO la modalità utente singolo disattiva la rete
Quinma

1
Questo metodo fa miracoli per i file di testo, grazie! Quello che mi piace è che non si basa sul journal del filesystem (come extundelete), ma in realtà scansiona i byte grezzi dell'intera unità. Se questo comando non trova il tuo file, nulla lo farà.
Benjamin B.

1
@Quinma, questo metodo può funzionare in remoto con solo lievi modifiche ... Invece di eseguire init 1, uccidi manualmente tutti i demoni di sistema tranne sshd. Penso anche che a questo punto dovresti rimontare tutti i filesystem RO e salvarli su tmpfs (supponendo che i tuoi file temporanei si adattino a ram) per evitare di sovrascrivere i file con i dati temporanei. Dovrai ovviamente copiarlo altrove in seguito, o su un server remoto o di nuovo su filesystem locali dopo averli rimontati RW.
Thomas Guyot-Sionnest,

qual è la tua partizione ??? Ho un errore: / dev / sda1: nessun file o directory del genere
coolcool1994

1
@Qback, davvero non lo so. Come detto, ho appena seguito la procedura passo-passo. Ma init 1 è pensato per compiti amministrativi e forse uccide il processo non correlato a quello scenario di runlevel. Ciò potrebbe aiutare a impedire l'utilizzo del disco rigido, sovrascrivendo il file che si sta tentando di ripristinare.
Gabriel L. Oliveira,

13
  • Se è molto importante, prendi il disco dal computer e assumi un'azienda per farlo per te.
  • Se è solo molto importante, monta il disco in sola lettura, copia l'intera partizione in un file usando dde prova a trovare il file al suo interno (usando grep, o un editor).

Modifica: a volte ddrescuefunziona meglio di dd.


1
"prova a trovare il file al suo interno" Sono confuso, come si potrebbe ragionevolmente aprire un file di oltre 15 GB e cercare o convogliare questa bestia in grep? E cosa faresti quando hai trovato il testo? Come diavolo è questa ripresa?
TheLQ

1
La prima cosa da fare è provare alcuni strumenti comuni prima di bruciare un sacco di soldi per un risultato incerto. A proposito, grep non sarà di grande aiuto, photorec o ext3grep lo faranno.
Wazoox,



5
  • L'unica risposta corretta è: ripristinare il file dal backup. Tutti devono avere un backup. Per file molto importanti, dovresti avere due backup. No? Beh, peccato, ecco una lezione appresa (mi dispiace sembrare duro, ma sono nell'archiviazione dei dati e le persone non eseguono il backup fino a quando non hanno perso alcuni dati importanti, questo è un dato di fatto. Quindi sì, sembri stupido, ma così è quasi tutti gli altri).

  • OK, non hai alcun backup. devi smettere di usare il filesystem che conteneva il file ADESSO ORA . Qualsiasi attività di scrittura può sicuramente filtrare i dati del file che possono (solo possono ) rimanere sul disco.

  • se hai commesso il tragico errore di usare solo una partizione sia come filesystem di root che / home, significa che devi avviare da qualche altro dispositivo. ORA .

  • Se il tuo file ha un formato comune (file Word, JPG, ecc.), Usa Photorec . Photorec può recuperare i formati di file più comuni.

  • Puoi provare il metodo "ext3 undelete" proposto in precedenza, ma devi essere a tuo agio con la riga di comando, capire i meccanismi interni di base di Linux, ecc.

  • Se il tuo file ha un formato speciale, buona fortuna. Una volta ho scritto un programma Perl per scansionare un'unità per alcuni file speciali, e ha funzionato abbastanza bene; ma per farlo dovrai conoscere un po 'di programmazione ed essere abbastanza a tuo agio anche con Linux.


5

L'ho fatto un paio d'anni fa. Il mio approccio era direttamente, senza tempo da perdere, smontare la partizione e poi

dd if=/dev/hda1 of=backup_image.ext3

per avere un file di backup dello stato esatto della partizione. Quindi è possibile montare nuovamente la partizione e continuare normalmente come si cerca il file eliminato nell'immagine creata. L'immagine sarà probabilmente MOLTO grande poiché hai bisogno di tutto lo spazio "vuoto", quindi potrebbe essere un problema pratico memorizzarlo.

Quindi era solo per eseguire ricerche noiose dopo frammenti di testo che mi aspettavo di essere da qualche parte nella minestra del contenuto della partizione. Ad esempio, per trovare i file .tex, ho corso

grep --binary-files=text -1000 "subsection" < backup_image.ext3 > latexfiles

che stampava un ampio contesto attorno alla frase "sottosezione" e salvava l'output in un file da cercare manualmente. Ho stampato un contesto così ampio dato che ci è voluto così tanto tempo per cercare l'immagine che preferirei non farlo più volte di quanto avrei dovuto.

Inoltre il comando è stringsstato utile per rimuovere la spazzatura binaria dall'output, ma se ricordo bene ha anche eliminato tutte le nuove righe, il che potrebbe essere un problema.

Per trovare i file binari allo stesso modo, si potrebbe avere successo nel trovare un'intestazione caratteristica o qualcosa di un certo file, ma immagino che sia un'avventura piuttosto grande.


Brevi note tecniche: ci sono difficoltà tecniche con il recupero del disco e Ext3 / 4. È una cosa lunga da spiegare, ma brevemente (e inadeguatamente): Ext3 / 4 rimuove i "marcatori" che indicano al sistema operativo dove si trovano i file sul disco quando li elimini. I file non vengono cancellati, ma nessuno sa da dove iniziano e finiscono sul disco, e talvolta sono persino frammentati in diversi punti. Alcuni altri file system impostano gli stati dei file su "eliminati", ma mantengono i dati sulla posizione. Quindi ripristinare non è più difficile che guardare i puntatori di file con questo flag (dovrebbero essere ancora disponibili se non si è verificata troppa attività), e quindi sperare che il loro contenuto non sia stato sovrascritto.

Qual è il migliore? Retorico, a mio avviso. Il backup frequente è la risposta a tutti questi problemi. I dati importanti senza un sistema di backup automatizzato sono un incidente in attesa di accadere, IMHO.


Obbligatorio aneddoto personale: stavo per rimuovere foo\ foo*da ~. scrissi

rm -r foo<Tab>*

, che purtroppo, poiché fooapparentemente era un collegamento simbolico e l'unico file corrispondente a questo, la shell è diventata

rm -r foo\ foo *

Ho premuto Invio e mi sono seduto lì a guardare il comando, che avrebbe dovuto impiegare un secondo al massimo. Dopo un po 'più di tempo rmmi ha chiesto se volevo "rimuovere il file protetto da scrittura' qualcosa '". Abbastanza rapidamente ho sentito i brividi e piano e molto controllato ho premuto Ctrl+c. ~ La metà dei miei è ~stata eliminata, ma sono riuscito a recuperare tutto il valore attraverso il grepping sopra descritto e alcuni backup più o meno attuali. Avevo alcuni dati di misurazione personalmente molto preziosi (leggi: che richiedevano tempo) e molto recenti su disco che erano andati persi, ma avevo fatto quadrupli backup. Uno è scomparso qui, un altro a causa di un'interruzione del sistema a scuola, un altro era corrotto e all'inizio non riuscivo a trovare il quarto, poiché per errore l'avevo messo nella cartella sbagliata MrGreen. Non avevarm -rbloccato su un file protetto da scrittura, il quarto sarebbe stato mangiato da quando quella cartella era montata tramite sshfs nel mio ~. Sono molto più attento a questo tipo di cose da allora.


5

Se è lo standard rm , spero che tu abbia un backup. La procedura per ripristinare un file eliminato sarebbe diversa per ciascun file system, se possibile. Linux non ha un "cestino" incorporato; una volta eliminato un file, è quasi sparito.

In qualsiasi modo, ti consigliamo di scollegare il computer - il più presto possibile, poiché continuare a far funzionare il computer (anche per spegnerlo) provoca scritture sul disco e aumenta la possibilità che alcuni blocchi precedentemente occupati dal il file verrà sovrascritto. Una volta fatto, inseriscilo in un altro computer, riavvia un CD live (assicurandoti di non montare l'unità a meno che non lo monti in sola lettura) o rimuova il disco rigido e lo porti a uno specialista del recupero dati.


4

Abbassa le tue aspettative. Se qualcosa è stato scritto sui dati "cancellati", li perderai.

Ho fatto una piccola quantità di recupero e gli strumenti migliori che ho trovato sono stati spesso progettati per determinati formati. Ad esempio, "photorec" è stato eccezionale quando volevo recuperare decine di migliaia di jpeg.

Recuva mi ha anche aiutato prima d'ora e potrebbe essere la tua scelta migliore. (È gratuito, non farti ingannare nel pagare dai loro annunci)

Alla fine della giornata, se ciò che hai perso è importante, porta l'unità offline e smetti di scriverla. Utilizzare tutti i software di recupero che è possibile trovare fino a quando non si ripristinano i dati o si smette di valerne la pena. Se è davvero importante, invialo ai professionisti a un prezzo elevato.

Se hai avuto fortuna con uno strumento prima, provalo di nuovo visto che ne hai familiarità. Alla fine, non dovrebbero scrivere su disco e quindi puoi usare il software fino a quando non ne trovi uno che funzioni.


2

Ecco un ottimo documento per te. Troverai un sacco di consigli pratici lì.

A proposito, ci sono due gruppi di persone:

  1. quelli che fanno i backup
  2. quelli che eseguiranno i backup

Congratulazioni, ti sei appena promosso al gruppo 2. ;-)


2

Se hai un'applicazione aperta che sta attualmente leggendo il file, come VLC o LibreOffice, questa fantastica risposta L & U.SO mi ha aiutato a uscire da questo pasticcio. Ecco un metodo alternativo per fare lo stesso.

L'idea generale è quella di trovare il collegamento /proc/PID/fd/DESCRIPTOR_NUMBERe copiarlo nella posizione originale. Utilizzare ps aux | grep APP_NAMEper trovare il PID e quindi ls -la /proc/PID/fd/per trovare il DESCRIPTOR_NUMBER corretto.


1

La risposta "corretta" è presumere che non esiste un metodo per ripristinare in modo affidabile e ripristinare invece da backup o da un sistema clonato o reinstallare.

TestDisk è un ottimo strumento e ci sono altri modi per essere in grado di recuperare alcuni dati dall'unità fisica a seconda del file system e della recency della cancellazione, ma il tempo e il dolore coinvolti possono essere semplicemente troppo grandi, quindi CONSERVARE I BACKUP (e anche testare che sono validi e ripristinabili)!


1

Se non viene sovrascritto da altri utenti, allora sei fortunato. Ho cancellato accidentalmente il mio file sorgente cpp e ho usato uno strumento chiamato soprattutto , che mi ha aiutato a ripristinare i detriti 60G cpp dal disco. Alla fine, ho recuperato il mio file assemblando quei detriti pezzo per pezzo. Penso che scansiona determinati schemi per specifici tipi di file e attraversa tutti gli inode sul disco per recuperare i file! Prova!


0

Se accidentalmente hai eliminato il file da Linux, puoi usare questo comando:

find /root -name "search text" -type f  -exec mv {} "/home" \;

al posto di search textpuoi inserire il nome del file e puoi specificare la directory dove vuoi ripristinare al posto di /home.


2
Ciao Santosh. Ti preghiamo di non aggiungere collegamenti fuorvianti ai tuoi post. È stato rimosso.
ᔕᖺᘎᕊ

0

Puoi provare questo script. Funziona bene e intende essere utilizzato al posto di rm e im utilizzandolo ampiamente ora.

https://github.com/nateshmbhat/safe-rm

Caratteristiche :

  • destinato ad essere utilizzato al posto di rm
  • gestisce tutti gli argomenti che rm può accettare
  • gestisce le collisioni di nomi di file con i file già nel cestino
  • gestisce automaticamente alcuni problemi di autorizzazione
  • se rm viene chiamato da qualsiasi altro script o indirettamente, il comando di sistema 'rm' viene utilizzato automaticamente
  • mostra i messaggi di errore appropriati come quelli che si presentano in rm

-2

Ho avuto lo stesso problema la scorsa settimana e ho provato molti programmi, come debugfs, photorec, ext3grep ed extundelete. ext3grep era il miglior programma per recuperare file. La sintassi è molto semplice:

ext3grep image.img --restore-all

o:

ext3grep /dev/sda3 --restore-all --after date -d '2015-01-01 00:00:00' '+%s' --before `date -d ‘2015-01-02 00:00:00’ ‘+%s’

Questo video mostra un mini tutorial che può aiutarti.

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.