Pulihkan data RAID 5 setelah membuat larik baru alih-alih menggunakan kembali

35

Orang-orang tolong bantu - Saya seorang pemula dengan sakit kepala besar di tangan (situasi badai sempurna).

Saya memiliki 3 1tb hdd di ubuntu 11.04 saya yang dikonfigurasi sebagai serangan perangkat lunak 5. Data telah disalin setiap minggu ke hard drive komputer yang terpisah secara terpisah hingga sepenuhnya gagal dan dibuang. Beberapa hari yang lalu kami mengalami pemadaman listrik dan setelah me-reboot kotak saya tidak akan me-mount serangan itu. Dalam kebijaksanaan saya yang tak terbatas, saya masuk

mdadm --create -f...

perintah alih-alih

mdadm --assemble

dan tidak memperhatikan parodi yang telah saya lakukan sampai sesudahnya. Itu mulai array terdegradasi dan dilanjutkan dengan membangun dan menyinkronkannya yang memakan waktu ~ 10 jam. Setelah saya kembali saya melihat bahwa array berhasil dan berjalan tetapi serangan itu tidak

Maksud saya masing-masing drive dipartisi (tipe partisi f8) tetapi md0perangkat tidak. Menyadari dengan ngeri apa yang telah saya lakukan, saya mencoba menemukan beberapa solusi. Saya hanya berdoa agar --createtidak menimpa seluruh isi hard disk.

Bisakah seseorang tolong bantu saya dengan ini - data yang ada di drive sangat penting dan unik ~ 10 tahun foto, dokumen, dll.

Apakah mungkin bahwa dengan menentukan hard drive yang berpartisipasi dalam urutan yang salah dapat membuat mdadmmenimpanya? ketika saya melakukannya

mdadm --examine --scan 

Saya mendapatkan sesuatu seperti ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0

Cukup menarik nama dulu 'raid' dan bukan host hame dengan: 0 ditambahkan.

Berikut adalah entri konfigurasi 'disanitasi':

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

Per saran saya memang membersihkan superblok dan menciptakan kembali array dengan --assume-cleanopsi tetapi tidak berhasil sama sekali.

Apakah ada alat yang akan membantu saya untuk menghidupkan kembali setidaknya beberapa data? Dapatkah seseorang memberi tahu saya apa dan bagaimana mdadm --create melakukan saat sinkronisasi untuk menghancurkan data sehingga saya dapat menulis alat untuk membatalkan apa pun yang dilakukan?

Setelah menciptakan kembali raid saya menjalankan fsck.ext4 / dev / md0 dan ini adalah hasilnya

root @ tanserv: / etc / mdadm # fsck.ext4 / dev / md0 e2fsck 1.41.14 (22-Des-2010) fsck.ext4: Superblock tidak valid, mencoba blok cadangan ... fsck.ext4: Angka ajaib buruk di super- blok ketika mencoba membuka / dev / md0

Superblock tidak dapat dibaca atau tidak menggambarkan sistem file ext2 yang benar. Jika perangkat ini valid dan benar-benar berisi sistem file ext2 (dan bukan swap atau ufs atau yang lainnya), maka superblock rusak, dan Anda dapat mencoba menjalankan e2fsck dengan superblock alternatif: e2fsck -b 8193


Atas saran Shanes saya mencoba

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

dan jalankan fsck.ext4 dengan setiap blok cadangan tetapi semuanya mengembalikan yang berikut:

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>

Ada saran?

Salam!

Brigadieren
sumber
1
Mungkin suatu hari orang mungkin menyadari mengapa RAID5 adalah ide yang buruk. Sampai saat itu, 1) orang akan kehilangan data. 2) Kami akan mendapatkan pertanyaan seperti ini.
Tom O'Connor
11
@ Tom O'Connor ... karena jelas, RAID5 yang harus disalahkan atas kesalahan pengguna. : rolleyes:
Reality Extractor
2
Semoga jawaban Shane dapat menyimpan data, tetapi, sekali lagi, buktikan mengapa RAID saja tidak terbaik untuk penyimpanan. Perlu cadangan juga. (tetapi +1 untuk pertanyaan dan jawaban epik yang dihasilkan)
tombull89
4
Saya tahu itu sering diulang, tetapi serangan itu bukan solusi cadangan . Pesan itu benar-benar membutuhkan perjalanan pulang.
Sirex

