как восстановить удаленный файл под linux?

<p>случайно я использовал <code>rm</code> для файла, который не хотел удалять. есть ли способ вернуть его под linux?</p>

<p>ниже приведены общие шаги для восстановления текстовых файлов.</p><ol> <li> <p>сначала используйте команду wall, чтобы сообщить пользователю, что система отключается в однопользовательском режиме:</p> <pre><code># wall system is going down to .... please save your work. </code></pre> <p>нажмите ctrl + d, чтобы отправить сообщение.</p> </li> <li> <p>затем используйте команду init 1, чтобы перевести систему в однопользовательский режим:</p> <pre><code># init 1 </code></pre></li> <li> <p>использование grep (традиционный способ unix) для восстановления файлов</p> <p>используйте следующий синтаксис grep:</p> <pre><code>grep -b 'search-text' /dev/partition > file.txt </code></pre> <p>or</p> <pre><code>grep -a -b[size before] -a[size after] 'text' /dev/[your\_partition] > file.txt </code></pre> <p>куда,</p> <pre><code>-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. </code></pre> <p>чтобы восстановить текстовый файл, начинающийся с «nixcraft» word в/dev/sda1, вы можете попробовать следующую команду:</p> <pre><code># grep -i -a -b10 -a100 'nixcraft' /dev/sda1 > file.txt </code></pre></li> <li> <p>затем используйте vi, чтобы увидеть file.txt.</p> <p>этот метод полезен, только если удаленный файл является текстовым файлом. если вы используете файловую систему ext2, попробуйте восстановить команду.</p> </li> </ol><p>найдено на <a href="http://www.cyberciti.biz/tips/linuxunix-recover-deleted-files.html">http://www.cyberciti.biz/tips/linuxunix-recover-deleted-files.html</a> </p>

<ul> <li>если это очень-очень важно, возьмите диск с компьютера и наймите компанию, которая сделает это за вас.</li> <li>если это только очень важно, подключите диск только для чтения, скопируйте весь раздел в файл, используя <code>dd</code>, и попытайтесь найти файл в нем (используя <code>grep</code> или редактор).</li> </ul><p>правка: иногда <a href="https://www.gnu.org/software/ddrescue/ddrescue.html"><code>ddrescue</code></a> работает лучше, чем <code>dd</code>.</p>

<p>если вашей файловой системой является <a href="http://en.wikipedia.org/wiki/ext3">ext3</a> , используйте <a href="http://www.xs4all.nl/~carlo17/howto/undelete\_ext3.html">ext3grep</a> .</p>

<p> <a href="http://en.wikipedia.org/wiki/testdisk">testdisk</a> имеет опцию восстановления, которая должна работать с linux.</p><p>существует <a href="http://www.cgsecurity.org/wiki/testdisk:\_undelete\_file\_for\_ext2">прохождение для linux</a> . обратите внимание, что это работает для <a href="http://en.wikipedia.org/wiki/ext2">ext2</a> , <a href="http://en.wikipedia.org/wiki/ext3">ext3</a> и <a href="http://en.wikipedia.org/wiki/ext4">ext4</a> .</p>

<p>если это стандартный <a href="http://en.wikipedia.org/wiki/rm\_%28unix%29">rm</a> , я надеюсь, у вас есть резервная копия. процедура восстановления удаленного файла будет разной для каждой файловой системы, если это вообще возможно сделать. в linux нет встроенной корзины. как только вы удалите файл, он почти исчез.</p><p>в любом случае вы захотите отключить компьютер от сети - как можно скорее, так как продолжение работы компьютера (даже выключение) вызывает запись на диск и увеличивает вероятность того, что некоторые блоки ранее были заняты файл будет перезаписан. как только вы это сделаете, либо вставьте его в другой компьютер, перезагрузите компьютер с <a href="http://en.wikipedia.org/wiki/live\_cd">live cd</a> (не устанавливая диск, если вы не монтируете его только для чтения), или извлеките жесткий диск и перенесите его на специалист по восстановлению данных.</p>

