Відновлення даних RAID 5 після створення нового масиву замість повторного використання


35

Люди, будь ласка, допоможіть - я новонароджений з великим головним болем під рукою (ідеальна ситуація з штормом).

У мене 3-футовий hdd на моєму ubuntu 11.04, налаштованому як програмний рейд 5. Дані копіювалися щотижня на інший окремий жорсткий диск комп'ютера, поки це повністю не вдалося і не було викинуто. Кілька днів тому у нас було відключення електроенергії, і після перезавантаження мого боксу не вдалося здійснити рейд. У своїй безмежній мудрості я ввійшов

mdadm --create -f...

команда замість

mdadm --assemble

і не помітив травертії, яку я робив до цього. Він запустив масив деградував і продовжив створення та синхронізацію, що зайняло ~ 10 годин. Після повернення я побачив, що масив успішно працює, але рейд - ні

Я маю на увазі, що окремі накопичувачі розділені (тип розділу f8), але md0пристрій - ні. З жахом усвідомлюючи те, що я зробив, я намагаюся знайти якісь рішення. Я просто молюсь, щоб --createне перезаписали весь вміст жорсткого драйвера.

Може хтось БУДЬ ЛАСКА, що мені це допоможе - дані, які знаходяться на диску, дуже важливі та унікальні ~ 10 років фотографій, документів тощо.

Чи можливо, вказавши жорсткі диски, що беруть участь у неправильному порядку, змусити mdadmїх перезаписати? коли я роблю

mdadm --examine --scan 

Я отримую щось на кшталт ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0

Досить цікаво, що ім'я використовувалося як "рейд", а не хаме хазяїна із доданим: 0.

Ось "очищені" записи конфігурації:

DEVICE /dev/sdf1 /dev/sde1 /dev/sdd1

CREATE owner=root group=disk mode=0660 auto=yes

HOMEHOST <system>

MAILADDR root


ARRAY /dev/md0 metadata=1.2 name=tanserv:0 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b


Here is the output from mdstat

cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid5 sdd1[0] sdf1[3] sde1[1]
1953517568 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>


fdisk shows the following:

fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000bf62e

Device Boot Start End Blocks Id System
/dev/sda1 * 1 9443 75846656 83 Linux
/dev/sda2 9443 9730 2301953 5 Extended
/dev/sda5 9443 9730 2301952 82 Linux swap / Solaris

Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000de8dd

Device Boot Start End Blocks Id System
/dev/sdb1 1 91201 732572001 8e Linux LVM

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00056a17

Device Boot Start End Blocks Id System
/dev/sdc1 1 60801 488384001 8e Linux LVM

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ca948

Device Boot Start End Blocks Id System
/dev/sdd1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/dm-0: 1250.3 GB, 1250254913536 bytes
255 heads, 63 sectors/track, 152001 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/dm-0 doesn't contain a valid partition table

Disk /dev/sde: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x93a66687

Device Boot Start End Blocks Id System
/dev/sde1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe6edc059

Device Boot Start End Blocks Id System
/dev/sdf1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/md0: 2000.4 GB, 2000401989632 bytes
2 heads, 4 sectors/track, 488379392 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table

За пропозиціями я очистив суперблоки та заново створив масив з --assume-cleanопцією, але зовсім не пощастивши.

Чи є якийсь інструмент, який допоможе мені відновити хоча б деякі дані? Хтось може сказати мені, що і як робить mdadm --create, коли синхронізує для знищення даних, щоб я міг написати інструмент, щоб виконувати все, що було зроблено?

Після відновлення рейду я запускаю fsck.ext4 / dev / md0 і ось вихід

root @ tanserv: / etc / mdadm # fsck.ext4 / dev / md0 e2fsck 1.41.14 (22-грудня 2010 р.) fsck.ext4: Суперблок недійсний, спробу блоку резервного копіювання ... fsck.ext4: Неправильне магічне число в супер- блокувати під час спроби відкрити / dev / md0

Суперблок не можна прочитати або не описує правильну файлову систему ext2. Якщо пристрій дійсний і він дійсно містить файлову систему ext2 (а не swap, ufs чи щось інше), то суперблок пошкоджений, і ви можете спробувати запустити e2fsck з альтернативним суперблоком: e2fsck -b 8193


За пропозицією Шейнса я спробував

root@tanserv:/home/mushegh# mkfs.ext4 -n /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=256 blocks
122101760 inodes, 488379392 blocks
24418969 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
14905 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

і запускайте fsck.ext4 з кожним блоком резервного копіювання, але всі повертають таке