Jawaban:

89

Ok - ada sesuatu yang mengganggu saya tentang masalah Anda, jadi saya meluncurkan VM untuk menyelami perilaku yang seharusnya. Saya akan sampai ke apa yang mengganggu saya dalam satu menit; pertama izinkan saya mengatakan ini:

Cadangkan drive ini sebelum mencoba sesuatu !!

Anda mungkin telah melakukan kerusakan di luar apa yang dilakukan sinkronisasi ulang; dapatkah Anda mengklarifikasi apa yang Anda maksudkan ketika mengatakan:

Per saran yang saya lakukan membersihkan superblok dan menciptakan kembali array dengan opsi --assume-clean tetapi tidak berhasil sama sekali.

Jika Anda berlari mdadm --misc --zero-superblock, maka Anda harus baik-baik saja.

Ngomong-ngomong, ambil beberapa disk baru dan ambil gambar saat ini yang tepat dari mereka sebelum melakukan apa pun yang mungkin melakukan lebih banyak menulis ke disk ini.

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

Yang sedang berkata .. sepertinya data yang disimpan pada hal-hal ini ternyata sangat tangguh terhadap sinkronisasi yang tidak sopan. Baca terus, ada harapan, dan ini mungkin hari saya mencapai batas panjang jawaban.


Skenario Kasus Terbaik

Saya mengumpulkan VM untuk menciptakan kembali skenario Anda. Drive hanya 100 MB jadi saya tidak akan menunggu selamanya pada setiap sinkronisasi, tetapi ini seharusnya representasi yang cukup akurat.

Membangun array secara umum dan standar mungkin - potongan 512k, tata letak simetris kiri, disk dalam urutan huruf .. tidak ada yang istimewa.

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>

Sejauh ini baik; mari kita membuat sistem file, dan menaruh beberapa data di dalamnya.

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

Baik. Kami memiliki sistem file dan beberapa data ("data" datafile, dan data acak senilai 5MB dengan hash SHA1 randomdata) di dalamnya; mari kita lihat apa yang terjadi ketika kita membuat ulang.

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>

Sinkronisasi ulang selesai dengan sangat cepat dengan disk kecil ini, tetapi hal itu terjadi. Jadi, inilah yang mengganggu saya dari sebelumnya; fdisk -loutput Anda . Tidak memiliki tabel partisi pada mdperangkat sama sekali bukan masalah, itu diharapkan. Sistem file Anda berada langsung di perangkat blok palsu tanpa tabel partisi.

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

Ya, tidak ada tabel partisi. Tapi...

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

Sistem file yang benar-benar valid, setelah dilakukan sinkronisasi ulang. Jadi itu bagus; mari kita periksa file data kami:

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

Solid - tidak ada korupsi data sama sekali! Tapi ini dengan pengaturan yang sama persis, jadi tidak ada yang dipetakan secara berbeda antara kedua kelompok RAID. Mari kita jatuhkan benda ini sebelum kita mencoba memecahkannya.

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

Mengambil Langkah Kembali

Sebelum kita mencoba untuk memecahkan ini, mari kita bicara tentang mengapa ini sulit untuk dipatahkan. RAID 5 bekerja dengan menggunakan blok paritas yang melindungi area dengan ukuran yang sama dengan blok pada setiap disk lain dalam array. Paritasnya tidak hanya pada satu disk tertentu, tetapi diputar di sekitar disk secara merata untuk menyebarkan beban baca yang lebih baik ke seluruh disk dalam operasi normal.

Operasi XOR untuk menghitung paritas terlihat seperti ini:

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

Jadi, paritas tersebar di antara disk.

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