<p>я сделал это пару лет назад. мой подход состоял в том, чтобы напрямую, не терять времени, размонтировать раздел, а затем</p><pre><code>dd if=/dev/hda1 of=backup\_image.ext3 </code></pre><p>иметь файл резервной копии точного состояния раздела. затем вы можете снова смонтировать раздел и продолжить работу в обычном режиме, когда будете искать удаленный файл в созданном вами образе. изображение, вероятно, будет очень большим, так как вам нужно все «пустое» пространство, поэтому его хранение может оказаться практической проблемой.</p><p>тогда это было просто для того, чтобы выполнять скучные поиски по фрагментам текста, которые я ожидал найти где-то в супе содержимого раздела. например. чтобы найти .tex-файлы, я побежал</p><pre><code>grep --binary-files=text -1000 "subsection" < backup\_image.ext3 > latexfiles </code></pre><p>который напечатал большой контекст вокруг фразы «подраздел» и сохранил вывод в файл для ручного поиска. я напечатал такой большой контекст, так как поиск по изображению занял так много времени, что я бы предпочел не делать это больше, чем нужно.</p><p>также команда <code>strings</code> была полезна для удаления двоичного мусора из выходных данных, но, если я правильно помню, она также удаляла все новые строки, что могло быть проблемой.</p><p>чтобы найти бинарные файлы таким же образом, можно успешно найти характерный заголовок или что-то из определенного файла, но я представляю, что это довольно большое приключение.</p><hr><p>краткие технические примечания: есть технические трудности с восстановлением диска и ext3/4. объяснять это долго, но кратко (и неадекватно): ext3/4 удаляет «маркеры», которые сообщают ос, где файлы находятся на диске, когда вы их удаляете. файлы не очищаются, но никто не знает, где на диске они начинаются и заканчиваются, а иногда они даже фрагментированы в нескольких местах. некоторые другие файловые системы просто устанавливают статусы файлов как «удаленные», но сохраняют данные о местоположении. тогда восстановить не сложнее, чем посмотреть на файловые указатели с этим флагом (они все равно должны быть доступны, если не произошло слишком много действий), и затем надеяться, что их содержимое не было перезаписано.</p><p>что лучше? риторический, на мой взгляд. частое резервное копирование является ответом на все эти проблемы. важные данные без<strong> автоматизированной </strong>системы резервного копирования - случайность, ожидающая случиться, имхо.</p><hr><p>обязательный личный анекдот: я собирался удалить <code>foo\ foo*</code> из <code>~</code>. я написал</p><pre><code>rm -r foo<tab>* </code></pre><p>к сожалению, поскольку <code>foo</code>, по-видимому, была символической ссылкой и единственным файлом, соответствующим этому, shell</p><pre><code>rm -r foo\ foo * </code></pre><p>я нажал enter и сел там, глядя на команду, которая должна была занять максимум секунду. через некоторое время <code>rm</code> спросил меня, хочу ли я «удалить файл с защитой от записи« что-то »». довольно быстро я почувствовал озноб и мягко и очень контролируемо нажал <code>ctrl+c</code>. ~ половина моего <code>~</code> была удалена, но мне удалось вернуть все, что имело значение, с помощью описанного выше поиска и некоторых более или менее текущих резервных копий. у меня были некоторые очень ценные (читай: отнимающие много времени) и самые последние данные измерений на диске, которые были утеряны, но я сделал четырехкратное резервное копирование. один здесь разочаровался, другой из-за сбоя системы в школе, другой был поврежден, и сначала я не смог найти четвертый, так как по ошибке положил его в неправильную папку :-d. если бы <code>rm -r</code> не застрял в файле, защищенном от записи, четвертый был бы съеден, так как эта папка была смонтирована через sshfs в моем <code>~</code>. с тех пор я гораздо осторожнее с такими вещами.</p>

<p>установите ваши ожидания на низком уровне. если что-то было записано поверх «удаленных» данных, вы потеряете это.</p><p>я провел небольшое количество восстановления, и лучшие инструменты, которые я нашел, часто предназначались для определенных форматов. например, «photorec» был великолепен, когда я хотел восстановить десятки тысяч jpeg.</p><p> <a href="http://www.piriform.com/recuva">recuva</a> также помог мне до сих пор и может быть вашим лучшим выбором. (это бесплатно, не обманывайте своих объявлений)</p><p>в конце дня, если то, что вы потеряли, важно, отключите диск и прекратите запись на него. используйте все части программного обеспечения для восстановления, которые сможете найти, пока не вернете свои данные или они не перестанут стоить того. если это действительно важно, отправьте его профессионалам по высокой цене.</p><p>если вам повезло с инструментом раньше, попробуйте еще раз, так как вы знакомы с ним. в конце концов, они не должны записывать на диск, поэтому вы можете использовать программное обеспечение, пока не найдете работающее.</p>

