Восстановление состояния диска c FDE/LUKS2 до разметки его в GPT

Если вам стёртые данные «действительно» важны - не занимайтесь самолечением, а сразу несите в СЦ. Чем больше манипуляций с диском производите - тем меньше шанс восстановления.

Ну а если данные не так уж и важны - ну отформатируйте диск заново, и не сношайте никому мозги.

Забавляет, конечно, факт шифрования. Так и хочется спросить - ну что, помогло?

до шифрования пока не добрался, пока что мне всего-то mapper-luks вернуть надо так сказать что был( где сейчас GPT с Unallocated Space (по Disks как значится), дальше уже, да, dump не снял, но сохраненный ключ есть и надежда с ним открыть какой бы то не был срез luks

Ну, после того, как не найдёте LUKS, можете ещё SKUL погрепать. Но сначала бы проверить, что там вобще какие-то данные есть, по произвольным смещениям. А то может форматирование/разбиение на разделы было быстрым, но TRIM вызывался.

LUKS пока находится, и не один. Еще вот этот способ на заметку оставил

• с Magic Bytes Recovery (если я правильно понял, что это то что мне надо)

Касательно TRIM/discard есть опасение, но знаете как и есть инфа

• [SOLVED] Recover of a deleted LUKS partition

nowadays even «quick format» deletes all data / entire partition, if it’s SSD (or loop device, or virtual drive, etc.) that supports TRIM or discard

I dont think thats true. quick format doesn’t erase the files. also I managed to recover the LUKS partition and the files were intact.

сохраненный ключ есть и надежда с ним открыть какой бы то не был срез

Ключ, который подходит ко многим замкам - хороший ключ. Но вот тогда замок всё-таки будет плохой. А LUKS - это очень хороший замок. Грепать «LUKS» на разделе можете до по посинения, и то не факт, что найдете. Вот товарищ выше подсказал, что с тем же успехом вы «SKUL» можете грепать. До посинения. А если TRIM успел проехаться - всё. Геймовер.

Что в в вашей ссылке, что в других, насколько я понял, чинят LUKS на разделе, а вы продвинулись дальше в уничножении данных, у вас исходного раздела с LUKS нет, неизвестно какой из найденых grep'ом LUKS относится к суперблоку (заголовку), а какой просто строка. Вот здесь написано про второй заголовок: https://vhs.codeberg.page/post/external-backup-drive-encryption/assets/luks2_... Насколько я понял, вам нужно для найденного LUKS посмотреть что в hdr_size и потом по этому смещению посмотреть, есть ли там SKUL.

nowadays even «quick format» deletes all data

Формат ведь просто работа утилиты в user-space. А ни вы, ни по ссылке не написали, чем выполнялся этот быстрый формат. А ещё, не знаю, насколько актуально, но раньше были SSD, у которых TRIM не гарантирует, что возвращаются нули при чтении. Поэтому, только если в свойствах SSD прописано, что после TRIM нули, и SSD выдаёт не нулевые сектора, можно быть увереным, что TRIM не выполнялся.

в свойствах SSD прописано, что после TRIM нули

Ну вообще-то trim «очищает» ячейки для последующей записи, чтобы контроллер не пыхтел, одновременно очищая и записывая ячейки (приводя к катастрофическому падению скорости записи). И то не факт, что именно нулями - зависит от типа конкретной памяти и контроллера.

Ну если у него строки находятся, значит действия «стереть всё», как бы оно ни было реализовано, сделано не было.

А в чём проблема отсутствующего раздела? Обычно вполне можно угадать где он располагался, если помнишь как систему настраивал.

Слыш, ну ты надоел. Иди ка в игнор)

Я с тобой и не разговаривал. Ты пытаешься отвечать во всех темах, не имея вообще представления о том что в них обсуждается. Регулярно получается невпопад, в том числе и тут.

А ты прям гуру, всегда «впопад», ды? Системды иди учи, неуч.

Какие мать-перемать строки на LUKS-разделе? ТС если и нагрепает «LUKS» - то только случайно. И то это ему абсолютно ничего не даст.

