Восстановление раздела LUKS после записи GPT-раздела с помощью Windows

Вопрос или проблема

У меня есть накопитель, который был настроен как контейнер LUKS с помощью cryptsetup luksFormat /dev/sda luks. На этом диске находился логический том, а внутри логического тома была раздел EXT4. При попытке отформатировать другой диск через непривычные интерфейсы Windows (в то время у меня не было доступа к Linux) я случайно нажал кнопку для инициализации таблицы GPT на этом диске (я был довольно уставшим). Это записало небольшой раздел на диск, занимая первые 30 МБ или около того. Этот раздел LUKS изначально занимал весь диск, и других разделов не было.

В попытках восстановить доступ к моему тому я создал новый раздел на диске с помощью gdisk, который охватывает весь диск как раздел LUKS, следуя этому ответу – но я не сделал резервную копию диска, поскольку у меня не было диска с достаточным объемом. Это могло быть фатальной ошибкой.

Суть вопроса: могу ли я что-нибудь сделать, чтобы попытаться получить доступ к этому диску с учетом этой информации, или вся надежда на восстановление данных потеряна?

Запуск hexdump -C /dev/sda | grep LUKS не дает много информации, но возвращает строки типа следующей:

00e2e4b0  2f 26 00 6a 45 61 97 4c  55 4b 53 b6 1e d4 27 bd  |/8.jEa.LUKS...'.|
649e5d00  18 3f 25 c8 b9 33 18 d7  ac ad 4c 55 4b 53 a5 5a  |.72..3....LUKS.Z|
1542bd130  00 bc 5c 3d 07 43 b0 4c  55 4b 53 50 64 2d a2 c4  |..\=.C.LUKSPd-..|
23f2530c0  ec a5 aa a0 2c ba 15 65  b1 4c 55 4b 53 49 da 0b  |....,..e.LUKSI..|
264443b50  fa 19 49 15 32 70 a0 da  07 4c 55 4b 53 e0 48 d5  |..I.2p...LUKS.H.|

Любые рекомендации будут приняты с благодарностью, хотя я и не надеюсь на много. Пожалуйста, дайте знать, если я могу предоставить больше деталей. Я видел этот конкретный ответ, но мне не удалось получить результаты с ссылкой на первую часть (cryptsetup repair не нашел ничего для работы), и я не совсем понимаю, как применить вторую часть в моем случае.

Обновление

Мне удалось восстановить заголовок и открыть его с помощью cryptsetup luksOpen --header luks.recovery /dev/loop1 luksrecovery.

Это создало два списка в выводе blkid/fdisk -l:

$ blkid
...
/dev/mapper/vg1-store: UUID="e508d1bf-e90a-4755-940c-705efff3cb3a" BLOCK_SIZE="4096" TYPE="ext4" # правильное имя и файловая система оригинального раздела
...
/dev/loop0: BLOCK_SIZE="1048576" TYPE="squashfs" # устройство цикла, созданное losetup
/dev/loop1: PTUUID="14e5f011-0427-4174-9c12-086c53e889c1" PTTYPE="gpt"
...

$ fdisk -l 
...
Диск /dev/loop0: 810.09 MiБ, 849440760 байт, 1659064 секторов
...
Диск /dev/loop1: 10..91TiB, 12000138625024 байт, 23437770752 секторов
...
/dev/loop1p1 40 23437770711 23437770672 10.9T неизвестно
...
Диск /dev/mapper/luksrecovery: 10.91 TiБ, 12000121847808 байт, 2929717240 секторов
...
Диск /dev/mapper/vg1-store: 10.91 TiБ, 12000117653504 байт, 2929716224 секторов

При попытке примонтировать /dev/mapper/vg1-store я получаю ошибки ввода-вывода:

