uuid диска мог где-то в опциях монтирования или файлах настройки сохраниться, например в grub

Я случайно проехался

Машиной, что ли? Он в каком состоянии?

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

В любом случае дампы данных сделайте с каждого диска (не с массива) и экспериментируйте на них (а лучше на снепшотах)

Информация о том, что данные испорчены, тоже является информацией. Если мы пишем что-то на один из дисков, то мы лишаем систему информации о том что они ошибочные, raid5 в теории может вычислить что данные на одном из диска ошибочные, но не имеет возмжности это исправить, что приводит к порче данных по всем дискам в массиве. Конкретно raid6 в linux не поддерживает коррекцию ошибок, т.е. ведёт себя аналогично raid5. (хотя я не понимаю почему, так как raid6 содержит излишние данные, которые позволяют не только востановить битый диск, а ещё и вычислить факт порчи)

Машиной, что ли? Он в каком состоянии?

Было записано около 500 мб на одном из дисков, это уничтожило около 500 мб ext4 раздела с самого начала (и не только), в том числе нулевой superblock, который был успешно востановлен с помощью fsck.ext4. Ну и пострадали некоторые файлы.

Как выяснилось, на нулевом суперблоке, при включении опции шифрования encrypt в поле «Encryption PW Salt» записывается 16 битное случайное значение соли. Из соли и пароля формируется симмитричный ключ (рас)шифрования каталогов. Т.е. зная только пароль расшифровать каталог невозможно, так как необходимо так-же знать и соль. В свою очередь эта соль записывается ТОЛЬКО в нулевой супурблок, и при его уничтожении мы теряем всё содержимое всех зашифрованных каталогов в этой файловой системе. Что у меня и произошло.

Я так понимаю мне нужно найти бекап нулевого суперблока, последняя надежда я думаю, это найти в файлах журнала ext4. Но вероятность этого около нуля.

В целом ошибка конечно моя, но в свою очередь остаются крайне непонятные и не логичные для меня вещи:

• Почему raid6 просто херит данные, а не вычисляет факт ошибки по избыточным данным
• Нафига было делать соль размером 16 байт. Соль в 8 байт так-же успено бы защитила от словарей, но в свою очередь точно зная пароль дала бы возможность её забрутфорсить, при потери.
• Почему соль не дублируется по всем суперблокам, а хранится только в нулевом суперблоке.

Конкретно raid6 в linux не поддерживает коррекцию ошибок

А вы уверены? А может быть, есть сторонние средства (не mdadm), которые это умеют? Реконструкция raid’ов - это достаточно типовой функционал для ПО для восстановления данных (в той же r-studio есть, например, хотя я не пользовался). Так же существуют отдельные программные решения именно для восстановления raid’ов (на глаза попадался какой-то raid reconstructor - поищите. Опять же, я не пользовался).

Не надо больше про ext4 - сосредоточьтесь именно на raid’е. Почему у Вас не получается с оставшихся 5 дисков (с их копий, естественно, в текущей ситуации) собрать живой (хоть и деградировавший) массив с нужными данными?

Посмотрел, r-studio умеет работать с raid’ами от mdadm.

Если нужно вычисления факта ошибки и вообще контроль целостности данных - то посмотрите в сторону zfs. Ну, это на будущее.

Было записано около 500 мб на одном из дисков, это уничтожило около 500 мб ext4 раздела с самого начала (и не только), в том числе нулевой superblock, который был успешно востановлен с помощью fsck.ext4. Ну и пострадали некоторые файлы.

Правильно ли я понимаю, что Вы:

1. вытащили диск из массива raid6 mdadam
2. перезаписали на нём первые 500 мб
3. вставили диск обратно в массив
4. запустили пересинхронизацию
5. дождались окончания пересинхронизации
6. обнаружили порчу данных

Цепочка точно такая?