не имея вообще представления о том что в них обсуждается

Хочу и отвечаю. Тебя это телепать не должно. Либо обоснуй свои выпады в мой адрес. А без пояснений - ты тут только клоунаду разводишь =)

Немного «просветление» происходит, спасибо, по ходу что вы описываете вот здесь подобный способ зайдествован

• https://superuser.com/questions/1893384/restore-sole-luks-2-encrypted-partition-on-hd-after-windows-created-msr-and-over

Возможно, раздел LUKS находился на смещении 2048 секторов, тогда следует попробовать losetup -f -v -r -o 1M /dev/sda

Затем попробовать смонтировать /dev/loop0 (если нет других файлов через loop) через cryptsetup и посмотреть, может он откроется.

Ещё можно попробовать file -sk /dev/loop0 так как там опция -r (read-only) операция неразрушающая. Но некоторые типы файловых систем не смонтируются в таком режиме. Но хотя бы понять есть там LUKS или нет можно.

Далее можно в скрипте попробовать перебирать оффсеты кратные 2048 секторов (1 мебибайт) и искать.

Там много разных прошивок, разные алгоритмы.

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

У SSD есть свойство, в выводе (hdparm -I) — обычно, «Deterministic read data after TRIM», что означает, после TRIM при чтении данного блока всегда будет возвращаться что-то одинаковое (обычно нули). Но, может быть и «Deterministic Read Zero after TRIM». А, если в выоде hdparm есть про поддержку TRIM, но нет «Deterministic», значит у SSD «Non-deterministic Trim». И он может при одном чтении вернуть старые данные, а при другом вернуть нули (или единицы).

не факт, что именно нулями

Я не про то, что хранится на флеше, а про то, что SSD возвращает по интерфейсу на команду READ.

чтобы контроллер не пыхтел,

Чтобы контроллер не пыхтел, там отдельный процесс сборки мусора, который может быть завязан на механизм выравнивая износа, да ещё и на механизм перепаковки из SLC-кеша...

Память штука такая, что-то помнишь, что-то помнишь, но не правильно. ТС вобще не написал, он ли устанавливал, только «форматнули», то есть не он сам форматнул. Плюс не понятно, он снял образ или «по-живому» экспериментит.

значит действия «стереть всё», как бы оно ни было реализовано, сделано не было.

Для меня «стереть всё» == «SECURITY ERASE», а ФС обычно на разделе, значит таблицу разделов стирать нельзя, то есть могло быть вызвано куча TRIM-команда (там часто небольшое кол-во секторов можно указывать). Ну и далее, если у SSD Non-deterministic Trim (редкость, но всё может быть), то какое-то время он будет отдавать старое содержимое, а потом нет.

Ну, и где-то я находил, что вобще у SSD с TRIM весело, и может быть, что «Deterministic Read Zero after TRIM» указан, а при определёныых условиях SSD выдаст не нули. TRIM не очень важная команда, видимо, её не особо тестируют разработчики прошивок.

FDE я делал, GPT и затирание FDE/LUKS получили от dualboot, где перебирали различные утилитлы/проги для работы с жестким, разделами, таблицами и какая-то из них (возможно даже при старте или даже своем закрытии сохранила предложенный результат и) резко все что винда не читает / не видит - перегнала (или форматнула) в GPT, когда были присоединены HDD и SSD на которых как раз и были FDE без таблицы, т.е. считайте что диска два и сейчас в попытках восстановить это FDE-состояние диска на каждом или хотя бы на одном (RAID не было если что).

Да. Но, только я не знаю, насколько это типично, что размер заголовка 16384 (0x4000), везде это подразумевают. Тут вот https://security.stackexchange.com/questions/227359/how-to-determine-start-an... показывают, что в hexdump и выводится «40 00» в этом случае. А у вас может быть другой размер, не знаю.

Хотя, может заголовки не повреждены и тогда перебирать через losetup + cryptsetup, как уже посоветовали. https://superuser.com/questions/1761609/how-to-recover-accidentily-deleted-lu...

