Per caso, ho usato rm
un file che non volevo cancellare. C'è un modo per riaverlo sotto Linux?
Per caso, ho usato rm
un file che non volevo cancellare. C'è un modo per riaverlo sotto Linux?
Risposte:
Di seguito sono riportati i passaggi generici per ripristinare i file di testo.
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.
Quindi utilizzare il comando init 1 per portare il sistema in una modalità utente singolo:
# init 1
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
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
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.
dd
e prova a trovare il file al suo interno (usando grep
, o un editor).Modifica: a volte ddrescue
funziona meglio di dd
.
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.
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 è strings
stato 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é foo
apparentemente 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 rm
mi 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 -r
bloccato 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.
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.
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.
Ecco un ottimo documento per te. Troverai un sacco di consigli pratici lì.
A proposito, ci sono due gruppi di persone:
Congratulazioni, ti sei appena promosso al gruppo 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_NUMBER
e copiarlo nella posizione originale. Utilizzare ps aux | grep APP_NAME
per trovare il PID e quindi ls -la /proc/PID/fd/
per trovare il DESCRIPTOR_NUMBER corretto.
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)!
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!
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 text
puoi inserire il nome del file e puoi specificare la directory dove vuoi ripristinare al posto di /home
.
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
rm
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.
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.