Як відновити видалений файл під Linux?

Я випадково використовував rmфайл, який я не хотів видаляти. Чи є спосіб повернути його під Linux?

Нижче наведено загальні етапи відновлення текстових файлів.

1. Спочатку скористайтеся командою wall, щоб повідомити користувачеві, що система перебуває в режимі роботи в одному режимі:

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

   Натисніть CTRL + D, щоб надіслати повідомлення.

2. Далі використовуйте команду init 1, щоб перевести систему в режим єдиного користувача:

   # init 1
   

3. Використання grep (традиційний спосіб UNIX) для відновлення файлів

   Використовуйте наступний синтаксис grep:

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

   АБО

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

   Де,

   -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.
   

   Щоб відновити текстовий файл, починаючи з слова "nixCraft" на / dev / sda1, ви можете спробувати наступну команду:

   # grep -i -a -B10 -A100 'nixCraft' /dev/sda1 > file.txt
   

4. Далі використовуйте vi, щоб переглянути файл.txt.

   Цей метод ЛИШЕ корисний, якщо видалений файл є текстовим файлом. Якщо ви використовуєте файлову систему ext2, спробуйте відновити команду.

Знайдено на веб- сайті http://www.cyberciti.biz/tips/linuxunix-recover-deleted-files.html

• Якщо це дуже-дуже важливо, візьміть диск з комп'ютера і наймайте компанію, щоб зробити це за вас.
• Якщо це дуже важливо, встановіть диск лише для читання, скопіюйте весь розділ у файл за допомогою ddта спробуйте знайти файл у ньому (за допомогою grepабо редактора).

Правка: іноді ddrescueпрацює краще, ніж dd.

Якщо ваша файлова система ext3 , використовуйте ext3grep .

Testdisk має можливість відновлення, яка повинна працювати з Linux.

Існує посібник для Linux . Зауважте, що він працює для ext2 , ext3 та ext4 .

• Єдина правильна відповідь: відновіть файл із резервної копії. Усі повинні мати резервну копію. Для дійсно важливих файлів у вас має бути дві резервні копії. Ви цього не робите? Ну, дуже погано, ось урок засвоєний (Вибачте, це звучить суворо, але я зберігаю дані, і люди не створюють резервного копіювання, поки не втратили важливих даних, це даний факт. Так, так, ти виглядаєш дурним, але так це майже всі інші).

• Гаразд, у вас немає резервного копіювання. ви повинні припинити використання файлової системи, яка містила файл ПРАВО ЗАРАЗ . Будь-яка активність запису, безумовно, може шлагувати файлові дані, які можуть (лише можуть ) залишатися на диску.

• якщо ви допустили трагічну помилку, щоб використовувати лише один розділ як кореневу файлову систему, так і / home, це означає, що ви повинні завантажуватися з іншого пристрою. ЗАРАЗ .

• Якщо ваш файл має звичайний формат (Word-файл, JPG тощо), використовуйте Photorec . Photorec може отримати найпоширеніші формати файлів.

• Ви можете спробувати запропонований раніше метод "ext3 undelete", але вам потрібно зручно використовувати командний рядок, розуміти основні внутрішні роботи Linux та ін.

• Якщо ваш файл має якийсь спеціальний формат, велика удача. Я колись написав програму Perl для сканування накопичувача на деякі спеціальні файли, і це спрацювало досить добре; але вам потрібно знати деякі програми, щоб зробити це, і бути дуже зручним і для Linux.

Я робив це пару років тому. Мій підхід полягав у тому, щоб прямо, не встигати втрачати, демонтувати розділ, а потім

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

мати файл резервної копії точного стану розділу. Потім ви зможете змонтувати розділ ще раз і продовжити справу, як зазвичай, під час пошуку видаленого файлу у створеному зображенні. Зображення, ймовірно, буде ДУЖЕ великим, оскільки вам потрібен весь "порожній" простір, тому його зберігання може бути практичною проблемою.

