Начало ответа

Я использовал photorecиз набора утилит testdiskдля восстановления некоторых данных.

Список того, что я пробовал

• Загрузка ноутбука Debian 10 (отдельная машина)
• Вставьте SSD через USB в контроллер SATA (ПЛОХАЯ ИДЕЯ!)
• Диск монтируется автоматически (не знаю, как это предотвратить)
• Начато копирование данных с помощью dd для создания резервной копии
• Недостаточно места
• Отменено задание dd
• Может быть хорошей идеей сначала скопировать данные, но я не знаю, как это сделать
• Проблемы У меня :диск имеет размер 1 ТБ, и мне нужно скопировать весь этот 1 ТБ (, наверное? я могу игнорировать обнуленные блоки? )перед проверкой с помощьюphotorec
• Внутренний SSD (ноутбук )всего 500 ГБ
• Подключенный внешний диск емкостью 4 ТБ
• отключенный твердотельный накопитель емкостью 1 ТБ (тот, с которого я пытаюсь восстановить)
• Не заморачивался с дд
• Загруженоphotorec
• инструкции здесь:https://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step
• единственное, что я сделал по-другому, это изменил типы файлов, которые он ищет, отключив их все и ища только связанные параметры .tx?и .txt(, которые включают исходные файлы.c и т. д.)

Обработка данных

• Photorec создал сотни выходных папок и тысячи файлов
• Я не понимаю правила именования/нумерации имен файлов или каталогов
• Имена файлов были беспорядочной чепухой
• Используется grep -rIwдля поиска точных совпадений целых строк слов во вложенных папках
• Произведена некоторая обработка вывода с использованием сценария bash для удаления ненужных строк
• использовал diffдля сравнения полученных совпадений
• Найдена последняя версия одного из моих исходных файлов
• Еще несколько...

Резюме

Не уверен, что это должен быть «принятый ответ» -, но описанный выше метод — это то, что я использовал для получения своих файлов.

Это не очень хороший метод, но он работает.

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

С текстовыми файлами сложнее работать, потому что система создает много ложных срабатываний из-за текстовых файлов, журналов и т. д.

Вот несколько моментов, на которые стоит обратить внимание:

• Сначала сделайте полную копию диска:dd if=/dev/sdX of=image.img bs=1M status=progress
  Работайте над этой копией (, например.photorec image.img)вместо самого диска.

• По моему (долгому )опыту, foremostлучше, чем photorecдля многих типов файлов. В зависимости от ваших типов файлов вы можете захотеть добавить пользовательские заголовки файлов в foremost, это было ОЧЕНЬ эффективно для меня в прошлом.Подробнее о выдаче/фотозаписи в моем ответе здесь

• Этот мой ответ может помочь вам найти пригодные для использования файлы из восстановленного стога сена.

• НЕ монтируйте SSD. Как уже говорилось в комментариях, монтирования только для чтения не всегда может быть достаточно для предотвращения перезаписи. Работа над ddизображениями.

Вот (умопомрачительный )трюк, который я выучил некоторое время назад и который может сработать на вас.

the directory I deleted contains all the code for my PhD

Итак, это текст. Теперь, если большая часть вашего кода находится в одном (или нескольких )файлах (с ), вы действительно можете попробовать это:

grep -ai '<this text is in my newest code revision>' image.img

Я знаю, это звучит слишком просто, но это спасло меня раньше в такой же ситуации. Вы можете добавить -C xк команде, чтобы включить заменуx(числом )строк выше и ниже совпадающей строки.

Обратите внимание, что ваш файл (s )может быть частично поврежден. Попробуйте много узоров. Начните с большого количества слов, чтобы попытаться найти точное соответствие, если нет результатов, попробуйте меньше слов.

И обязательно... ВСЕГДА делайте резервные копии . НЕ на одном диске. ПРОВЕРЬТЕ резервные копии. Вы имеете дело с текстом, я предполагаю, что это не сотни гигабайт, поэтому вы также можете настроить облачные резервные копии (, зашифрованные, конечно, )или что-то в этом роде.

Еще один совет. :Не тратьте на волнения по этому поводу больше времени, чем вам потребовалось бы для повторного -написания кода. Сохраняйте спокойствие, попробуйте все, что сможете, посмотрите, поможет ли вам мой grepметод, и если вы ничего не найдете после целого дня, лучшим решением, вероятно, будет получить последнюю резервную копию и продолжить работу оттуда.

Если вы были достаточно быстры при выключенном питании -, то после полного бинарного резервного копирования вашего раздела вы можете попробовать extundelete .
Если я правильно помню,extundelete использует журнал вашего раздела для «отмены» изменений файлов каталога, вызванных вашим rm -rf.