mdadm raid5 відновити подвійний збій диска - з поворотом (порядок приводу)

Дозвольте спочатку визнати, що я помилився, і що у мене є резервна копія більшості, але не всіх даних цього RAID. Я все ще маю надію відновити решту даних. У мене немає таких грошей, щоб віднести накопичувачі компанії, що займається відновленням.

Помилка № 0, не маючи 100% резервного копіювання. Я знаю.

У мене mdadmсистема RAID5 4х3 ТБ. Диски / dev / sd [be], всі з одним розділом /dev/sd[b-e]1. Я знаю, що RAID5 на дуже великих накопичувачах ризиковано, але все-таки я це зробив.

Останні події

RAID деградує після двох помилок накопичувача. Один накопичувач [/ dev / sdc] справді відсутній, інший [/ dev / sde] повернувся після циклу живлення, але автоматично не був повторно доданий до RAID. Тож мені залишилося 4 пристрою RAID із лише 2 активними накопичувачами [/ dev / sdb та / dev / sdd].

Помилка №1, не використовуючи копії накопичувачів диска для відновлення RAID. У мене не було ні приводів, ні часу. Помилка №2, не створюючи резервну копію суперблоку та mdadm -Eінших дисків.

Спроба відновлення

Я знову зібрав RAID в деградованому режимі з

mdadm --assemble --force /dev/md0, using /dev/sd[bde]1.

Тоді я міг отримати доступ до своїх даних. Я замінив /dev/sdcзапасний; порожній; однаковий привід.

Я видалив старий /dev/sdc1з RAID

mdadm --fail /dev/md0 /dev/sdc1

Помилка №3, не роблячи цього перед заміною накопичувача

Потім я розділив нове /dev/sdcі додав його до RAID.

mdadm --add /dev/md0 /dev/sdc1

Потім він почав відновлювати RAID. ETA 300 хв. Я стежив за процесом через /proc/mdstat2%, а потім пішов робити інші речі.

Перевірка результату

Через кілька годин (але менше 300 хвилин) я перевірив процес. Він зупинився через помилку читання на /dev/sde1.

Ось де справді починаються неприємності

Потім я видалив /dev/sde1RAID і повторно додав його. Я не можу згадати, чому я це зробив; було пізно.

mdadm --manage /dev/md0 --remove /dev/sde1
mdadm --manage /dev/md0 --add /dev/sde1

Однак /dev/sde1зараз був позначений як запасний. Тому я вирішив відтворити весь масив, використовуючи --assume-clean, використовуючи те, що, на мою думку, було правильним порядком і з /dev/sdc1відсутнім.

mdadm --create /dev/md0 --assume-clean -l5 -n4 /dev/sdb1 missing /dev/sdd1 /dev/sde1

Це спрацювало, але файлова система не була розпізнана під час спроби встановити. (Це повинно було бути EXT4).

Замовлення пристрою

Тоді я перевірив нещодавню резервну копію, яку я мав /proc/mdstat, і знайшов порядок приводу.

md0 : active raid5 sdb1[0] sde1[4] sdd1[2] sdc1[1]
      8790402048 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

Потім я згадав, що цей RAID зазнав втрати накопичувача близько року тому, і відновився після цього, замінивши несправний диск на запасний. Це, можливо, трохи заштрифувало замовлення пристрою ... так що не було приводу [3], а лише [0], [1], [2] та [4].

Я спробував знайти замовлення диска за допомогою сценарію Permute_array: https://raid.wiki.kernel.org/index.php/Permute_array.pl, але не знайшов потрібного порядку.

Запитання

Зараз у мене є два основних питання:

1. Я накрутив усі суперблоки на накопичувачах, але лише дав:

   mdadm --create --assume-clean
   

   команди (так що я не повинен бути перезаписані самі дані про /dev/sd[bde]1. Правильно чи я , що в теорії НАБЕГ може бути відновлена [припускаючи , на мить , що /dev/sde1це нормально] , якщо я просто знайти порядок правильного пристрою?

2. Чи важливо /dev/sde1вказати номер пристрою [4] в RAID? Коли я створюю його

   mdadm --create /dev/md0 --assume-clean -l5 -n4 \
     /dev/sdb1 missing /dev/sdd1 /dev/sde1
   

   йому присвоюється число [3]. Цікаво, чи це стосується обчислення блоків паритету. Якщо це виявляється важливим, як я можу відтворити масив з /dev/sdb1[0]пропущеним [1] /dev/sdd1[2] /dev/sde1[4]? Якби я міг змусити це працювати, я міг би запустити його в деградованому режимі і додати новий диск /dev/sdc1і дозволити йому повторно синхронізуватися.

Добре, якщо ви хочете зазначити мені, що це, можливо, не був найкращим способом дій, але ви виявите, що я це зрозумів. Було б чудово, якщо хтось має якісь пропозиції.

Щоб відповісти на ваші запитання,

1. Чи можна його відновити?

   • Перше, що спочатку - СТОПУЙТЕ, сядьте і просто подумайте. Так, алгоритм, розмір блоку та порядок диска є життєво важливим для отримання будь-якої файлової системи, яка була присутня, для правильної повторної збірки. Але оскільки ви перезаписали суперблоки, тепер вам залишаються спроби та помилки.
   • По-друге, чи є можливість отримати попередній макет диска? Я завжди роблю резервну копію файлу mdadm --detail>, щоб зберегти макет диска десь у безпеці. Перевірте dmesg, / var / log на наявність будь-яких доказів налаштування дисків у рейді.
   • Нарешті, якщо ви збігаєтеся з попереднім розміром фрагменту та порядком диска, можливо, ви пошкодили суперблок ext4 - є способи ретельно сканувати інші суперблоки (а є чудова програма під назвою TestDisk, яка сканує суперблоки існуючих файлових систем і намагається переглядати їх вручну: http://www.cgsecurity.org/wiki/Main_Page )

2. Оскільки sdc є новим, я б продовжував намагатися збирати вручну за допомогою відсутнього пункту, і так, sde повинен бути у правильному порядку, щоб він міг зібратися в деградованому режимі. Як тільки ви знайдете правильний макет - скопіюйте всі дані з масиву і починайте знову, документуючи макет (щоб ви більше не запускалися до цієї проблеми).

Щасти

Перш ніж робити щось інше, захопіть 'mdadm --examine / dev / sdX1' для кожного з накопичувачів, які ВИНАГИ у вашому масиві, і 'mdadm --detail / dev / md0' з цього, ви повинні мати можливість визначити точний макет.

Я просто повинен був зробити це сам, щоб відновити масив Synology в окремому запитанні:

Як відновити масив mdadm в Synology NAS з приводом у стан "E"?

Редагувати: Вибачте, щойно ви побачили, що сказали, що втратили суперблоки на всіх накопичувачах.

Ваші пізніші команди LOOK правильні. Найпростішим варіантом може бути запуск творінь із кожним можливим замовленням, а потім побачити, чи зможете ви змонтувати файлові системи та отримати доступ до них лише для читання.

Це питання давнє, і я впевнений, що зараз ніхто не може вам допомогти, але для інших, хто читає:

найнебезпечніша помилка, яку ви зробили, - це не та, яку ви пронумерували:

mdadm --create ...

на оригінальних дисках, перш ніж ви були підготовлені, знаючи, що робити. Це перезаписало метадані, тому у вас немає запису порядку замовлення, зміщення даних, розміру фрагмента тощо.

Щоб відновитись після цього, вам потрібно знову перезаписати їх правильними значеннями. Найпростіший спосіб дізнатися це - подивитися на метадані, але ви це вже знищили. Наступний спосіб - здогадатися. Вгадайте різні комбінації такої команди, з різними значеннями для будь-якого з параметрів, за винятком того, що вам відомо (4 пристрої, рівень 5), а також різним порядком диска:

mdadm --create /dev/md0 --assume-clean --metadata=1.2 --raid-devices=4 --level=5 --layout=... --chunk=512 --data-offset=128M /dev/sdb1 missing /dev/sdd1 /dev/sde1

Але оскільки ви НЕ знаєте правильного результату, знову ж таки, вам не слід запускати це на старих дисках, руйнуючи їх далі, роблячи ту саму фатальну помилку. Натомість використовуйте накладку; наприклад, ця процедура повинна працювати для збереження оригіналів.

Після того, як ви знайшли деякі аргументи, які створюють робочий масив, який ви можете fsck або змонтувати та перевірити (наприклад, перевірити контрольну суму файлу, достатньо великого, щоб перейти на всі учасники рейду, як ізо, які ви повинні зберігати з контрольною сумою / pgp підпис або распакуйте -t або gunzip -великий архів)