Sinkronisasi ulang biasanya dilakukan saat mengganti disk yang mati atau hilang; itu juga dilakukan mdadm createuntuk memastikan bahwa data pada disk sejajar dengan seperti apa bentuk geometri RAID. Dalam hal ini, disk terakhir dalam spesifikasi array adalah disk yang 'disinkronkan ke' - semua data yang ada pada disk lain digunakan untuk sinkronisasi.

Jadi, semua data pada disk 'baru' dihapus dan dibangun kembali; baik membangun blok data baru dari blok paritas untuk apa yang seharusnya ada, atau membangun blok paritas baru.

Apa yang keren adalah bahwa prosedur untuk kedua hal itu sama persis: operasi XOR di seluruh data dari seluruh disk. Proses sinkronisasi ulang dalam kasus ini mungkin memiliki tata letak di mana blok tertentu harus menjadi blok paritas, dan berpikir itu sedang membangun blok paritas baru, padahal sebenarnya itu menciptakan kembali blok data lama. Jadi, bahkan jika itu dianggap membangun ini:

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

... mungkin hanya membangun kembali DISK5dari tata letak di atas.

Jadi, dimungkinkan data tetap konsisten meskipun array salah.


Melempar Monyet dalam Karya

(bukan kunci pas; seluruh monyet)

Tes 1:

Mari kita membuat array dengan urutan yang salah! sdclalu sdd, lalu 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>

Ok, itu semua baik dan bagus. Apakah kita memiliki sistem file?

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>

Nggak! Mengapa demikian? Karena sementara semua data ada di sana, itu dalam urutan yang salah; apa yang dulunya 512KB dari A, kemudian 512KB dari B, A, B, dan sebagainya, sekarang telah dikocok ke B, A, B, A. Disk sekarang terlihat seperti bualan ke pemeriksa sistem file, itu tidak akan berjalan. Output dari mdadm --misc -D /dev/md1memberi kita lebih banyak detail; Ini terlihat seperti ini:

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

Kapan seharusnya terlihat seperti ini:

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

Jadi, itu semua baik dan bagus. Kami menimpa sejumlah besar blok data dengan blok paritas baru kali ini. Buat ulang, dengan urutan yang benar sekarang:

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

Rapi, masih ada filesystem di sana! Masih punya data?

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

Keberhasilan!

Tes 2

Ok, mari kita ubah ukuran bongkahan dan melihat apakah itu membuat kita patah.

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>

Ya, ya, disemprot ketika dipasang seperti ini. Tapi, bisakah kita pulih?

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

Berhasil lagi!

Tes 3

Ini adalah salah satu yang saya pikir akan membunuh data dengan pasti - mari kita lakukan algoritma tata letak yang berbeda!

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).

Menakutkan dan buruk - menurutnya ia menemukan sesuatu dan ingin melakukan perbaikan! Ctrl+ C!

Clear<y>? cancelled!

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

Ok, krisis terhindar. Mari kita lihat apakah data masih utuh setelah melakukan sinkronisasi ulang dengan tata letak yang salah:

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

Keberhasilan!

Tes 4

Mari kita buktikan juga bahwa zerolock superblock tidak berbahaya dengan cepat:

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

Ya, bukan masalah besar.

Tes 5

Mari kita lemparkan semua yang kita miliki. Semua 4 tes sebelumnya, digabungkan.

  • Pesanan perangkat salah
  • Ukuran potongan yang salah
  • Algoritma tata letak salah
  • Zeroed superblocks (kami akan melakukan ini di antara kedua kreasi)

Maju!

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

Putusannya?

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

Wow.

Jadi, sepertinya tidak ada tindakan yang merusak data dengan cara apa pun. Saya cukup terkejut dengan hasil ini, terus terang; Saya berharap kemungkinan moderat hilangnya data pada perubahan ukuran chunk, dan beberapa kerugian pasti pada perubahan tata letak. Saya belajar sesuatu hari ini.


Jadi .. Bagaimana cara saya mendapatkan data saya ??