Какие именно команды Вы выполняли до вытаскивания диска? Какие команды выполняли после подключения диска? Или Вы в подключенном состоянии записали на диск 500 мб данных (без отключения его от массива либо без ?

Возможно, Вам будут полезны результаты моего теста.

Вот что я сделал:

1. создал raid6 массив из 6 дисков:

# for i in `seq 1 6`; do
  dd if=/dev/zero of=/tmp/raid-$i;
  losetup /dev/loop$i /tmp/raid-$i;
done

# mdadm  --create /dev/md0 -l 6 -n 6 /dev/loop{1,2,3,4,5,6}

2. Записал контрольную информацию на массив и проверил, что она там есть:

# echo "hello world"> /dev/md0
# head -c 14 /dev/md0

# head -c 14 /dev/md0 | xxd
00000000: 6865 6c6c 6f20 776f 726c 640a 0000       hello world...

3. Испортил информацию на первом носителе и проверил результат (всё продолжает работать):

# dd if=/dev/urandom of=/tmp/raid-1 bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00663654 s, 158 MB/s

# head -c 14 /dev/md0 | xxd
00000000: 6865 6c6c 6f20 776f 726c 640a 0000       hello world...

4. Испортил информацию на втором носителе и проверил результат (вместо данных читаются нули):

# dd if=/dev/urandom of=/tmp/raid-2 bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00815898 s, 129 MB/s

# head -c 14 /dev/md0 | xxd
00000000: 0000 0000 0000 0000 0000 0000 0000       ..............

5. Пометил первый диск как сбойный и проверил результат (обратите внимание - с массива опять читаются корректные данные):

# mdadm --manage /dev/md0 --fail /dev/loop1 
mdadm: set /dev/loop1 faulty in /dev/md0

# head -c 14 /dev/md0 | xxd
00000000: 6865 6c6c 6f20 776f 726c 640a 0000       hello world...

В общем, поэкспериментируйте на копиях дисков из Вашего массива.

А вы уверены? А может быть, есть сторонние средства (не mdadm), которые это умеют?

Если бы я был уверен во всём, о чём пишу, то не описывал бы всё в подробностях, в надежде, что мне укажут на мои явные заблуждения.

Или Вы в подключенном состоянии записали на диск 500 мб данных (без отключения его от массива либо без ?

Это произошло в подключённом состоянии. Т.е. да, без отключения. На домашнем компьютере. Из-за двух взаимосвязанных ошибок в тестовой программе.

Почему у Вас не получается с оставшихся 5 дисков (с их копий, естественно, в текущей ситуации) собрать живой (хоть и деградировавший) массив с нужными данными?

Что-то не додумался проделать самостоятельно такой тест, который Вы провели. Результаты значительно отличаются от того, что я ожидал увидеть. С учётом того, что я уже натворил, боюсь что данные востановить не получится. Но попробую, спасибо.

У меня 6 дисков, вкрученных программно через raid6.

На домашнем компьютере.

Жируешь, товарищь?

Вопрос возникает сам собой: А для чего рейды? Какой смысл их применения? Ну как? Что-нибудь откликается в голове?

Проблемный диск нужно либо выкинуть из массива, либо запустить scrub.

А для чего рейды?

Точно не для того, для чего их использует автор темы :) Судя по отсутствию у него бэкапов, он не знает первого правила RAID.

А для чего рейды? Какой смысл их применения?

Очевидно, что для уменьшения шанса потерять данные.

Проблемный диск нужно либо выкинуть из массива, либо запустить scrub.

В целом я уже сделал ряд вывыодов и алгортм как нужно было правильно поступить, но беда в том, что их нужно было было делать ДО потери данных.

Очевидно, что для уменьшения шанса потерять данные.

И как это «согласуется» с тем, что происходит у тебя?

Очевидно, что для уменьшения шанса потерять данные.

Нет. RAID нужен только для уменьшения даунтайма. Для уменьшения шанса потерять данные используется резервное копирование!

И как это «согласуется» с тем, что происходит у тебя?

Очевидно, что никак. Какой практический смысл указывать на очевидные проблемы, которые понятны как мне, так и каждому кто читает этот топик? Чисто поиздеваться над раздоблайством?

Чисто поиздеваться над раздоблайством?

Не только. Ещё на авось и на «и так сойдёт».

Нет. RAID нужен только для уменьшения даунтайма. Для уменьшения шанса потерять данные используется резервное копирование!

Если у нас есть 1мегабайт данных, и нам нужно его сохранить, то наилучшим способом хранения будет дублирование данных, причём куда-нибудь в другую локацию (на случай пожара или ещё чего). Для этого нужно ещё 1 мегабайта на хранилище), а то и 2, если мы хотим сделать две копии.