root@tanserv:/home/mushegh# fsck.ext4 -b 214990848 /dev/md0
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Invalid argument while trying to open /dev/md0

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Будь-які пропозиції?

З повагою!


1
Можливо, одного дня люди можуть зрозуміти, чому RAID5 - це жахлива ідея. До цього часу 1) люди втратять дані. 2) Ми отримаємо такі питання.
Том О'Коннор

11
@Tom O'Connor ... тому що явно RAID5 винен у помилках користувача. : rolleyes:
реальності

2
Сподіваємось, відповідь Шейна може зберегти дані, але, знову ж таки, підтвердження, чому RAID поодинці не найкращий для зберігання. Також потрібні резервні копії. (але +1 за запитання та епічну відповідь, що виникла)
tombull89

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

Відповіді:


89

Гаразд - щось непокоїло мене щодо вашої проблеми, тому я запустив машину управління, щоб зануритися в поведінку, на яку слід очікувати. Я дістанусь до того, що мене клопоче за хвилину; спочатку дозвольте сказати це:

Створіть резервні копії цих дисків, перш ніж щось робити!

Можливо, ви вже зробили шкоду, що перевищує ресинхронізацію; чи можете ви уточнити, що ви мали на увазі, сказавши:

За пропозиціями я очистив суперблоки та заново створив масив з опцією --assume-clean, але зовсім не пощастило.

Якщо ви побігли mdadm --misc --zero-superblock, тоді вам слід добре.

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

dd if=/dev/sdd of=/path/to/store/sdd.img

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


Найкращий сценарій випадку

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

Вбудований масив максимально загальнодоступний і за замовчуванням - 512k шматки, ліво-симетричний макет, диски в літерному порядку .. нічого особливого.

root@test:~# mdadm --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Все йде нормально; давайте зробимо файлову систему та додамо до неї деякі дані.

root@test:~# mkfs.ext4 /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=512 blocks, Stripe width=1024 blocks
51000 inodes, 203776 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
root@test:~# mkdir /mnt/raid5
root@test:~# mount /dev/md0 /mnt/raid5
root@test:~# echo "data" > /mnt/raid5/datafile
root@test:~# dd if=/dev/urandom of=/mnt/raid5/randomdata count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.706526 s, 7.2 MB/s
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Добре. У нас є файлова система і деякі дані ("дані" в datafile, і 5MB варто випадкових даних з цим SHA1 хеш в randomdata) на ній; давайте подивимося, що станеться, коли ми робимо відтворення.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[2] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Resync дуже швидко закінчився цими крихітними дисками, але це сталося. Тож ось що мене клопоче від раніше; ваш fdisk -lвихід. Відсутність таблиці mdпристроїв на пристрої взагалі не є проблемою, як очікується. Ваша файлова система знаходиться безпосередньо на пристрої підробленого блоку, без таблиці розділів.

root@test:~# fdisk -l
...
Disk /dev/md1: 208 MB, 208666624 bytes
2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/md1 doesn't contain a valid partition table

Так, ніякого перегородкового столу. Але ...

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks

Ідеально дійсна файлова система після пересинхронізації. Так що це добре; давайте перевіримо наші файли даних:

root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Солідно - взагалі немає корупції даних! Але це з цілком однаковими налаштуваннями, тому нічого не було відображено по-різному між двома групами RAID. Давайте опустимо цю річ, перш ніж ми спробуємо її зламати.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1

Зроби крок назад

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

Операція XOR для обчислення парності виглядає приблизно так:

DISK1  DISK2  DISK3  DISK4  PARITY
1      0      1      1    = 1
0      0      1      1    = 0
1      1      1      1    = 0

Отже, паритет розкинувся між дисками.

DISK1  DISK2  DISK3  DISK4  DISK5
DATA   DATA   DATA   DATA   PARITY
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA

Ресинхронізація, як правило, робиться під час заміни мертвого чи відсутнього диска; це також робиться mdadm createдля того, щоб переконатися, що дані на дисках співпадають з тим, як має виглядати геометрія RAID. У такому випадку останній диск у специфікації масиву - той, який "синхронізований" - усі існуючі дані на інших дисках використовуються для синхронізації.

Отже, всі дані на «новому» диску стираються та відновлюються; або будувати свіжі блоки даних з парності блоків для того, що там повинно було бути, або будувати нові блоки парності.

Приємно, що процедура обох цих речей абсолютно однакова: операція XOR над даними з решти дисків. Процес пересинхронізації в цьому випадку може мати в своєму макеті те, що певний блок повинен бути блоком паритету, і думаю, що він створює новий блок паритету, коли він фактично створює старий блок даних. Тож навіть якщо він думає, що це будує:

