Неправильная команда dd на основном диске — как восстановить данные?

Question 1

Я предполагаю, что таблицу разделов и загрузочный раздел можно легко воссоздать, поэтому сосредоточусь на разделе ext4.

Макет файловой системы в некоторой степени зависит от опций, используемых при ее создании. Я опишу общий случай. Вы можете увидеть, соответствует ли это вашему, запустив его dumpe2fsна устройстве (которое, как мы надеемся, найдет все метаданные верхнего уровня в кэше, а не будет считываться с диска).

Обычный размер блока для файловых систем ext4 составляет 4096 байт, поэтому вы потеряли 1024 блока.

Первым перезаписанным был блок 0, первичный суперблок. Это само по себе не проблема, поскольку есть резервные суперблоки. После этого идет таблица дескрипторов групп, которая также имеет резервные копии в файловой системе.

Затем идут битовые карты блоков и битовые карты инодов. Вот тут новости начинают становиться немного хуже. Если какие-либо из них находятся ниже блока 1024, что, скорее всего, так и есть, вы потеряли информацию о том, какие иноды и блоки используются. Эта информация избыточна и будет восстановлена fsck на основе того, что он найдет, пройдя по всем каталогам и инодам, если они не повреждены.

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

Если вы запустите dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024сейчас, вы получите резервную копию всего, что находится в вашем кэше в данный момент, смешанную с плохими данными для блоков, которые не кэшированы. Затем, после загрузки диска восстановления, вы можете сделать то же самое ddв обратном порядке, чтобы вернуть эти частично хорошие данные на диск, перезаписав все плохие вещи, которые там сейчас.

После этого вы можете обнаружить, что автоматизированные инструменты восстановления ( fsck, testdisk) работают достаточно хорошо. Если нет, у вас есть карта, которую вы можете использовать для помощи в ручном восстановлении. Используя списки "свободных блоков" из dumpe2fs, вы знаете, какие блоки следует игнорировать.

Большая часть того, что вы потеряли, вероятно, это inodes. На самом деле, вполне вероятно, что у вас не было файласодержаниев первых 4 МБ диска. (Я запустил mkfs.ext4без параметров на файле образа размером 1 ТБ, и первым блоком, не содержащим метаданных, оказался блок 9249)

Каждый инод, который вам удастся восстановить, будет идентифицировать блоки данных целого файла. И эти блоки данных могут быть расположены по всему диску, не обязательно поблизости.

День 2

Дамп, размещенный на pastebin, раскрывает отличные новости:

Group 0: (Blocks 0-32767) csum 0x9569 [ITABLE_ZEROED]
  Primary superblock at 0, Group descriptors at 1-117
  Reserved GDT blocks at 118-1141
  Block bitmap at 1142 (+1142)
  Inode bitmap at 1158 (+1158)
  Inode table at 1174-1685 (+1174)
  21349 free blocks, 8177 free inodes, 2 directories, 8177 unused inodes
  Free blocks: 11419-32767
  Free inodes: 16-8192

Поскольку мы думаем, что перезаписано только 4 МБ в начале файловой системы, нам нужно беспокоиться только о блоках 0-1023. А зарезервированные блоки GDT идут до самого блока 1141! Это тот тип повреждений, который должен быть исправлен простым e2fsck -b $backup_superblock_number(после перезагрузки). Вы можете хотя бы попробовать это с помощью , -nчтобы посмотреть, что он думает.

Answer