Informasi sebanyak yang Anda miliki tentang sistem lama akan sangat membantu Anda. Jika Anda mengetahui jenis sistem file, jika Anda memiliki salinan lama Anda /proc/mdstatdengan informasi tentang urutan drive, algoritma, ukuran chunk, dan versi metadata. Apakah Anda memiliki peringatan email mdadm yang diatur? Jika demikian, temukan yang lama; jika tidak, periksa /var/spool/mail/root. Periksa Anda ~/.bash_historyuntuk melihat apakah bangunan asli Anda ada di sana.

Jadi, daftar hal-hal yang harus Anda lakukan:

  1. Cadangkan disk ddsebelum melakukan apa pun !!
  2. Cobalah fsckmd aktif saat ini - Anda mungkin baru saja membangun dalam urutan yang sama seperti sebelumnya. Jika Anda mengetahui tipe sistem file, itu sangat membantu; gunakan fsckalat khusus itu . Jika ada alat yang menawarkan untuk memperbaiki apa pun, jangan biarkan mereka kecuali Anda yakin mereka telah menemukan sistem file yang benar! Jika fsckpenawaran untuk memperbaiki sesuatu untuk Anda, jangan ragu untuk meninggalkan komentar untuk menanyakan apakah itu benar-benar membantu atau hanya akan memuntahkan data.
  3. Coba buat array dengan parameter berbeda. Jika Anda memiliki yang lama /proc/mdstat, maka Anda bisa meniru apa yang ditunjukkannya; jika tidak, maka Anda agak dalam kegelapan - mencoba semua perintah drive yang berbeda adalah wajar, tetapi memeriksa setiap ukuran chunk yang mungkin dengan setiap pesanan yang mungkin adalah sia-sia. Untuk masing-masing, fsckitu untuk melihat apakah Anda mendapatkan sesuatu yang menjanjikan.

Jadi begitulah. Maaf untuk novel ini, jangan ragu untuk meninggalkan komentar jika Anda memiliki pertanyaan, dan semoga sukses!

catatan kaki: di bawah 22 ribu karakter; 8k + malu batas panjangnya

Shane Madden
sumber
8
Itu adalah satu jawaban yang luar biasa.
Antoine Benkemoun
3
Aku bahkan tidak tahu harus berkata apa ... BRAVO !!! Kudos to Shane Madden. Saya akan membuat cadangan disk dan memulai dengan saran Anda. Terima kasih, tidak, terima kasih banyak !!!
Brigadieren
3
Saya hanya ... wow. Jawaban yang brilian Saya pikir satu-satunya jawaban untuk menembus batas 30.000 karakter adalah esai Evan Andersons "How Subnetting Work".
tombull89
3
Jawaban terbaik untuk SF sejauh yang saya ketahui.
Chopper3
14
Anda, Tuan, menangkan internet.
Mark Henderson
5

Jika Anda beruntung, Anda mungkin akan berhasil mengembalikan file Anda dengan perangkat lunak pemulihan yang dapat membaca array RAID-5 yang rusak. Zero Assumption Recovery adalah salah satu yang pernah saya sukseskan sebelumnya.

Namun, saya tidak yakin apakah proses membuat array baru telah menghancurkan semua data, jadi ini mungkin upaya peluang terakhir.

Mark Henderson
sumber
Terima kasih banyak, Mark. Saya akan mencobanya. Apakah Anda tahu jika itu memodifikasi drive? Jika demikian saya akan membuat salinan disk dan juga mencoba dengan alat lain.
Brigadieren
@Brigadieren - tidak, maaf, saya tidak cukup akrab dengan seluk-beluk cara kerja RAID5.
Mark Henderson
@Brigadieren Menurut dokumentasi mdadm , proses membuat tidak akan menghancurkan data, hanya menyinkronkan ulang - tetapi jika itu memilih geometri yang tidak cocok dengan aslinya, maka mungkin telah menghancurkan data dengan penulisan paritas baru. Jika saya punya waktu luang nanti saya mungkin melihat tentang menciptakan kembali situasi Anda di VM, untuk melihat apakah saya dapat menambahkan wawasan. Saya akan merekomendasikan mengambil salinan lengkap drive sebelum mencoba langkah-langkah pemulihan yang menulis ke disk sama sekali - Anda mungkin ingin melihat ke dalam mendapatkan drive tambahan untuk membuat salinan.
Shane Madden
Saya hanya tidak yakin apa yang menyebabkan sinkronisasi - fakta bahwa array terdegradasi di tempat pertama (karena pemadaman listrik) atau sesuatu yang lain? Saya ingin tahu apakah mdadm --create membuat perbedaan apakah saya menentukan urutan drive berbeda dari yang semula diberikan?
Brigadieren
@Brigadieren Sync selalu terjadi di buat.
Shane Madden
5