DISK1  DISK2  DISK3  DISK4  DISK5
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA
DATA   DATA   PARITY DATA   DATA

... це може бути просто перебудова DISK5з макетом вище.

Таким чином, дані можуть залишатися послідовними, навіть якщо масив побудований неправильно.


Кидання мавпи у творах

(не гайковий ключ; ціла мавпа)

Тест 1:

Давайте зробимо масив у неправильному порядку! sdc, то sdd, тоді sdb..

root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Гаразд, це все добре і добре. Чи є у нас файлова система?

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Ні! Чому так? Тому що, хоча всі дані є, це в неправильному порядку; те, що колись 512 Кб А, то 512 Кб B, A, B і так далі, тепер перемістили в B, A, B, A. Диск тепер схожий на перемикання до перевірки файлової системи, він не запуститься. Результат роботи mdadm --misc -D /dev/md1дає нам більше деталей; Це виглядає приблизно так:

Number   Major   Minor   RaidDevice State
   0       8       33        0      active sync   /dev/sdc1
   1       8       49        1      active sync   /dev/sdd1
   3       8       17        2      active sync   /dev/sdb1

Коли це має виглядати так:

Number   Major   Minor   RaidDevice State
   0       8       17        0      active sync   /dev/sdb1
   1       8       33        1      active sync   /dev/sdc1
   3       8       49        2      active sync   /dev/sdd1

Отже, це все добре і добре. Цього разу ми замінили цілу купу блоків даних з новими блоками паритету. Відновіть, за допомогою правильного замовлення зараз:

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks

Акуратно, там ще є файлова система! Ще отримали дані?

root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Успіху!

Тест 2

Гаразд, давайте змінимо розмір шматка і подивимось, чи отримає це нас деяка ламкість.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Так, так, це шланг при такому налаштуванні. Але ми можемо одужати?

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Успіх, знову ж таки!

Тест 3

Це той, на який я думав, що точно вбиває дані - давайте зробимо інший алгоритм компонування!

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --layout=right-asymmetric --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 1 [3/3] [UUU]

unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).

Страшно і погане - він думає, що знайшов щось, і хоче зробити щось виправлення! Ctrl+ C!

Clear<y>? cancelled!

fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1

Гаразд, криза запобігла. Давайте подивимось, чи зберігаються дані незмінними після повторної синхронізації з неправильним компонуванням:

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Успіху!

Тест 4

Давайте також просто докажемо, що обнулення суперблоку не є шкідливим реально швидко:

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Так, нічого страшного.

Тест 5

Давайте просто кинемо все, що у нас є. Усі 4 попередні тести, разом.

  • Неправильне замовлення пристрою
  • Неправильний розмір шматка
  • Неправильний алгоритм компонування
  • Нульові суперблоки (ми зробимо це між обома творіннями)

Вперед!

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 --layout=right-symmetric /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
      204672 blocks super 1.2 level 5, 64k chunk, algorithm 3 [3/3] [UUU]

unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1

Вирок?

root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 13/51000 files, 17085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Ого.

Отже, схоже, що жодна з цих дій жодним чином не зіпсувала дані. Я був дуже здивований цим результатом, відверто кажучи; Я очікував помірних шансів втрати даних щодо зміни розміру шматка, а також певної втрати на зміні макета. Я щось сьогодні дізнався.


Отже .. Як я можу отримати свої дані ??

Стільки інформації, яку ви маєте про стару систему, були б вам надзвичайно корисні. Якщо ви знаєте тип файлової системи, якщо у вас є якісь старі копії /proc/mdstatз інформацією про порядок приводу, алгоритм, розмір фрагмента та версію метаданих. Чи налаштовано сповіщення електронною поштою mdadm? Якщо так, знайдіть старий; якщо ні, перевірте /var/spool/mail/root. Перевірте, ~/.bash_historyчи існує ваша оригінальна збірка.

Отже, перелік речей, які слід зробити:

  1. Створіть резервні копії дисків, ddперш ніж робити щось !!
  2. Спробуйте до fsckпоточного, активного md - ви, можливо, щойно траплялися будувати в тому ж порядку, що і раніше. Якщо ви знаєте тип файлової системи, це корисно; використовувати цей конкретний fsckінструмент. Якщо будь-який із інструментів пропонує щось виправити, не дозволяйте їм, якщо ви не впевнені, що дійсно знайшли дійсну файлову систему! Якщо fsckвам пропонують щось виправити, не соромтесь залишити коментар, щоб запитати, чи це насправді допомагає чи просто збирається зайняти дані.
  3. Спробуйте створити масив з різними параметрами. Якщо у вас є стара /proc/mdstat, то ви можете просто імітувати те, що на ній показано; якщо ні, то ви ніби в темряві - спроба всіх різних замовлень приводу є розумною, але перевірка всіх можливих розмірів шматка при кожному можливому замовленні є марною. Для кожного, fsckщоб побачити, чи отримаєте ви щось перспективне.