<ul> <li> <p>единственный правильный ответ: восстановить файл из резервной копии. у всех должна быть резервная копия. для действительно важных файлов у вас должно быть две резервные копии. ты не? что ж, очень плохо, вот урок (извините за грубость, но я нахожусь в хранилище данных, и люди не копируют, пока не потеряли некоторые важные данные, это факт. так что да, вы выглядите глупо, но так почти все остальные).</p> </li> <li> <p>ок, у вас нет резервной копии. вы должны<strong> остановить </strong>использовать файловую систему, которая содержала файл<strong> прямо сейчас </strong>. любая операция записи может определенно удалить данные файла, которые <em>могут</em> (только <em>могут</em>) остаются на диске.</p> </li> <li> <p>если вы допустили трагическую ошибку, указав только один раздел в качестве корневой файловой системы и/home, это означает, что вы <em>must</em> загружаетесь с другого устройства.<strong>сейчас</strong>.</p> </li> <li> <p>если ваш файл имеет какой-либо общий формат (файл word, jpg и т.д.), используйте <a href="http://www.cgsecurity.org/wiki/photorec">photorec</a> . photorec может получить наиболее распространенные форматы файлов.</p> </li> <li> <p>вы можете попробовать метод "ext3 undelete", предложенный ранее, но вам нужно уметь работать с командной строкой, понимать основные принципы работы linux и т.д.</p> </li> <li> <p>если ваш файл имеет какой-то особый формат, то повезло однажды я написал perl-программу для сканирования дисков на наличие специальных файлов, и она работала довольно хорошо; но для этого вам нужно знать некоторые программы, и с linux тоже не спеша.</p> </li> </ul>

<p>если у вас открыто приложение, которое в данный момент читает файл, такое как vlc или libreoffice, то <a href="https://unix.stackexchange.com/questions/58949/recovering-deleted-file-held-open-by-apache">этот потрясающий ответ l & u.so</a> выручил меня из этого беспорядка. вот <a href="https://unix.stackexchange.com/questions/101237/how-to-recover-files-i-deleted-now-by-running-rm">альтернативный метод</a> для того же.</p><p>основная идея заключается в том, чтобы найти ссылку в <code>/proc/pid/fd/descriptor\_number</code> и скопировать ее обратно в исходное местоположение. используйте <code>ps aux | grep app\_name</code>, чтобы найти pid, а затем <code>ls -la /proc/pid/fd/</code>, чтобы найти правильный descriptor\_number.</p>

<p>вот отличный <a href="https://help.ubuntu.com/community/datarecovery">документ</a> для вас. там вы найдете множество практических советов.</p><p>кстати, есть две группы людей:</p><ol> <li>те, кто делает резервные копии</li> <li>те, кто будет делать резервные копии</li> </ol><p>поздравляю, вы только что повысили себя до группы 2. ;-)</p>

<p>«правильный» ответ состоит в том, чтобы предположить, что нет способа надежного восстановления, и вместо этого восстановить из резервных копий или клонированной системы или переустановить.</p><p>testdisk - отличный инструмент, и существуют другие способы сохранения некоторых данных с физического диска в зависимости от файловой системы и времени удаления, но время и боль могут быть слишком большими, поэтому<strong> keep backups </strong>(а также проверьте, что они действительны и восстанавливаемы)!</p>

<p>если это не перезаписано другими пользователями, то вам повезло. я случайно удалил исходный файл cpp и использовал инструмент <a href="https://linux.die.net/man/1/foremost">foremost</a> , который помог мне восстановить 60g cpp-мусора с диска. наконец, я восстановил свой файл, собирая эти обломки по частям. я думаю, что он сканирует определенный шаблон для конкретного типа файла и обходит все inode на диске, чтобы восстановить файлы! просто попробуйте!</p>

<p>если вы случайно удалили файл из linux, вы можете использовать эту команду:</p><pre><code>find /root -name "search text" -type f -exec mv {} "/home" \; </code></pre><p>вместо <code>search text</code> вы можете указать имя файла и указать каталог, который вы хотите восстановить вместо <code>/home</code>.</p>

<p>вы можете попробовать этот скрипт. работает хорошо и предназначен для использования вместо rm, и я сейчас активно его использую.</p><p> <a href="https://github.com/nateshmbhat/safe-rm">https://github.com/nateshmbhat/safe-rm</a> </p><h3>особенности :</h3><ul> <li>предназначен для использования вместо рм</li> <li>обрабатывает все аргументы, которые может принять rm</li> <li>обрабатывает столкновения имен файлов с файлами, уже находящимися в корзине</li> <li>автоматически обрабатывает некоторые проблемы с разрешениями</li> <li>если rm вызывается из любого другого скрипта или косвенно, то системная команда 'rm' используется автоматически</li> <li>показывает соответствующие сообщения об ошибках, подобные тем, которые появляются в <code>rm</code></li> </ul>