История изменений
Исправление intelfx, (текущая версия) :
Логи ядра?
Да, dmesg — сразу после чистой загрузки, попытки примонтировать раздел и попытки прочитать резервные суперблоки (например, тем же btrfs check
-ом).
Я бы давно скопировал раздел на другой диск и там уже копался пытаясь восстановить. Но раздел 900ГБ, а диски есть только на 500 и 300.
Ну блин, милчеловек, сами себя загнали в угол. Купить или одолжить терабайтник — не вариант? Да хоть в облако выгрузить, в тот же Backblaze (через s3ql с небольшим размером блока типа 10 MiB). Но всё равно рано или поздно придётся найти чистый диск, чтобы на него развернуть образ.
Я думаю, если ОЧЕНЬ сильно запариться, то восстановить можно, просто это будет очень долго и непомерно сложно.
Я ненастоящий сварщик, но просто с позиций общей логики кажется, что есть ровно два принципиально разных случая: либо содержимое «тегов» (authentication tags) является частью ключа и используется для расшифровки, либо наоборот, нужно только для проверки целостности.
В первом случае данные восстановить математически нельзя, во втором случае очень просто — достаточно вырезать или выключить код проверки этого тега.
А что лучше, использовать integrity или нет?
У тебя на уровне btrfs вычисляются контрольные суммы всех данных (но не криптографические). Если ты не защищаешься от атак с подменой шифротекста (chosen ciphertext attack), то dm-integrity тебе не нужно.
Неужели без него лучше восстановить данные?
Не понял. Без журнала или без dm-integrity? Без журнала всё плохо. А без dm-integrity всё хорошо, т. к. каждый сектор открытого текста соответствует ровно одному сектору шифротекста. В этом режиме таких проблем, как у тебя сейчас, возникнуть в принципе не может.
Исправление intelfx, :
Логи ядра?
Да, dmesg — сразу после чистой загрузки, попытки примонтировать раздел и попытки прочитать резервные суперблоки (например, тем же btrfs check
-ом).
Я бы давно скопировал раздел на другой диск и там уже копался пытаясь восстановить. Но раздел 900ГБ, а диски есть только на 500 и 300.
Ну блин, милчеловек, сами себя загнали в угол. Купить или одолжить терабайтник — не вариант? Да хоть в облако выгрузить, в тот же Backblaze (через s3ql с небольшим размером блока типа 10 MiB). Но всё равно рано или поздно придётся найти чистый диск, чтобы на него развернуть образ.
Я думаю, если ОЧЕНЬ сильно запариться, то восстановить можно, просто это будет очень долго и непомерно сложно.
Я ненастоящий сварщик, но просто с позиций общей логики кажется, что есть ровно два принципиально разных случая: либо содержимое «тегов» (authentication tags) является частью ключа и используется для расшифровки, либо наоборот, нужно только для проверки целостности.
В первом случае данные восстановить математически нельзя, во втором случае очень просто — достаточно вырезать или выключить код проверки этого тега.
А что лучше, использовать integrity или нет?
У тебя на уровне btrfs вычисляются контрольные суммы всех данных (но не криптографические). Если ты не защищаешься от атак с подменой шифротекста, то dm-integrity тебе не нужно.
Неужели без него лучше восстановить данные?
Не понял. Без журнала или без dm-integrity? Без журнала всё плохо. А без dm-integrity всё хорошо, т. к. каждый сектор открытого текста соответствует ровно одному сектору шифротекста. В этом режиме таких проблем, как у тебя сейчас, возникнуть в принципе не может.
Исправление intelfx, :
Логи ядра?
Да, dmesg — сразу после чистой загрузки, попытки примонтировать раздел и попытки прочитать резервные суперблоки (например, тем же btrfs check
-ом).
Я бы давно скопировал раздел на другой диск и там уже копался пытаясь восстановить. Но раздел 900ГБ, а диски есть только на 500 и 300.
Ну блин, милчеловек, сами себя загнали в угол. Купить или одолжить терабайтник — не вариант? Да хоть в облако выгрузить, в тот же Backblaze (через s3ql с небольшим размером блока типа 10 MiB). Но всё равно рано или поздно придётся найти чистый диск, чтобы на него развернуть образ.
Я думаю, если ОЧЕНЬ сильно запариться, то восстановить можно, просто это будет очень долго и непомерно сложно.
Я ненастоящий сварщик, но просто с позиций общей логики кажется, что есть два принципиально разных случая: либо содержимое «тегов» (authentication tags) является частью ключа и используется для расшифровки, либо наоборот, нужно только для проверки целостности.
В первом случае данные восстановить математически нельзя, во втором случае достаточно вырезать или выключить код проверки этого тега.
А что лучше, использовать integrity или нет?
У тебя на уровне btrfs вычисляются контрольные суммы всех данных (но не криптографические). Если ты не защищаешься от атак с подменой шифротекста, то dm-integrity тебе не нужно.
Неужели без него лучше восстановить данные?
Не понял. Без журнала или без dm-integrity? Без журнала всё плохо. А без dm-integrity всё хорошо, т. к. каждый сектор открытого текста соответствует ровно одному сектору шифротекста. В этом режиме таких проблем, как у тебя сейчас, возникнуть в принципе не может.
Исправление intelfx, :
Логи ядра?
Да, dmesg — сразу после чистой загрузки, попытки примонтировать раздел и попытки прочитать резервные суперблоки (например, тем же btrfs check
-ом).
Я бы давно скопировал раздел на другой диск и там уже копался пытаясь восстановить. Но раздел 900ГБ, а диски есть только на 500 и 300.
Ну блин, милчеловек, сами себя загнали в угол. Купить или одолжить терабайтник — не вариант? Да хоть в облако выгрузить, в тот же Backblaze (через s3ql с небольшим размером блока типа 10 MiB). Но всё равно рано или поздно придётся найти чистый диск, чтобы на него развернуть образ.
Я думаю, если ОЧЕНЬ сильно запариться, то восстановить можно, просто это будет очень долго и непомерно сложно.
Я ненастоящий сварщик, но просто с позиций общей логики кажется, что есть два принципиально разных случая: либо содержимое «тегов» (authentication tags) является частью ключа и используется для расшифровки, либо наоборот, нужно только для проверки целостности.
В первом случае данные восстановить математически нельзя, во втором случае достаточно вырезать или выключить код проверки этого тега.
А что лучше, использовать integrity или нет?
У тебя на уровне btrfs вычисляются контрольные суммы всех данных. Если ты не защищаешься от атак с подменой шифротекста, то dm-integrity тебе не нужно.
Неужели без него лучше восстановить данные?
Не понял. Без журнала или без dm-integrity? Без журнала всё плохо. А без dm-integrity всё хорошо, т. к. каждый сектор открытого текста соответствует ровно одному сектору шифротекста. В этом режиме таких проблем, как у тебя сейчас, возникнуть в принципе не может.
Исходная версия intelfx, :
Логи ядра?
Да, dmesg — сразу после чистой загрузки, попытки примонтировать раздел и попытки прочитать резервные суперблоки (например, тем же btrfs check
-ом).
Я бы давно скопировал раздел на другой диск и там уже копался пытаясь восстановить. Но раздел 900ГБ, а диски есть только на 500 и 300.
Ну блин, милчеловек, сами себя загнали в угол. Купить или одолжить терабайтник — не вариант? Да хоть в облако выгрузить, в тот же Backblaze (через s3ql с небольшим размером блока типа 10 MiB). Но всё равно рано или поздно придётся найти чистый диск, чтобы на него развернуть образ.
Я думаю, если ОЧЕНЬ сильно запариться, то восстановить можно, просто это будет очень долго и непомерно сложно.
Я ненастоящий сварщик, но просто с позиций общей логики кажется, что есть два принципиально разных случая: либо содержимое «тегов» (authentication tags) является частью ключа и используется для расшифровки, либо наоборот, нужно только для проверки целостности.
В первом случае данные восстановить математически нельзя, во втором случае достаточно вырезать или выключить код проверки этого тега.
А что лучше, использовать integrity или нет?
У тебя на уровне btrfs вычисляются контрольные суммы всех данных. Если ты не защищаешься от атак с подменой шифротекста, то dm-integrity тебе не нужно.
Неужели без него лучше восстановить данные?
Не понял. Без журнала или без dm-integrity?
Без журнала всё плохо. А без dm-integrity каждый сектор открытого текста соответствует ровно одному сектору шифротекста. В этом режиме таких проблем, как у тебя сейчас, возникнуть в принципе не может.