В связи с тем, что самой частой (и почти единственной) точкой отказа бывает выход жёсткого диска из строя, то дешевле всего докупить ещё 0.5 мегабайт данных и сделать raid6. Что сведёт почти к 0 потерю данных из-за этой проблемы.

Но это работает только при правильном использовании и адекватном поведении при возникновении проблем.

Это всё порочные практики, забудь о них. Учи вот это: https://www.backblaze.com/blog/the-3-2-1-backup-strategy/

В связи с тем, что самой частой (и почти единственной) точкой отказа бывает выход жёсткого диска из строя

Это не так. Вот в этой теме пример: Востановить соль, используемая для расшифровки каталогов в ext4 :)

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

Неверно! Наименее худшим способом является непрерывное копирование аля b2t. Всё остальное - либо плохо, либо очень плохо.

Вопрос в цена/результат. Самый надёжный способ, это данные блокчейн биткойна складывать, но дороговато.

Самый бюджетный это что-нибудь на коде Рида-Саломона. Например raid6. Что я и использовал.

В бюджетном варианте, качество можно очень хорошо поднять совершенно бесплатно разобравшись как формируются симмитричные ключи и как происходит восcтановление данных raid6 при колиззиях. Чего я не сделал.

Самый надёжный способ, это данные блокчейн биткойна складывать

Это кто тебе сказал? И как это связано с хранением и резервированием?

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

Им дали радиолу, чтобы наслаждаться музыкой, а они разобрали её в поисках оркестра маленьких музыкантов.

Востановить

Восстановить

Там ещё гора ошибок.

И как это связано с хранением и резервированием?

Записываешь туда что угодно, оно раскопируется на 100500 тысяч копий по всему миру и попадает в анналы. Каждый участник финансово заинтересован хранитеть эту информацию вечно. Цена вопроса, всего 15 копеек за байт.

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

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

Но в результате ты пришёл к обратному! Теорема доказана, нулевая гипотеза отвергнута!

Но в результате ты пришёл к обратному! Теорема доказана, нулевая гипотеза отвергнута!

Я пока ещё не сдался, у меня есть ещё несколько идей.

С учётом того, что я уже натворил, боюсь что данные востановить не получится.

Тогда тащите диски в лабораторию по восстановлению данных. Вполне возможно, что там Вам помогут.

Вы не в Москве, случайно?

Вполне возможно, что там Вам помогут.

А смысл? Либо соль на дисках есть и я сам её смогу найти. Либо соли нет, тогда мне уже ничего не поможет.

Не удивлючь, если в лаборатории подходящего уровня прочитают содержимое секторов «до последней перезаписи» по значению магнитной напряжнности бита, считанному с бОльшей точностью, недели бинарное 0/1. Или такое ещё не делают?

А самая частая причина потери данных - не сбой диска, а их случайное удалние руками или ошибка в программе, которая дополняет архив. Качество дисков конечно всё хуже и и хуже, но качество рук тоже не идеально.

Или такое ещё не делают?

Такое уже не делают. Примерно после объёма дисков 20-40 Гб искать остаточную намагниченность стало негде :)

А самая частая причина потери данных - не сбой диска, а их случайное удалние руками

++

Нет. RAID нужен только для уменьшения даунтайма. Для уменьшения шанса потерять данные используется резервное копирование!

Raid1 смотрит на это высказывание с удивлением.

Какая разница, какой уровень, кроме 0? Никакой.

tune2fs -l /dev/...

Выводит:

Filesystem UIID

Directory Hash Seed

Попробуй их.

UUID это не рандом, это чтото типа хеша мака и времени, но может быть и рандом полный.

но может быть и рандом полный.