Отже, ось це. Вибачте за роман, не соромтесь залишити коментар, якщо у вас є якісь питання, і удачі!

виноска: менше 22 тис. символів; 8k + сором'язлива обмеження довжини


8
Це одна дивовижна відповідь.
Антуан Бенкемун

3
Я навіть не знаю, що сказати ... BRAVO !!! Кудос Шейн Медден. Я збираюся створити резервну копію дисків і розпочати роботу з вашими пропозиціями. Дякую, насправді великої подяки !!!
Бригад'єрен

3
Я просто ... вау. Блискуча відповідь. Я думаю, що єдиною відповіддю, щоб пробити межу 30 000 символів, є есе Евана Андерсона "Як працює підмережа".
tombull89

3
Найкраща відповідь на SF коли-небудь, наскільки я стурбований.
Chopper3

14
Ви, пане, виграєте Інтернет.
Марк Хендерсон

5

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

Однак я не впевнений, що процес створення нового масиву пішов і знищив усі дані, тому це може бути останнім шансом.


Велике спасибі Марку. Я спробую. Чи знаєте ви, чи змінює він накопичувачі? Якщо так, я зроблю копію диска, а також спробуйте з іншими інструментами.
Бригад’єрен

@Brigadieren - ні, вибачте, я недостатньо знайомий з тонкощами того, як працює RAID5.
Марк Хендерсон

@Brigadieren Згідно з документацією на mdadm , процес створення не знищить дані, просто пересинхронізується, але якщо для нього обрана геометрія, яка не збігалася з вашим оригіналом, можливо, вона знищила дані при написанні нового паритету. Якщо у мене з’явиться трохи вільного часу пізніше, я можу побачити, як відтворити вашу ситуацію у вітчизняній машині, щоб побачити, чи можу я додати якусь інформацію. Я рекомендую захопити повні копії накопичувачів перед тим, як взагалі спробувати відновити кроки, які записують на диски - можливо, ви захочете переглянути додаткові диски, щоб зробити копії.
Шейн Мадден

Я просто не впевнений, що спричинило синхронізацію - той факт, що масив був деградований в першу чергу (через відключення електроенергії) чи щось інше? Цікаво, чи робить mdadm --create якесь розрізнення, чи визначаю я порядок приводу інакше, ніж було вказано спочатку?
Бригад’єрен

@Brigadieren Sync завжди відбувається під час створення.
Шейн Мадден

5

У мене була подібна проблема:
після виходу з ладу програмного масиву RAID5 я звільнився, mdadm --createне даючи його --assume-clean, і більше не міг змонтувати масив. Після двох тижнів копання я нарешті відновив усі дані. Сподіваюся, що наведена нижче процедура врятує чийсь час.

Довга історія Коротка

Проблема була викликана тим, що mdadm --createстворив новий масив, який відрізнявся від початкового у двох аспектах:

  • різний порядок перегородок
  • різні зміщення даних RAID

Як було показано у блискучій відповіді Шейна Маддена , mdadm --createв більшості випадків дані не знищують даних! Після знаходження порядку розподілу та зміщення даних я міг відновити масив і витягнути з нього всі дані.

Передумови

У мене не було резервних копій суперблоків RAID, тому все, що я знав, це те, що це масив RAID5 на 8 розділах, створених під час встановлення Xubuntu 12.04.0. У ньому була файлова система ext4. Ще однією важливою інформацією була копія файлу, який також зберігався в масиві RAID.

Інструменти

Для всієї роботи було використано живий компакт-диск Xubuntu 12.04.1. Залежно від вашої ситуації, вам можуть знадобитися деякі з наступних інструментів:

версія mdadm, яка дозволяє задати зміщення даних

sudo apt-get install binutils-dev git
git clone -b data_offset git://neil.brown.name/mdadm
cd mdadm
make

bgrep - пошук бінарних даних

curl -L 'https://github.com/tmbinc/bgrep/raw/master/bgrep.c' | gcc -O2 -x c -o bgrep -

hexdump, e2fsck, mount та шістнадцятковий калькулятор - стандартні інструменти від репостів

Почніть з повної резервної копії

Ім'я файлів пристрою, наприклад, /dev/sda2 /dev/sdb2тощо, не є стійким, тому краще записати серійні номери ваших дисків, задані