Тоді було просто виконувати нудні пошуки за текстовими фрагментами, які я очікував десь у супі вмісту розділів. Наприклад, щоб знайти .tex-файли, я побіг

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

яка надрукувала великий контекст навколо фрази "підрозділ" і зберегла вихід у файл, який слід шукати вручну. Я надрукував такий великий контекст, оскільки на пошук зображення знадобилося стільки часу, що я краще не зробив би це більше разів, ніж мені довелося.

Також команда stringsбула корисною для видалення бінарного сміття з виводу, але якщо я пригадую правильно, вона також позбавила всіх нових рядків, що може бути проблемою.

Щоб знайти двійкові файли таким же чином, можливо, вдасться знайти характерний заголовок або щось із певного файлу, але я думаю, що це досить велика пригода.

Короткі технічні примітки: існують технічні труднощі з відновленням диска та Ext3 / 4. Пояснювати це довго, але коротко (і неадекватно): Ext3 / 4 видаляє "маркери", які повідомляють ОС, де файли знаходяться на диску, коли ви видаляєте їх. Файли не очищаються, але ніхто не знає, де на диску вони починаються і закінчуються більше, а іноді вони навіть фрагментовані в декількох місцях. Деякі інші файлові системи просто встановлюють статуси файлів "видаленими", але зберігають дані про місцезнаходження. Потім відновити не важче, ніж подивитися на покажчики файлів із цим прапором (вони все одно мають бути доступними, якщо не надто велика активність), і тоді сподіваюся, що їх вміст не буде перезаписаний.

Що найкраще? На мій погляд, риторичний. Часті резервні копії - це відповідь на всі ці проблеми. Важливі дані без автоматизованої системи резервного копіювання - це нещасний випадок, який очікує, IMHO.

Обов’язковий особистий анекдот: я збирався зняти foo\ foo*з ~. я написав

rm -r foo<Tab>*

, що, на жаль, оскільки, fooмабуть, було символьним посиланням і єдиним файлом, що відповідає цьому, вбудована оболонка

rm -r foo\ foo *

Я натиснув Enter і сів там, дивлячись на команду, яка повинна була зайняти максимум секунду. Через трохи довший час rmзапитав, чи хочу я "видалити захищений від запису файл" щось ". Досить швидко я відчув озноб і тихо і дуже контрольовано натиснув Ctrl+c. ~ Половину мого ~було видалено, але мені вдалося повернути все значення за допомогою описаних вище знімків та деяких більш-менш поточних резервних копій. У мене були втрачені деякі дуже цінні (читання: трудомісткі) та дуже недавні дані вимірювань на диску, але я зробив чотириразове резервне копіювання. Один тут розчарувався, інший через відключення системи в школі, інший був пошкоджений, і спочатку я не міг знайти четвертого, оскільки я помилково помістив його в неправильну папку :-D. Не мавrm -rзастряг у захищеному від запису файлі, четвертий був би з'їдений, оскільки ця папка була встановлена ​​через sshfs в моєму ~. З тих пір я набагато уважніший.

Якщо це стандартний rm , я сподіваюся, у вас є резервна копія. Процедура відновлення видаленого файлу була б різною для кожної файлової системи, якщо це взагалі можна зробити. Linux не має вбудованого "кошика"; як тільки ви видалите файл, він майже не зник.

У будь-якому випадку ви хочете відключити комп'ютер - якнайшвидше, оскільки продовження роботи комп'ютера (навіть для його вимкнення) викликає запис на диск і збільшує ймовірність того, що деякі блоки, які раніше були зайняті файл буде перезаписаний Щойно ви зробите це, або покладіть його на інший комп'ютер, перезавантажте живий компакт-диск (переконайтеся, що не монтувати диск, якщо ви не змонтуєте його лише для читання), або вийміть жорсткий диск і віднесіть його до фахівця з відновлення даних.