Обычно trim производится по таймеру раз в неделю. Так что данные могут сохраниться. Если опция disсard не задана. discard тримит на лету при удалении файлов.

Попробуй Parted Magic, кое-что по восстановлению в нем можно.Скачать можно, только осторожно :-)

тогда перебирать через losetup + cryptsetup

я пока что не знаю и решиться не могу послать команду на физический диск, пока hexdump -C идет и идет, есть план раздобыть объемистей HDD и на него образ через ddrescue получить и с ним(и) возиться

я не знаком с этими командами, механизмами, но что-то мне подсказывает: losetup -o создаст мне новую запись на диск (еще одну) и т.д., что я уже потом в обще ничего не восстановлю (если конечно возможно)

В том числе еще и такой способ нагуглил, может не то, но вот

• https://superuser.com/questions/1412738/restore-partially-formatted-luks-drive

It should be possible to retrieve the data of the LUKS disk if you haven’t overwritten it (if it’s the second partition on the drive). But to prevent an unnecessary question: I’m sure that it’s possible, but I don’t know how.

It might be possible to recover some data, but not if you continue to write to that disk or attempt to create a new partition.

losetup точно ничего не пишет, разве что где-то в ОЗУ в таблицах ядра появляется запись, куда транслировать обращения к /dev/loopX. А вот что сделает cryptsetup я не знаю. Поянтно, что если cryptsetup будет писать в /dev/loopX, то это окажется на SSD. Хотя, у losetup есть ключ -r, тогда /dev/loopX будет read-only, но корректно ли поведёт себя cryptsetup в этом случае я не знаю.

такой способ нагуглил

Да, пожалуйста, хотите addpart, вместо losetup, пусть будет addpart. Только я не уверен в могуществе file, ИМХО, он может сказать, что есть LUKS, а cryptsetup скажет, что нет или повреждено.

есть план раздобыть объемистей HDD и на него образ через ddrescue получить и с ним(и) возиться

План хороший, но ddrescue то зачем? Ещё есть пробелемы с чтением SSD?

проблем с чтением нет, как и смарт нормальный… это просто что бы в ходе проб не затереть случаем, как и, диски сейчас в машине с убунту и я не знаю как там systemd по trim что делает, у меня все просто по старинке с discard было через fstab и crypttab. Тот же cryptsetup который вы упомянули, я тоже не знаю как он себе поведет и тут по ходу реально лучше образ снять, но все сведется как всегда к тому что дорого это, и после проб с

# hexdump -C /dev/sdX | grep LUKS

я переключусь на

# hexdump -C /dev/sdX | grep SKUL

c (0x4000) же cryptsetup repair, Part One — Magic Bytes Recovery

---  Primary:    0x0000 » LUKS\xba\xbe\x00\x02  ---
# printf 'LUKS\272\276\0\2' | 
  dd bs=1 count=8 conv=notrunc of=luksheaderdamage.img

---  Secondary:  0x4000 » SKUL\xba\xbe\x00\x02  ---
# printf 'SKUL\272\276\0\2' | 
  dd bs=1 count=8 seek="$((0x4000))" conv=notrunc of=luksheaderdamage.img

• да, у меня первый заголовок в ходе выше приведенного grep другой выводится на 2-ух дисках

Как и, печально все это видится

• https://unix.stackexchange.com/questions/746668/ssd-partition-table-deleted-of-an-encrypted-luks-linux-drive

You didn’t find the correct place, but probably the content of a tool dealing with LUKS. Redo a search on the whole disk (or disk copy). For example with hexedit, (be sure to not be able to write with it) search for either 4c554b53babe0001 (LUKS v1) or 4c554b53babe0002 (LUKS v2) (probably this last)

losetup -f -v -r -o 1M /dev/sda

то что вы описываете похоже на это Recover deleted LUKS partition

sudo losetup -o <offset> -r -f /dev/nvme0n1

Вопрос то был зачем использовать ddrescue вместо dd, если всё читается.

но все сведется как всегда к тому что дорого это