К сожалению так и есть:

linux/fs/ext4/ioctl.c:

1154             err = ext4_journal_get_write_access(handle, sbi->s_sbh);
1155             if (err)
1156                 goto pwsalt_err_journal;
1157             generate_random_uuid(sbi->s_es->s_encrypt_pw_salt);
1158             err = ext4_handle_dirty_metadata(handle, NULL,
1159                              sbi->s_sbh);

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

какие выводы следует сделать юному падавану из этого топика?

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

Что-то здесь не то. RAID6 же должен переживать в том числе полную потерю одного из дисков. И даже двух.

Основан на кодах Рида — Соломона и обеспечивает работоспособность после одновременного выхода из строя любых двух дисков.

Либо Википедия врёт, либо твой raid6 не raid6.

какие выводы следует сделать юному падавану из этого топика?

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

Некопенгаген мимо крокодил

Из соли и пароля формируется симмитричный ключ (рас)шифрования каталогов.

Пруфлинк?

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

Для шифрования пароль хешировать нафиг не нужно. Значит и соль нафиг не нужна. Нафига она тогда есть?

Может она нужна, потому что хранится хешированый пароль, чтобы сверять пароль и вообще не пытаться что-то расшифровывать, если пароль не подходит к хешу? Тогда, если эту проверку пароля тупо пропустить, то диск можно расшифровать и соль для этого не нужна.

Высосал всё из пальца, ага.

Либо Википедия врёт, либо твой raid6 не raid6.

Выше привели результаты достаточно интересного теста: Востановить соль, используемая для расшифровки каталогов в ext4 (комментарий)

На основании которого можно сделать выводы, о том что raid6 пока не пнёшь, ничего востанавливать не будет.

Пруфлинк?

e4crypt.c:

574     key.mode = EXT4_ENCRYPTION_MODE_AES_256_XTS;
575     memcpy(key.raw, salt->key, EXT4_MAX_KEY_SIZE);
576     key.size = EXT4_MAX_KEY_SIZE;

707     for (j = 0, salt = salt_list; j < num_salt; j++, salt++) {
708         pbkdf2_sha512(in_passphrase, salt,
709                   EXT4_PBKDF2_ITERATIONS, salt->key);
710         generate_key_ref_str(salt);
711         insert_key_into_keyring(keyring, salt);
712     }

406 static void pbkdf2_sha512(const char *passphrase, struct salt *salt,
407               unsigned int count,
408               unsigned char derived_key[EXT4_MAX_KEY_SIZE])
409 {
410     size_t passphrase_size = strlen(passphrase);
411     unsigned char buf[SHA512_LENGTH + EXT4_MAX_PASSPHRASE_SIZE] = {0};
412     unsigned char tempbuf[SHA512_LENGTH] = {0};
413     char final[SHA512_LENGTH] = {0};
414     unsigned char saltbuf[EXT4_MAX_SALT_SIZE + EXT4_MAX_PASSPHRASE_SIZE] = {0};
415     int actual_buf_len = SHA512_LENGTH + passphrase_size;
416     int actual_saltbuf_len = EXT4_MAX_SALT_SIZE + passphrase_size;
417     unsigned int x, y;
418     __u32 *final_u32 = (__u32 *)final;
419     __u32 *temp_u32 = (__u32 *)tempbuf;
420 
421     if (passphrase_size > EXT4_MAX_PASSPHRASE_SIZE) {
422         printf("Passphrase size is %zd; max is %d.\n", passphrase_size,
423                EXT4_MAX_PASSPHRASE_SIZE);
424         exit(1);
425     }
426     if (salt->salt_len > EXT4_MAX_SALT_SIZE) {
427         printf("Salt size is %zd; max is %d.\n", salt->salt_len,
428                EXT4_MAX_SALT_SIZE);
429         exit(1);
430     }
431     assert(EXT4_MAX_KEY_SIZE <= SHA512_LENGTH);
432 
433     memcpy(saltbuf, salt->salt, salt->salt_len);
434     memcpy(&saltbuf[EXT4_MAX_SALT_SIZE], passphrase, passphrase_size);
435 
436     memcpy(&buf[SHA512_LENGTH], passphrase, passphrase_size);
437 
438     for (x = 0; x < count; ++x) {
439         if (x == 0) {
440             ext2fs_sha512(saltbuf, actual_saltbuf_len, tempbuf);
441         } else {
442             /*
443              * buf: [previous hash || passphrase]
444              */
445             memcpy(buf, tempbuf, SHA512_LENGTH);
446             ext2fs_sha512(buf, actual_buf_len, tempbuf);
447         }
448         for (y = 0; y < (sizeof(final) / sizeof(*final_u32)); ++y)
449             final_u32[y] = final_u32[y] ^ temp_u32[y];
450     }
451     memcpy(derived_key, final, EXT4_MAX_KEY_SIZE);
452 }