sudo hdparm -I /dev/sda

Потім підключіть зовнішній жорсткий диск та створіть резервну копію кожного розділу RAID-масиву таким чином:

sudo dd if=/dev/sda2 bs=4M | gzip > serial-number.gz

Визначте оригінальний макет RAID5

Тут описані різні макети: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Щоб знайти, як смуги даних були організовані в початковому масиві, вам потрібна копія випадкового вигляду файлу, який ви знаєте зберігається на масиві. Стандартний розмір шматка, який використовується зараз, mdadmстановить 512 Кб. Для масиву N розділів вам потрібен файл розміром принаймні (N + 1) * 512KB. Jpeg або відео хороші, оскільки надають відносно унікальні підрядки двійкових даних. Припустимо, наш файл називається picture.jpg. Ми читаємо 32 байти даних у позиціях N + 1, починаючи з 100 к і збільшуючи на 512 к:

hexdump -n32 -s100k -v -e '/1 "%02X"' picture.jpg ; echo
DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2
hexdump -n32 -s612k -v -e '/1 "%02X"' picture.jpg ; echo
AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7
hexdump -n32 -s1124k -v -e '/1 "%02X"' picture.jpg ; echo
BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA
...

Потім ми здійснюємо пошук подій усіх цих байтарів на всіх наших необроблених розділах, тому в цілому (N + 1) * N команд, як це:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sda2
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdb2
...
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdh2
/dev/sdh2: 52a7ff000
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/sda2
/dev/sdb2: 52a87f000
...

Ці команди можна виконувати паралельно для різних дисків. Сканування 38 Гб розділу займало близько 12 хвилин. У моєму випадку кожен 32-байтовий рядок був знайдений лише один раз серед усіх восьми дисків. Порівнюючи компенсації, повернені bgrep, ви отримуєте таке зображення:

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          | P |   |   |   |   |   |   | 1 |
| 52a87f000          | 2 | 3 | 4 | 5 | 6 | 7 | 8 | P |
| 52a8ff000          |   |   |   |   |   |   | P | 9 |

Ми бачимо нормальний лівосиметричний макет, який є типовим для mdadm. Що ще важливіше, зараз ми знаємо порядок перегородок. Однак ми не знаємо, який розділ є першим у масиві, оскільки вони можуть бути зрушені циклічно.

Зауважте також відстань між знайденими зміщеннями. У моєму випадку це було 512 Кб. Розмір шматка насправді може бути меншим за цю відстань, і в цьому випадку фактична компонування буде іншою.

Знайдіть оригінальний розмір шматка

Ми використовуємо один і той же файл, picture.jpgщоб читати 32 байти даних через різні проміжки часу. Зверху ми знаємо, що дані при зміщенні 100k лежать /dev/sdh2, при зміщенні 612k є /dev/sdb2, а при 1124k - at /dev/sdd2. Це показує, що розмір шматка не більше 512 КБ. Ми перевіряємо, що вона не менше 512 КБ. Для цього ми скидаємо байтінгрінг при зміщенні 356k і дивимося, на якому розділі він сидить:

hexdump -n32 -s356k -v -e '/1 "%02X"' P1080801.JPG ; echo
7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A
sudo ./bgrep 7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A /dev/sdb2
/dev/sdb2: 52a83f000

Він знаходиться на тому ж розділі, що і зсув 612k, що вказує, що розмір шматка не становить 256 КБ. Ми усуваємо менші розміри шматка аналогічно. Зрештою, з 512 КБ шматки були єдиною можливістю.

Знайдіть першу секцію у макеті

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

Для початку ми створюємо масив із правильним порядком розділів, який ми знайшли раніше:

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sda2 /dev/sdh2

Ми перевіряємо, чи виконується наказ, видаючи

sudo mdadm --misc -D /dev/md126
...
Number   Major   Minor   RaidDevice State
   0       8       18        0      active sync   /dev/sdb2
   1       8       50        1      active sync   /dev/sdd2
   2       8       34        2      active sync   /dev/sdc2
   3       8       66        3      active sync   /dev/sde2
   4       8       82        4      active sync   /dev/sdf2
   5       8       98        5      active sync   /dev/sdg2
   6       8        2        6      active sync   /dev/sda2
   7       8      114        7      active sync   /dev/sdh2

Тепер ми визначимо зрушення N + 1 відомих байтарів у масиві RAID. Я запускаю сценарій на ніч (Live CD не запитує пароль на sudo :):