ИМХО, можно ограничиться первым гигабайтом, dd в файл, файл в loop-устройство, там искать. Но, если JSON не находится --«keyslots»:{«0» и т.д., то, наверное, не восстановить.

что-то я уже запутался, как и было столько сказано, что я даже не знаю с чего начать

вот если разве что https://unix.stackexchange.com/questions/364229/recover-deleted-luks-partition/

там только смущает sudo ecryptfs-recover-private .Private/ Не натворит ли он что(?)

Не натворит ли он что

Не знаю. Но там losetup с флагом -r, то есть read-only, то есть, не должно на SSD через /dev/loop ничего записаться. Плюс, вам бы чтобы просто cryptsetup успешно выполнился: «At this point the disk should have been mounted».

ИМХО, пробовать cryptsetup имеет смысл, только если заголовки есть, то есть команда:

hexdump ... | grep -A 5 -E 'LUKS|SKUL|«keyslots»'

выведет сначала «LUKS» и двоичные данные, потом JSON, потом «SKUL»...

попробовал так Restore a LUKS partition that was overwritten by pvcreate

# cd /tmp
# head -c 2G /dev/sdc > luksheaderdamage.img

# printf 'LUKS\272\276\0\2' | 
  dd bs=1 count=8 conv=notrunc of=luksheaderdamage.img
8+0 records in
8+0 records out
8 bytes copied, 0,000128221 s, 62,4 kB/s

# printf 'SKUL\272\276\0\2' | 
  dd bs=1 count=8 seek="$((0x4000))" conv=notrunc of=luksheaderdamage.img
8+0 records in
8+0 records out
8 bytes copied, 0,000142808 s, 56,0 kB/s

# cryptsetup repair luksheaderdamage.img
WARNING: Device luksheaderdamage.img already contains a 'PMBR' partition signature.

WARNING!
========
Really try to repair LUKS device header?

Are you sure? (Type 'yes' in capital letters): YES

# cryptsetup luksDump luksheaderdamage.img
Device luksheaderdamage.img is not a valid LUKS device.

Как и попробовал со своими <offset> (не всеми) , вот этот способ - не катит How to recover accidentily deleted LUKS partition table?

и там судя по всему не один loop* человек перепробовал

sudo cryptsetup luksOpen /dev/loop17 luksrecover

по ходу реально буду пускать

hexdump -C /dev/sdc |  grep -A 5 -E 'LUKS|SKUL|«keyslots»'

но прежде наверно все же # hexdump -C /dev/sdX | grep SKUL

получилось, открылось и смонтировалось! Файлы на месте и читаемы! cast mky, ALiEN175, Xenius

• restore sole LUKS 2 encrypted partition on HD after Windows created MSR and overwrote the partition table

# file -s /dev/sdc
/dev/sdc: LUKS encrypted file, ver 2 [, , sha256] UUID:...

что сделал? Да считайте что все «в лоб» по приведенной теме выше

I did an experiment to recreate your situation, that is, I've created an LUKS2 container, then initialized it as GPT under Windows. I'm assuming the same happened in your case.

In my experiment, I found out that encryption key is not damaged (this is good). But both (main and backup) binary headers are lost. Luckily, there isn't much data. I'm assuming you created LUKS2 container with default parameters. The UUID of your container is lost, but it's not important, probably. The primary JSON header is lost, too, but the backup JSON header remained (it is in your question).

Итак, LinuxMint-21.3 / Ubuntu-22.04:

# cd /tmp
# cryptsetup luksFormat dummy.img
# dd if=dummy.img bs=4096 count=1 skip=4 | hd
# dd if=dummy.img bs=4096 count=1 skip=4 seek=4 of=/dev/sdc conv=notrunc
# dd if=/dev/sdc of=backup-header.bin bs=4096 count=4 skip=4
# dd if=/dev/zero of=backup-header.bin bs=1 seek=448 count=64 conv=notrunc

# apt install xxd
# sha256sum backup-header.bin | awk '{print $1}' | xxd -r -p | dd of=backup-header.bin bs=1 seek=448 conv=notrunc

# dd if=backup-header.bin of=/dev/sdc bs=4096 count=4 seek=4 conv=notrunc
# cryptsetup repair /dev/sdc

# cryptsetup luksDump /dev/sdc
# file -s /dev/sdc
# cryptsetup -v --type luks2 --allow-discards luksOpen /dev/sdc luks2_sdc

# mkdir luks2_sdc
# mount -o noatime,discard /dev/mapper/luks2_sdс /tmp/luks2_sdс

• тут еще пометка что парольная фраза была такая же (пароль), как и прежде до случившегося, может это еще помогло, ну, при открытии и что бы совпадало

но прежде наверно все же # hexdump -C /dev/sdX | grep SKUL

Тот grep, с опцией -E он включал и SKUL и он бы показал, что ни нужного LUKS, ни SKUL нет, а один JSON есть...

mount без ro, возможно, преждевременно. GPT ведь в два места накопителя пишется, у вас не только первые, но и последние блоки «испорчены». Не знаю, хранилось ли что-то на последних блоках, главное, чтобы там каких-нибудь метаданных xfs не было.

И, если там действительно создавался только GTP+Microsoft reserved, то и быстрого форматирования не было, этот раздел, вроде, без файловой системы.

P.S. Вот ваша реальная история, что всегда, что для RAID, что для LUKS лучше создавать раздел. А то давно были страшилки, что винда таблицу разделов без спроса создаёт, но, ЕМНИП, я проверял и раньше такого не было.

таблицу можно пересоздать, а потом раздел без форматировлвания и файловой системы (через parted пустой). нужно только по сигнатуре LUKS найти его начало

о ты уж сам нашел этот способ.

~
❯ sudo python
Python 3.13.5 (main, Jun 21 2025, 09:35:00) [GCC 15.1.1 20250425] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> magic = b"\x4c\x55\x4b\x53\xba\xbe\x00\x02"
... fd = open("/dev/sda","rb")
... while chunk := fd.read(512):
...   if chunk.startswith(magic):
...     print(fd.tell())
...
1049088
^CTraceback (most recent call last):
  File "<python-input-1>", line 3, in <module>
    while chunk := fd.read(512):
                   ~~~~~~~^^^^^
KeyboardInterrupt
>>> magic = b"\x4c\x55\x4b\x53\xba\xbe\x00\x02"
... fd = open("/dev/nvme2n1","rb")
... while chunk := fd.read(512):
...   if chunk.startswith(magic):
...     print(fd.tell())
...
1049088
^CTraceback (most recent call last):
  File "<python-input-2>", line 4, in <module>
    if chunk.startswith(magic):
       ~~~~~~~~~~~~~~~~^^^^^^^

Я даже проверил

Тут только надо 512 отнять, так как .tell() вернет количество прочитанных байт, а чтобы узнать содержит ли блок сигнатуру его надо прочитать

(1049088/512)-1
2048 // те раздел начинается там где и должен быть (это номер сектора)

И вам спасибо, я знаете что думаю, а если бы без FDE было и GPT таблица, там LUKS и в нем XFS. Получился бы данный способ, в плане, как и, цифорки другие были бы?

пока что я восстановить сумел диск один, точнее файлы спасти - увидеть, и я не знаю, если gpt было получилось бы, как и что-то мне подсказывает получилось бы и через testdisk все это сделать была бы GPT

так ты ничего не удалял по факту. там только скриптом найти начала раздела, а потом через parted создать раздел примерного размера. на диске первые и последние 2048 секторов под gpt заняты… главное файловую систему не пересоздать - тогда все

Понимаю, но тут из уровня не знаю что и думать. По сути вернул считай, из той же оперы вопрос: по-новой создавать не надо ничего случаем?

Я просто реально уже не знаю, раз уж такое случилось во что и я не верил, я специально fde сделал, что бы винда в обще не трогала его, а тут типа, я не исключаю что смотрели что-то по обновлениям еще и откатам их, но разделы зачем трогать? Да какие разделы,- диски, и не один!

Как и вывод сам напрашивается со встречным вопросом, что бы такого не случилось и если dualboot выходит надо

• GPT/MBR -> Раздел -> LUKS -> ФС что ли делать ?

GPT/MBR -> Раздел -> LUKS -> ФС что ли делать ?

Если нет цели скрыть факт наличия LUKS раздела от посторонних, то да.
См. этот коммент: LVM. Надо ли создавать предварительно раздел или пустить под него неразмеченный диск? (комментарий) (и тему в целом).

P.S. Вот ваша реальная история, что всегда, что для RAID, что для LUKS лучше создавать раздел. А то давно были страшилки, что винда таблицу разделов без спроса создаёт, но, ЕМНИП, я проверял и раньше такого не было.

По-моему тут другое решение: не давать сомнительному софту (это и винда и не только она, мало ли он chmod 777 /dev/sda сделает) прямой доступ к диску.

мало ли он

Дак, как я понял, не ТС устроил dual boot с запуском всякой фигни, ему помогли:

форматнули

получили от dualboot, где перебирали различные утилитлы/проги

Но при этом эти «помошники» сознательно данные уничтожить не пытались. Если бы был GPT раздел, а не FDE, то ничего бы не произошло. А почему у кого-то ещё есть доступ — другой вопрос, такое часто бывает. И почему это было в случае ТС уже и не интерестно.

Ну не знаю, я бы в таком случае всё-таки не про разделы думал, а про битьё по рукам тем кто лезет куда не следует.

спасибо большое за ссылку, план за md/raid так же есть, что теперь и этим озадачен, или, знаете что, по RAID что можете сказать, там все так же? ну в плане 1+1 если делать - GPT на каждый и потом только md?

• GPT -> md -> LUKS -> XFS или
• GPT -> LUKS -> md -> XFS ?

здесь могут люди за btrfs и zfs подтянуться и сказать что там все это есть, но давайте пока стандартными средствами (и проверенными) ограничимся

знаете что, по RAID что можете сказать, там все так же?

Не знаю. Сделайте лучше отдельную тему.

xfs глючная какая-то раньше была. зачем она тебе. у меня два раздела luks с одинаковым паролем и на них btrfs в raid-1, dracut при загрузке предлагает ввести пароль от диска и автоматом им пробует разлочить другие устройства, указанные в параметрах ядра. md - это костыль в эпоху btrfs (стабильна, в ядре), bcachefs (могут выкинуть из ядра, так как автор ее ломает), zfs (стабильна, в ядре ее никогда не будет из-за лицензии)

да не, почему, нормально XFS, мне надо проще ext4 что-то было, думал JFS (из +10-летних воспоминаний), но вот знающие люди намекали-намекали и все таки ткнули пальцем

• https://wiki.archlinux.org/title/JFS#JFS_losing_files

XFS у меня было и пережило на десктопе hdd-SMR -> ssd-TLC -> ssd-QLC -> hdd-CMR, для файлов я считаю XFS вполне нормальной;

btrfs (стабильна, в ядре)

я больше жалоб за btrfs как раз нахожу, как на форуме/ах, так и в IRL, и идет это с самого начала этой ФС, когда там ВАУ было, типа, бэкап прям средствами самой ФС. Пробовал zfs-linux, но эти пуллы что-то и не осилил, особенно по открытию этой ФС в другом лине, точнее даже редакции, когда одна система stable, другая напосмотреть на соседнем разделе - testing, а тебе из zfs для теста пару файлов надо или скриптов взять;

md

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

у меня вопрос все равно остался, после восстановления такого

• https://superuser.com/questions/1893384/restore-sole-luks-2-encrypted-partition-on-hd-after-windows-created-msr-and-over

понятное дело что бы описанного «случайно» не случилось вновь - лучше в GPT разметить, но вот временно, на том что получилось,

• имеет ли смысл перекинуть данные на другой диск и сразу же в GPT тот на котором ситуация случилась, в плане, все таки где-то как-то структура нарушена
• или после такого восстановления пользоваться вполне себе можно еще?