Высосал всё из пальца, ага.

КЭП намекает, что радужные таблицы можно делать не только с хешами, но и с ключами для шифрования.

Но для защиты от них достаточно соли размером байта в 4, т.к. это увеличит размер и так не маленькой таблицы в 4 млрд раз. Нафига было делать 16 байт совершенно не ясно.

Пароли хешируют мульён раз, чтобы их труднее было подбирать (key derivation, например PBKDF).

Выхода из строя, а не затирания диска _в обход_ RAID'а. С другой стороны, даже такие моменты могли бы детектиться и исправляться.

Пароли хешируют мульён раз, чтобы их труднее было подбирать (key derivation, например PBKDF).

Уж коли залез в код, можно даже посчитать. EXT4_PBKDF2_ITERATIONS это 0xffff раз, т.е. 65535. Видуха 1080ti заявляет 1511.9 MH/s sha-512 в секунду. Получается 1511/65535 это 20 тысяч паролей в секунду.

Т.е. востановить 4 байтную соль нужно 214748 секунд, т.е. около 2 дней. Востанавливать 16 байтную займёт 39e32 года....

[code] 1157 generate_random_uuid(sbi->s_es->s_encrypt_pw_salt); [/code]

Даже если UUID не на времени основан, а на «рандоме» - не верь им там рандома НЕТ!

Из временного UUID можно извлечь все. Из «рандомного» чуть-чуть все равно извлекается. Смотри generate_random_uuid.

[code] uuidgen –random |uuidparse uuidgen –time |uuidparse [/code] Полного рандома нет, есть указание варианта и типа, - извлекается информация.

Посмотри uuidparse свои UUID. У меня «Filesystem UIID», «Directory Hash Seed» вариант DCE тип random, а если был бы полный рандом то ни тип ни вариант не определялся. Смотри как создается UUID вариант DCE.

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

1157             generate_random_uuid(sbi->s_es->s_encrypt_pw_salt);

Даже если UUID не на времени основан, а на «рандоме» - не верь им там рандома НЕТ!

Из временного UUID можно извлечь все. Из «рандомного» чуть-чуть все равно извлекается. Смотри generate_random_uuid.

uuidgen --random |uuidparse
uuidgen --time |uuidparse

Полного рандома нет, есть указание варианта и типа, - извлекается информация.

Посмотри uuidparse свои UUID. У меня «Filesystem UIID», «Directory Hash Seed» вариант DCE тип random, а если был бы полный рандом то ни тип ни вариант не определялся. Смотри как создается UUID вариант DCE.

В некоторых UUID даже хеш функции не используются, просто кодируется мак сетевушки и время создания. И их можно даже декодировать обратно.

EXT4_PBKDF2_ITERATIONS это 0xffff раз, т.е. 65535. Видуха 1080ti заявляет 1511.9 MH/s sha-512 в секунду. Получается 1511/65535 это 20 тысяч паролей в секунду.

Не понял твоей математики.

С другой стороны, даже такие моменты могли бы детектиться и исправляться

Welcome to zfs :)

Идея крайне интересная, спасибо.

Смотри как создается UUID вариант DCE.

Но к сожалению там сделано всё на «совесть». Создаётся UUID вариант DCE, берёт данные аналогичные тому, что можно получить из /dev/urandom