Я сделал это пару лет назад. Мой подход состоял в том, чтобы напрямую, не терять времени, размонтировать раздел, а затем
dd if=/dev/hda1 of=backup_image.ext3
иметь файл резервной копии точного состояния раздела. Затем вы можете снова смонтировать раздел и продолжить работу, как обычно, при поиске удаленного файла в созданном вами образе. Изображение, вероятно, будет ОЧЕНЬ большим, поскольку вам нужно все «пустое» пространство, поэтому его хранение может оказаться практической проблемой.
Тогда это было просто для того, чтобы выполнять скучные поиски по фрагментам текста, которые я ожидал найти где-то в супе содержимого раздела. Например, чтобы найти .tex-файлы, я побежал
grep --binary-files=text -1000 "subsection" < backup_image.ext3 > latexfiles
который напечатал большой контекст вокруг фразы «подраздел» и сохранил вывод в файл для ручного поиска. Я напечатал такой большой контекст, так как поиск по изображению занял так много времени, что я бы предпочел не делать это больше, чем нужно было.
Также команда stringsбыла полезна для удаления двоичного мусора из выходных данных, но, если я правильно помню, она также удаляла все новые строки, что могло быть проблемой.
Чтобы найти бинарные файлы таким же образом, можно успешно найти характерный заголовок или что-то из определенного файла, но я представляю, что это довольно большое приключение.
Краткие технические замечания: есть технические трудности с восстановлением диска и Ext3 / 4. Объяснять это долго, но кратко (и неадекватно): Ext3 / 4 удаляет «маркеры», которые сообщают ОС, где файлы расположены на диске, когда вы их удаляете. Файлы не очищаются, но никто не знает, где на диске они начинаются и заканчиваются, а иногда они даже фрагментированы в нескольких местах. Некоторые другие файловые системы просто устанавливают статусы файлов как «удаленные», но сохраняют данные о местоположении. Тогда восстановить не сложнее, чем посмотреть на файловые указатели с этим флагом (они все равно должны быть доступны, если не произошло слишком много действий), и затем надеяться, что их содержимое не было перезаписано.
Что лучше? Риторический, на мой взгляд. Частое резервное копирование является ответом на все эти проблемы. Важные данные без автоматизированной системы резервного копирования - авария, ожидающая, чтобы произойти, ИМХО.
Обязательный личный анекдот: собирался удалить foo\ foo*из ~. я написал
rm -r foo<Tab>*
К сожалению, поскольку, по- fooвидимому, это была символическая ссылка и единственный файл, соответствующий этому, оболочка превращена в
rm -r foo\ foo *
Я нажал Enter и сел там, глядя на команду, которая должна была занять максимум секунду. Спустя немного больше времени, rmменя спросили, не хочу ли я «удалить что-то из файла, защищенного от записи». Довольно быстро я почувствовал озноб и мягко и очень сдержанно нажал Ctrl+c. ~ Половина моего~ была удалена, но мне удалось вернуть все, что имело значение, с помощью описанного выше поиска и некоторых более или менее текущих резервных копий. У меня были некоторые очень ценные (читай: отнимающие много времени) и самые последние данные измерений на диске, которые были утеряны, но я сделал четырехкратное резервное копирование. Один здесь разочаровался, другой из-за сбоя системы в школе, другой был поврежден, и сначала я не смог найти четвертый, так как я по ошибке положил его в неправильную папку :-D. Не имелrm -rЗастрял в файле, защищенном от записи, четвертый был бы съеден, так как эта папка была смонтирована через мой sshfs ~. С тех пор я гораздо осторожнее с такими вещами.