Saya memiliki masalah yang sama:
setelah kegagalan array perangkat lunak RAID5 saya menembak mdadm --createtanpa memberikannya --assume-clean, dan tidak bisa me-mount array lagi. Setelah dua minggu penggalian, saya akhirnya mengembalikan semua data. Saya harap prosedur di bawah ini akan menghemat waktu seseorang.

Cerpen Panjang

Masalahnya disebabkan oleh fakta yang mdadm --createmembuat array baru yang berbeda dari yang asli dalam dua aspek:

  • urutan partisi yang berbeda
  • offset data RAID yang berbeda

Seperti yang telah ditunjukkan dalam jawaban brilian oleh Shane Madden , mdadm --createdalam kebanyakan kasus tidak menghancurkan data! Setelah menemukan urutan partisi dan data offset saya bisa mengembalikan array dan mengekstrak semua data darinya.

Prasyarat

Saya tidak punya cadangan RAID superblocks, jadi yang saya tahu hanyalah array RAID5 pada 8 partisi yang dibuat saat instalasi Xubuntu 12.04.0. Itu sistem file ext4. Sepotong pengetahuan penting lainnya adalah salinan file yang juga disimpan pada array RAID.

Alat

CD live Xubuntu 12.04.1 digunakan untuk melakukan semua pekerjaan. Tergantung pada situasi Anda, Anda mungkin memerlukan beberapa alat berikut:

versi mdadm yang memungkinkan untuk menentukan offset data

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

bgrep - mencari data biner

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

hexdump, e2fsck, mount dan kalkulator heksadesimal - alat standar dari repo

Mulai dengan Cadangan Penuh

Penamaan file perangkat, misalnya /dev/sda2 /dev/sdb2dll, tidak persisten, jadi lebih baik untuk menuliskan nomor seri drive Anda yang diberikan oleh

sudo hdparm -I /dev/sda

Kemudian pasang HDD eksternal dan cadangkan setiap partisi array RAID Anda seperti ini:

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

Tentukan Tata Letak RAID5 Asli

Berbagai tata letak dijelaskan di sini: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Untuk menemukan bagaimana setrip data disusun pada larik asli, Anda memerlukan salinan file yang tampak acak yang Anda tahu adalah disimpan pada array. Ukuran chunk default yang saat ini digunakan mdadmadalah 512KB. Untuk larik partisi N, Anda memerlukan file ukuran setidaknya (N + 1) * 512KB. Jpeg atau video bagus karena menyediakan substring data biner yang relatif unik. Misalkan file kita dipanggil picture.jpg. Kami membaca 32 byte data pada posisi N +1 mulai dari 100rb dan bertambah dengan 512rb:

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
...

Kami kemudian mencari kemunculan semua bytestrings ini pada semua partisi mentah kami, jadi secara total (N + 1) * N perintah, seperti ini:

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
...

Perintah-perintah ini dapat dijalankan secara paralel untuk disk yang berbeda. Pemindaian partisi 38GB membutuhkan waktu sekitar 12 menit. Dalam kasus saya, setiap string 32-byte hanya ditemukan sekali di antara delapan drive. Dengan membandingkan offset yang dikembalikan oleh bgrep, Anda memperoleh gambar seperti ini:

| 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 |