#!/bin/bash
echo "1st:"
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126
echo "2nd:"
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/md126
echo "3rd:"
sudo ./bgrep BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA /dev/md126
...
echo "9th:"
sudo ./bgrep 99B5A96F21BB74D4A630C519B463954EC096E062B0F5E325FE8D731C6D1B4D37 /dev/md126

Вихід із коментарями:

1st:
/dev/md126: 2428fff000 # 1st
2nd:
/dev/md126: 242947f000 # 480000 after 1st
3rd:                   # 3rd not found
4th:
/dev/md126: 242917f000 # 180000 after 1st
5th:
/dev/md126: 24291ff000 # 200000 after 1st
6th:
/dev/md126: 242927f000 # 280000 after 1st
7th:
/dev/md126: 24292ff000 # 300000 after 1st
8th:
/dev/md126: 242937f000 # 380000 after 1st
9th:
/dev/md126: 24297ff000 # 800000 after 1st

На основі цих даних ми бачимо, що 3-й рядок не знайдено. Це означає, що шматок at /dev/sdd2використовується для паритету. Ось ілюстрація позицій паритету в новому масиві:

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          |   |   | P |   |   |   |   | 1 |
| 52a87f000          | 2 | P | 4 | 5 | 6 | 7 | 8 |   |
| 52a8ff000          | P |   |   |   |   |   |   | 9 |

Наша мета полягає в тому, щоб визначити, з якого розділу розпочати масив, щоб зрушити шматки парності в потрібне місце. Оскільки паритет повинен бути зміщений двома відрізками вліво, послідовність розділів повинна бути зміщена на два кроки праворуч. Таким чином, правильний макет для цього зміщення даних такий ahbdcefg:

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sda2 /dev/sdh2 /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 

На даний момент наш RAID-масив містить дані в потрібній формі. Можливо, вам пощастить, щоб зсув даних RAID був таким самим, як це був у вихідному масиві, і тоді ви, швидше за все, зможете змонтувати розділ. На жаль, це не було моєю справою.

Перевірка узгодженості даних

Ми перевіряємо, що дані узгоджуються на смузі фрагментів, витягуючи копію picture.jpgз масиву. Для цього ми знаходимо зміщення 32-байтового рядка на 100 к:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

Потім виводимо з результату 100 * 1024 і використовуємо отримане десяткове значення в skip=параметрі для dd. count=Має розмір picture.jpgв байтах:

sudo dd if=/dev/md126 of=./extract.jpg bs=1 skip=155311300608 count=4536208

Перевірте, що extract.jpgце те саме, що picture.jpg.

Знайдіть зміщення даних RAID

Сторонне позначення: за замовчуванням зміщення даних для mdadmверсії 3.2.3 становить 2048 секторів. Але ця величина з часом змінювалася. Якщо вихідний масив використовував менший зсув даних, ніж ваш поточний mdadm, то mdadm --createбез цього --assume-cleanможна замінити початок файлової системи.

У попередньому розділі ми створили масив RAID. Перевірте, який саме RAID-дані компенсували, видавши для деяких окремих розділів:

sudo mdadm --examine /dev/sdb2
...
    Data Offset : 2048 sectors
...

2048 512-байтних секторів становить 1 МБ. Оскільки розмір фрагмента становить 512 КБ, поточний зсув даних становить два шматки.

Якщо в цей момент у вас є двосхилий зсув, він, ймовірно, досить малий, і ви можете пропустити цей параграф.
Ми створюємо масив RAID5 зі зміщенням даних на один фрагмент 512KB. Починаючи один відрізок раніше, зміщуємо паритет на один крок вліво, таким чином ми компенсуємо, переміщуючи послідовність розділів на один крок вліво. Отже, для компенсації даних 512 Кб, правильний макет hbdcefga. Ми використовуємо версію, mdadmяка підтримує зміщення даних (див. Розділ Інструменти). Це компенсується в кілобайтах:

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdh2:512 /dev/sdb2:512 /dev/sdd2:512 /dev/sdc2:512 /dev/sde2:512 /dev/sdf2:512 /dev/sdg2:512 /dev/sda2:512

Тепер ми шукаємо дійсний суперблок ext4. Структуру суперблоку можна знайти тут: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
Ми скануємо початок масиву на предмет виникнення магічного числа, s_magicза яким слідує s_stateі s_errors. Шукати слід:

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

Приклад команди:

sudo ./bgrep 53EF01000100 /dev/md126
/dev/md126: 0dc80438

Магічне число починається з 0x38 байт у суперблок, тому ми підсумовуємо 0x38, щоб обчислити зміщення та вивчити весь суперблок:

sudo hexdump -n84 -s0xDC80400 -v /dev/md126
dc80400 2000 00fe 1480 03f8 cdd3 0032 d2b2 0119
dc80410 ab16 00f7 0000 0000 0002 0000 0002 0000
dc80420 8000 0000 8000 0000 2000 0000 b363 51bd
dc80430 e406 5170 010d ffff ef53 0001 0001 0000
dc80440 3d3a 50af 0000 0000 0000 0000 0001 0000
dc80450 0000 0000                              

Здається, це дійсний суперблок. s_log_block_sizeполе в 0x18 дорівнює 0002, тобто розмір блоку дорівнює 2 ^ (10 + 2) = 4096 байт. s_blocks_count_loна 0x4 - це 03f81480 блоків, що становить 254 Гб. Виглядає добре.

Тепер ми перевіряємо наявність перших байтів суперблока, щоб знайти його копії. Зверніть увагу на перегортання байтів у порівнянні з виведенням з гексадуми

sudo ./bgrep 0020fe008014f803d3cd3200 /dev/md126
/dev/md126: 0dc80400    # offset by 1024 bytes from the start of the FS        
/dev/md126: 15c80000    # 32768 blocks from FS start
/dev/md126: 25c80000    # 98304
/dev/md126: 35c80000    # 163840
/dev/md126: 45c80000    # 229376
/dev/md126: 55c80000    # 294912
/dev/md126: d5c80000    # 819200
/dev/md126: e5c80000    # 884736
/dev/md126: 195c80000
/dev/md126: 295c80000

Це ідеально співпадає з очікуваними позиціями резервних суперблоків:

sudo mke2fs -n /dev/md126
...
Block size=4096 (log=2)
...
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872

Отже, файлова система починається зі зміщення 0xdc80000, тобто 225792KB від запуску розділу. Оскільки у нас є 8 розділів, з яких один призначений для паритету, ми ділимо зміщення на 7. Це дає 33030144 байт зміщення на кожному розділі, що становить точно 63 відрізка RAID. А оскільки поточне зміщення даних RAID становить один шматок, ми робимо висновок, що початковий зсув даних становив 64 шматки, або 32768 Кб. Зсув hbdcefga63 рази вправо дає макет bdcefgah.

Ми нарешті побудуємо правильний масив RAID:

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2:32768 /dev/sdd2:32768 /dev/sdc2:32768 /dev/sde2:32768 /dev/sdf2:32768 /dev/sdg2:32768 /dev/sda2:32768 /dev/sdh2:32768
sudo fsck.ext4 -n /dev/md126
e2fsck 1.42 (29-Nov-2011)
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/md126: clean, 423146/16654336 files, 48120270/66589824 blocks
sudo mount -t ext4 -r /dev/md126 /home/xubuntu/mp

Вуаля!


Відмінна інструкція. Одна примітка - 53EF00000100, здається, не є дійсним якорем для заголовка EXT4. Відповідно до ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block, два байти після 53EF можуть бути лише 0100, 0200 або 0400.
Мат

0

У мене було подібне питання. Я відформатував і перевстановив свій ОС / завантажувальний диск з чистою установкою Ubuntu 12.04, потім запустив команду mdadm --create ... і не зміг її встановити.

Він сказав, що не має дійсного суперблоку чи розділу.

Більше того, коли я зупинив наліт mdadm, я вже не міг монтувати звичайний пристрій.

Мені вдалося виправити суперблок за допомогою mke2fs та e2fsck:

root@blackbox:~# mke2fs -n /dev/sdc1
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
91578368 inodes, 366284000 blocks
18314200 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
11179 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
  4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
  102400000, 214990848

Потім побіг:

e2fsck -b 32768 -y /dev/sdc1

Це відновило суперблок, щоб я міг змонтувати та прочитати диск.

Щоб масив працював, не руйнуючи суперблок або розділи, які я використав: build:

mdadm --build /dev/md0 --level=mirror --assume-clean --raid-devices=2  /dev/sdc1 missing 

Після перевірки даних я додам інший диск:

mdadm --add /dev/md0 /sdd1

0

Я лише оновлюю інформацію, надану раніше. У мене був 3-диск-масив raid5, який працював нормально, коли моя материнська плата померла. Масив містив / dev / md2 як / home розділ 1.2TB та / dev / md3 як / var розділ 300GB.

У мене було два резервні копії «важливих» речей і купа випадкових речей, які я схопив з різних частин Інтернету, які я дійсно повинен був пройти і вибірково скинути. Більшість резервних копій були розбиті на файли .tar.gz розміром 25 Гб або менше, також була створена резервна копія окремої копії / тощо.

Решта файлової системи зберігалася на двох невеликих дисках raid0 об'ємом 38 Гб.