[ 4631.852531] Ошибка ввода-вывода, устройство loop1, сектор 13220482768 операция 0x1:(WRITE) флаги 0x800 физический сегмент 2 приоритет класс 0
[ 4631.853610] buffer_io_error: 51 вызовов подавлено
[ 4631.853611] Ошибка ввода-вывода буфера на dm-1, логический блок 1652555994, потеряна асинхронная запись страницы
[ 4631.854333] Ошибка ввода-вывода буфера на dm-1, логический блок 1652555995, потеряна асинхронная запись страницы
[ 4631.854921] Ошибка ввода-вывода, устройство loop1, сектор 13220482736 операция 0x1:(WRITE) флаги 0x800 физический сегмент 1 приоритет класс 0
[ 4631.855496] Ошибка ввода-вывода буфера на dm-1, логический блок 1652555990, потеряна асинхронная запись страницы
[ 4631.856073] Ошибка ввода-вывода, устройство loop1, сектор 13220482712 операция 0x1:(WRITE) флаги 0x800 физический сегмент 2 приоритет класс 0
[ 4631.856651] Ошибка ввода-вывода буфера на dm-1, логический блок 1652555987, потеряна асинхронная запись страницы
[ 4631.857229] Ошибка ввода-вывода буфера на dm-1, логический блок 1652555988, потеряна асинхронная запись страницы
[ 4631.857799] Ошибка ввода-вывода, устройство loop1, сектор 13220481744 операция 0x1:(WRITE) флаги 0x800 физический сегмент 1 приоритет класс 0
[ 4631.858385] Ошибка ввода-вывода буфера на dm-1, логический блок 1652555866, потеряна асинхронная запись страницы
[ 4631.858965] Ошибка ввода-вывода, устройство loop1, сектор 13220481712 операция 0x1:(WRITE) флаги 0x800 физический сегмент 2 приоритет класс 0
[ 4631.859560] Ошибка ввода-вывода буфера на dm-1, логический блок 1652555862, потеряна асинхронная запись страницы
[ 4631.860144] Ошибка ввода-вывода буфера на dm-1, логический блок 1652555863, потеряна асинхронная запись страницы
[ 4631.860722] Ошибка ввода-вывода, устройство loop1, сектор 13195330672 операция 0x1:(WRITE) флаги 0x800 физический сегмент 1 приоритет класс 0
[ 4631.861312] Ошибка ввода-вывода буфера на dm-1, логический блок 1649411982, потеряна асинхронная запись страницы
[ 4631.861900] Ошибка ввода-вывода, устройство loop1, сектор 13195330600 операция 0x1:(WRITE) флаги 0x800 физический сегмент 1 приоритет класс 0
[ 4631.862490] Ошибка ввода-вывода буфера на dm-1, логический блок 1649411973, потеряна асинхронная запись страницы
[ 4631.863088] Ошибка ввода-вывода, устройство loop1, сектор 4613769480 операция 0x1:(WRITE) флаги 0x800 физический сегмент 1 приоритет класс 0
[ 4631.863691] Ошибка ввода-вывода, устройство loop1, сектор 3556805168 операция 0x1:(WRITE) флаги 0x800 физический сегмент 1 приоритет класс 0
[ 4631.864278] Ошибка ввода-вывода, устройство loop1, сектор 34816 операция 0x1:(WRITE) флаги 0x800 физический сегмент 1 приоритет класс 0
[ 4631.865658] JBD2: сбой восстановления журнала
[ 4631.865662] EXT4-fs (dm-1): ошибка загрузки журнала

Я не уверен, какие следующие шаги предпринять, и мои поиски дали довольно нерелевантные результаты. Спасибо всем еще раз за ваше терпение и помощь.

Ответ или решение

К сожалению, ваша ситуация с диском и LUKS действительно сложна, особенно после инициализации таблицы GPT, что привело к записи новых данных. Однако все еще есть несколько шагов, которые вы можете предпринять для восстановления данных.

Шаг 1: Подготовка

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

Шаг 2: Проверка доступного пространства и состояния диска

Перед началом восстановления внимательно проверьте состояние диска. С помощью утилит smartctl или hdparm проанализируйте состояние диска на наличие аппаратных ошибок. Обязательно проверьте, как ведет себя диск под нагрузкой и реагирует ли он на команды.

Шаг 3: Анализ и восстановление заголовка LUKS

Вы уже упомянули, что удалось восстановить заголовок LUKS и открыть его. Это критически важный шаг. Используйте команду cryptsetup luksDump /dev/loop1, чтобы получить информацию о ключах и версиях, которые находятся в заголовке. Если заголовок поврежден, но вы знаете его резервную копию, попробуйте восстановить его с помощью команды cryptsetup luksHeaderRestore.

Шаг 4: Попробуйте использовать fsck

Попробуйте проверить файловую систему, использовав команду fsck.ext4 /dev/mapper/vg1-store. Это может исправить некоторые ошибки, возникающие при попытке монтирования.

Шаг 5: Восстановление данных

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

Шаг 6: Создание образа диска

Если доступная память позволяет, создайте образ вашего диска с помощью ddrescue или dd. Это создаст резервную копию, которую можно использовать для дальнейших попыток восстановления. Это также позволит избежать дополнительного повреждения оригинала.

Шаг 7: Обратитесь к специалистам

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

Заключение

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

Оцените материал
Добавить комментарий

Капча загружается...