Kami melihat tata letak simetris kiri normal , yang merupakan default untuk mdadm. Lebih penting lagi, sekarang kita tahu urutan partisi. Namun, kita tidak tahu partisi mana yang merupakan yang pertama dalam array, karena mereka dapat digeser secara siklis.

Perhatikan juga jarak antara offset yang ditemukan. Dalam kasus saya itu adalah 512KB. Ukuran bongkahan sebenarnya bisa lebih kecil dari jarak ini, dalam hal ini tata letak yang sebenarnya akan berbeda.

Temukan Ukuran Potongan Asli

Kami menggunakan file yang sama picture.jpguntuk membaca 32 byte data pada interval yang berbeda satu sama lain. Kita tahu dari atas bahwa data pada offset 100k terletak pada /dev/sdh2, pada offset 612k adalah pada /dev/sdb2, dan pada 1124k adalah pada /dev/sdd2. Ini menunjukkan bahwa ukuran chunk tidak lebih besar dari 512KB. Kami memverifikasi bahwa itu tidak lebih kecil dari 512KB. Untuk ini, kita membuang bytestring pada offset 356k dan lihat di partisi mana itu berada:

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

Ini pada partisi yang sama dengan offset 612k, yang menunjukkan bahwa ukuran chunk tidak 256KB. Kami menghilangkan ukuran potongan yang lebih kecil dengan cara yang sama. Saya akhirnya dengan potongan 512KB menjadi satu-satunya kemungkinan.

Temukan Partisi Pertama di Layout

Sekarang kita tahu urutan partisi, tetapi kita tidak tahu partisi mana yang harus menjadi yang pertama, dan offset data RAID mana yang digunakan. Untuk menemukan dua hal yang tidak diketahui ini, kami akan membuat array RAID5 dengan tata letak chunk yang benar dan offset data kecil, dan mencari awal sistem file kami dalam array baru ini.

Untuk memulainya, kami membuat array dengan urutan partisi yang benar, yang kami temukan sebelumnya:

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

Kami memverifikasi bahwa pesanan dipatuhi dengan menerbitkan

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