Моя нова машина була схожа на стару апаратуру, і я запустив і працює машину, просто включивши всі п’ять дисків і вибравши старе загальне ядро. Тож у мене було п'ять дисків з чистими файловими системами, хоча я не міг бути впевненим, що диски в правильному порядку, і мені потрібно було встановити нову версію Debian Jessie, щоб бути впевненим, що я можу оновити машину, коли потрібно, і розібратися з іншими проблеми.

З новою загальною системою, встановленою на двох дисках Raid0, я почав складати масиви назад. Я хотів бути впевненим, що я мав диски в потрібному порядку. Що я повинен був зробити:

mdadm --assemble /dev/md3 -o --no-degraded --uuid=82164ae7:9af3c5f1:f75f70a5:ba2a159a

Але я цього не зробив. Здається, що mdadm досить розумний і, маючи уяву, може зрозуміти, які диски куди йти. Навіть якщо bios позначає / dev / sdc як / sda, mdadm складе його правильно (хоча YMMV).

Натомість я видав: mdadm --create /dev/md2 without the --assume-cleanта дозволив завершити повторну синхронізацію на / dev / sde1. Наступною помилкою, яку я допустив, було працювати над / dev / sdc1 замість останнього диска в / dev / md2, / sde1. Будь-коли mdadm вважає, що є проблема, саме останній диск виганяється або повторно синхронізується.

Після цього mdadm не зміг знайти жодного суперблоку, а e2fsck -n також не міг.

Після того як я знайшов цю сторінку, я пройшов процедуру спроби знайти послідовність для накопичувачів (зроблено), перевірив достовірні дані (перевірено 6 Мб файлу 9 МБ), дістав диск у потрібній послідовності, cde, схопив uuid з / md2 та / md3 зі старого /etc/mdadm.conf та спробувала збірка.

Ну, /dev/md3почали і mdadm --misc -D /dev/md3показали три здорові розділи та диски в потрібному порядку. /dev/md2також добре виглядав, поки я не спробував змонтувати файлову систему.

# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.

Файлова система відмовилася монтуватися, і e2fsck не зміг знайти жодних суперблоків. Крім того, під час перевірки суперблоків, як описано вище, загальний кількість блоків, знайдений як a880 0076 або a880 0076 або 5500 1176, не відповідав розміру ємності диска 1199,79, повідомив мій mdadm. Також жодне місце розташування "суперблоків" не узгоджується з даними в публікаціях вище.

Я створив резервну копію всього / var і підготувався до протирання дисків. Щоб побачити, чи можна стерти тільки / md2, (мені нічого більше нічого втрачати в цей момент) я виявив наступне:

root@ced2:/home/richard# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.
# mkfs.ext3 /dev/md2
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 292902912 4k blocks and 73228288 inodes
Filesystem UUID: a54e252f-78db-4ebb-b7ca-7dcd2edf57a4
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 


# hexdump -n84 -s0x00000400 -v /dev/md2
0000400 6000 045d 5800 1175 7799 00df 6ff0 112e
0000410 5ff5 045d 0000 0000 0002 0000 0002 0000
0000420 8000 0000 8000 0000 2000 0000 10d3 56b2
0000430 10d3 56b2 0002 ffff ef53 0001 0001 0000
0000440 0c42 56b2 0000 0000 0000 0000 0001 0000
0000450 0000 0000                              
0000454

#  ./bgrep 00605D0400587511 /dev/md2
/dev/md2: 00000400
/dev/md2: 08000000
/dev/md2: 18000000
/dev/md2: 28000000
/dev/md2: 38000000
/dev/md2: 48000000
/dev/md2: c8000000
/dev/md2: d8000000
/dev/md2: 188000000
/dev/md2: 288000000
/dev/md2: 3e8000000
/dev/md2: 798000000
/dev/md2: ab8000000
etc

Все здавалося нормальним, за винятком зміни на uuid. Тому після ще кількох перевірок я написав 600 ГБ резервних даних на / dev / md2. Потім відключившись і спробувавши знову встановити накопичувач:

# mdadm --assemble /dev/md2 uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7
mdadm: cannot open device uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7: No such file or directory
mdadm: uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 has no superblock - assembly aborted

Ти жартуєш мене *********? що з моїм 600 ГБ у файлі?

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 not identified in config file.

Ах - легко фіксується. коментовано один рядок у /etc/mdadm.conf

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 has been started with 3 drives.

# e2fsck -n /dev/md2
e2fsck 1.42.12 (29-Aug-2014)
/dev/md2: clean, 731552/73228288 files, 182979586/292902912 blocks

Іпі!

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.