Я сделал это пару лет назад. Мой подход состоял в том, чтобы напрямую, не терять времени, размонтировать раздел, а затем
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. ~ Половина моего ~была удалена, но мне удалось вернуть все, что имело значение, через описанные выше grepping и некоторые более или менее текущие резервные копии. У меня были некоторые очень ценные (читай: отнимающие много времени) и самые последние данные измерений на диске, которые были утеряны, но я сделал четырехкратное резервное копирование. Один здесь разочаровался, другой из-за сбоя системы в школе, другой был поврежден, и сначала я не смог найти четвертый, так как по ошибке поместил его в неправильную папку :-D. Не имелrm -rЗастрял в файле, защищенном от записи, четвертый был бы съеден, так как эта папка была смонтирована с помощью sshfs в моем ~. С тех пор я гораздо осторожнее с такими вещами.
rm- это «опасная» команда UNIX / Linux (читать$ man rm). Используйте это с особой осторожностью . С учетом сказанного, это быстрый способ удалить файлы, в которых вы уверены. В современных средах Linux и Unix для настольных ПК предусмотрено решение «Корзины» , поэтому пользователь может легко восстановить случайно удаленные файлы.