Встановіть ваші очікування низькими. Якщо щось було написано над 'видаленими' даними, ви втратите їх.

Я зробив невелику кількість відновлення, і найкращі інструменти, які я знайшов, часто були розроблені у певних форматах. Наприклад, "photorec" був чудовим, коли я хотів відновити десятки тисяч jpegs.

Recuva також допомагала мені раніше, і це може бути найкращим вибором. (Безкоштовно, не обманюйте платити за свої оголошення)

Зрештою, якщо те, що ви втратили, є важливим, відключіть диск і перестаньте писати на ньому. Використовуйте кожен фрагмент програмного забезпечення для відновлення, яке ви зможете знайти, поки не отримаєте свої дані назад, або він перестане коштувати. Якщо це дійсно важливо, надішліть його професіоналам за високою ціною.

Якщо раніше вам пощастило з інструментом, спробуйте його ще раз, як ви знайомі з ним. Зрештою, вони не повинні записувати на диск, тому ви можете використовувати програмне забезпечення, поки не знайдете той, який працює.

Ось чудовий документ для вас. Ви знайдете безліч практичних порад там.

До речі, є дві групи людей:

1. тих, хто робить резервні копії
2. тих, хто буде робити резервні копії

Вітаю, ви щойно просунули себе до групи 2. ;-)

Якщо у вас відкрита програма, яка зараз читає файл, наприклад, VLC або LibreOffice, тоді ця надзвичайна відповідь L&U.SO допомогла мені вийти з цього безладу. Ось альтернативний спосіб зробити те саме.

Загальна ідея полягає у тому, щоб знайти посилання /proc/PID/fd/DESCRIPTOR_NUMBERта скопіювати його в початкове місце. Використовуйте, ps aux | grep APP_NAMEщоб знайти PID, а потім ls -la /proc/PID/fd/знайти правильний DESCRIPTOR_NUMBER.

"Правильна" відповідь - припустити, що не існує способу надійного відновлення, а замість цього відновити з резервних копій або клонованої системи чи перевстановити.

TestDisk - це чудовий інструмент, і є інші способи врятувати деякі дані з фізичного накопичувача залежно від файлової системи та часу видалення, але час і біль можуть бути занадто великими, тому ЗАБУТИТИ РЕКЛАМИ (а також перевірити що вони дійсні та відновлювані)!

Якщо його не перезаписали інші користувачі, то вам пощастить. Я випадково видалив свій вихідний файл cpp і застосував інструмент, який називається головним чином , який допоміг мені відновити сміття 60G cpp з диска. Нарешті, я відновив свій файл, збираючи ті сміття по частинах. Я думаю, він сканує певний зразок для конкретного типу файлу і проходить всі вставки на диску для відновлення файлів! Просто спробуйте!

Якщо випадково ви видалили файл з Linux, ви можете скористатися цією командою:

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

замість search textвас можна поставити ім'я файлу та вказати каталог, куди ви хочете відновити замість /home.

Ви можете спробувати цей сценарій. Працює чудово і призначений для використання замість RM, і я їх широко використовую зараз.

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

Особливості:

• призначений для використання замість rm
• обробляє всі аргументи, які може приймати rm
• обробляє зіткнення імені файлів з файлами, які вже є в кошику
• обробляє деякі проблеми з дозволом автоматично
• якщо rm викликається з будь-якого іншого скрипту або опосередковано, то системна команда 'rm' використовується автоматично
• відображає відповідні повідомлення про помилки, як-от ті, що виникають у rm

У мене була така ж проблема минулого тижня, і я спробував багато програм, таких як налагодження, фотореклама, ext3grep та extundelete. ext3grep була найкращою програмою для відновлення файлів. Синтаксис дуже простий:

ext3grep image.img --restore-all

або:

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’

Це відео- шоу - це міні-підручник, який може вам допомогти.