Sekarang kita menentukan offset dari N + 1 yang diketahui bytestrings dalam array RAID. Saya menjalankan skrip untuk satu malam (Live CD tidak meminta kata sandi pada 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

Keluaran dengan komentar:

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

Berdasarkan data ini kita melihat bahwa string ke-3 tidak ditemukan. Ini berarti bahwa potongan pada /dev/sdd2digunakan untuk paritas. Berikut adalah ilustrasi posisi paritas dalam array baru:

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

Tujuan kami adalah untuk menyimpulkan dari partisi mana untuk memulai array, untuk menggeser potongan paritas ke tempat yang tepat. Karena paritas harus digeser dua potongan ke kiri, urutan partisi harus digeser dua langkah ke kanan. Dengan demikian tata letak yang benar untuk data offset ini adalah 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 

Pada titik ini array RAID kami berisi data dalam bentuk yang tepat. Anda mungkin beruntung sehingga offset data RAID sama dengan array aslinya, dan kemungkinan besar Anda akan dapat me-mount partisi. Sayangnya ini bukan kasus saya.

Verifikasi Konsistensi Data

Kami memverifikasi bahwa data konsisten di atas potongan dengan mengekstraksi salinan dari picture.jpgarray. Untuk ini kami menemukan offset untuk string 32-byte pada 100k:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

Kami kemudian mengurangi 100 * 1024 dari hasil dan menggunakan nilai desimal yang diperoleh dalam skip=parameter untuk dd. The count=adalah ukuran picture.jpgdalam bytes:

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

Periksa extract.jpgapakah sama dengan picture.jpg.

Temukan Offset Data RAID

Sidenote: offset data default untuk mdadmversi 3.2.3 adalah 2048 sektor. Tetapi nilai ini telah berubah seiring waktu. Jika array asli menggunakan offset data yang lebih kecil dari arus Anda mdadm, maka mdadm --createtanpa --assume-cleandapat menimpa awal sistem file.

Di bagian sebelumnya kami membuat array RAID. Verifikasi data RAID mana yang diimbangi dengan mengeluarkan untuk beberapa partisi individual:

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

2048 sektor 512-byte adalah 1MB. Karena ukuran chunk adalah 512KB, offset data saat ini adalah dua chunk.

Jika pada titik ini Anda memiliki offset dua potong, itu mungkin cukup kecil, dan Anda dapat melewati paragraf ini.
Kami membuat array RAID5 dengan offset data sebesar satu 512KB-chunk. Memulai satu bongkahan sebelumnya menggeser paritas satu langkah ke kiri, jadi kami mengimbanginya dengan menggeser urutan partisi satu langkah ke kiri. Oleh karena itu untuk offset data 512KB, tata letak yang benar adalah hbdcefga. Kami menggunakan versi mdadmyang mendukung penggantian data (lihat bagian Alat). Dibutuhkan offset dalam kilobyte:

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

Sekarang kami mencari superblock ext4 yang valid. Struktur superblock dapat ditemukan di sini: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
Kami memindai awal array untuk kemunculan angka ajaib s_magicdiikuti oleh s_statedan s_errors. Bytestrings yang harus dicari adalah:

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

Contoh perintah:

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

Angka ajaib mulai 0x38 byte ke dalam superblok, jadi kami mengurangi 0x38 untuk menghitung offset dan memeriksa seluruh superblock:

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                              

Ini tampaknya merupakan superblok yang valid. s_log_block_sizebidang pada 0x18 adalah 0002, artinya ukuran blok adalah 2 ^ (10 + 2) = 4096 byte. s_blocks_count_lopada 0x4 adalah blok 03f81480 yang 254GB. Kelihatan bagus.

Kami sekarang memindai kemunculan byte pertama superblok untuk menemukan salinannya. Perhatikan flipping byte dibandingkan dengan output hexdump:

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

Ini sejajar dengan posisi yang diharapkan dari cadangan superblok:

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

Oleh karena itu sistem file dimulai pada 0xdc80000 offset, yaitu 225792KB dari mulai partisi. Karena kami memiliki 8 partisi yang satu untuk paritas, kami membagi offset dengan 7. Ini memberikan 33030144 byte offset pada setiap partisi, yang persis 63 potongan RAID. Dan karena offset data RAID saat ini adalah satu chunk, kami menyimpulkan bahwa offset data asli adalah 64 chunk, atau 32768KB. Menggeser hbdcefga63 kali ke kanan memberikan tata letakbdcefgah .

Kami akhirnya membangun array RAID yang benar:

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

Voa!

Anton Stolbunov
sumber
Panduan yang sangat baik. Satu catatan - 53EF00000100 tampaknya tidak menjadi jangkar yang valid untuk header EXT4. Menurut ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Blok dua byte setelah 53EF bisa jadi hanya 0100, 0200 atau 0400.
matt
0

Saya memiliki masalah serupa. Saya memformat dan menginstal ulang OS / boot drive saya dengan instalasi Ubuntu 12.04 yang bersih, kemudian menjalankan perintah mdadm --create ... dan tidak bisa memasangnya.

Dikatakan tidak memiliki superblock atau partisi yang valid.

Selain itu, ketika saya menghentikan serangan mdadm, saya tidak bisa lagi memasang perangkat biasa.

Saya dapat memperbaiki superblock dengan mke2fs dan 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

Kemudian berlari:

e2fsck -b 32768 -y /dev/sdc1

Itu memulihkan superblock sehingga saya bisa memasang dan membaca drive.

Untuk membuat array berfungsi tanpa merusak superblock atau partisi yang saya gunakan build:

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

Setelah memverifikasi data, saya akan menambahkan drive lain:

mdadm --add /dev/md0 /sdd1
SideShow Bob
sumber
0

Saya hanya memperbarui beberapa informasi yang diberikan sebelumnya. Saya memiliki array raid5 3-disk yang berfungsi dengan baik ketika motherboard saya mati. Array memegang / dev / md2 sebagai partisi / home 1.2TB dan / dev / md3 sebagai partisi / var 300GB.

Saya memiliki dua cadangan hal-hal "penting" dan banyak hal acak yang saya ambil dari berbagai bagian internet yang harus saya lalui dan dibuang secara selektif. Sebagian besar cadangan dipecah menjadi file .tar.gz berukuran 25GB atau kurang, dan salinan / etc yang terpisah juga didukung.

Sisa dari filesystem diadakan pada dua disk raid0 kecil 38GB.

Mesin baru saya mirip dengan perangkat keras lama, dan saya menghidupkan dan menjalankan mesin hanya dengan memasukkan kelima disk dan memilih kernel generik lama. Jadi saya punya lima disk dengan filesystem yang bersih, meskipun saya tidak bisa memastikan bahwa disk berada dalam urutan yang benar, dan perlu menginstal versi baru Debian Jessie untuk memastikan bahwa saya dapat meningkatkan mesin ketika dibutuhkan, dan memilah-milah lainnya. masalah.

Dengan sistem generik baru yang diinstal pada dua disk Raid0, saya mulai menyatukan kembali array. Saya ingin memastikan bahwa saya memiliki disk dengan urutan yang benar. Apa yang seharusnya saya lakukan adalah mengeluarkan:

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

Tetapi saya tidak melakukannya. Tampaknya mdadm cukup pintar dan diberi uuid, dapat mengetahui drive mana yang pergi ke mana. Bahkan jika bios menunjuk / dev / sdc sebagai / sda, mdadm akan memasangnya dengan benar (YMMV though).

Alih-alih saya mengeluarkan mdadm --create /dev/md2 without the --assume-clean:, dan memperbolehkan sinkronisasi ulang di / dev / s11 selesai. Kesalahan berikutnya yang saya buat adalah bekerja di / dev / sdc1 alih-alih drive terakhir di / dev / md2, / sde1. Kapan pun mdadm berpikir ada masalah, itu adalah drive terakhir yang dikeluarkan atau disinkronkan kembali.

Setelah itu, mdadm tidak dapat menemukan superblock, dan e2fsck -n juga tidak bisa.

Setelah saya menemukan halaman ini, saya pergi melalui prosedur mencoba menemukan urutan untuk drive (selesai), memeriksa data yang valid (diverifikasi 6MB dari file 9MB), mendapatkan disk dalam urutan yang benar, cde, meraih uuid's dari / md2 dan / md3 dari /etc/mdadm.conf lama dan mencoba merakit.

Nah, /dev/md3mulai, dan mdadm --misc -D /dev/md3menunjukkan tiga partisi sehat, dan disk dalam urutan yang benar. /dev/md2juga terlihat bagus, sampai saya mencoba me-mount sistem file.

# 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.

Sistem file menolak untuk di-mount, dan e2fsck tidak dapat menemukan superblok. Lebih lanjut, ketika memeriksa superblok seperti dijelaskan di atas, jumlah blok total yang ditemukan sebagai a880 0076 atau a880 0076 atau 5500 1176 tidak cocok dengan ukuran kapasitas disk 1199,79 yang dilaporkan mdadm saya. Juga tidak ada lokasi "superblok" yang selaras dengan data di pos di atas.

Saya mencadangkan semua / var, dan bersiap untuk menghapus disk. Untuk melihat apakah mungkin untuk menghapus just / md2, (saya tidak memiliki hal lain yang hilang pada saat ini) saya menghilangkan hal-hal berikut:

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

Semua tampak baik-baik saja, kecuali untuk perubahan ke uuid. Jadi setelah beberapa cek lagi, saya menulis 600GB data yang dicadangkan ke / dev / md2. Kemudian, lepaskan dan coba pasang kembali drive:

# 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

Apakah kamu bercanda? bagaimana dengan 600GB saya pada file?

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

Ah - mudah diperbaiki. menghapus komentar satu baris di /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

Yippie!

rd.olivaw
sumber