Millet lütfen yardım edin - Eldeki büyük baş ağrıları olan bir yeniyim (mükemmel fırtına durumu).

Ben ubuntu 11.04 üzerinde yazılım baskını 5 olarak yapılandırılmış 3 1tb hdd'm var. Veriler, tamamen başarısız olana ve atılana kadar haftalık olarak bilgisayarın sabit diskinden ayrı bir başkasına kopyalandı. Birkaç gün önce elektrik kesintisi yaşadık ve kutumu yeniden başlattıktan sonra baskın yapmazdım. Sonsuz bilgeliğimde girdim

mdadm --create -f...

yerine komut

mdadm --assemble

ve sonrasına kadar yaptığım travestiyi fark etmedi. Diziyi indirgemeye başladı ve ~ 10 saat süren eşleştirmeye ve eşleştirmeye devam etti. Döndükten sonra dizinin başarılı bir şekilde çalıştığını ve çalıştığını gördüm ancak baskın olmadı

Yani bireysel sürücüler bölümlere ayrılıyor (bölüm tipi f8) ama md0cihaz değil. Yaptığım şeyi dehşet içinde gerçekleştirerek bazı çözümler bulmaya çalışıyorum. Dua ediyorum ki --createbu, sabit sürücünün tüm içeriğinin üzerine yazmamış.

Birisi LÜTFEN bana bu konuda yardımcı olabilir - sürücüdeki veriler çok önemli ve benzersiz ~ 10 yıllık fotoğraf, belge vb.

Katılan sabit diskleri yanlış sırayla belirterek mdadmbunların üzerine yazmak mümkün olabilir mi? ben yaparken

mdadm --examine --scan 

Gibi bir şey alıyorum ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0

İlginç bir şekilde yeterince isim kullanılmış ve baskın yapılmış: 0 eklenmiş.

İşte 'sterilize edilmiş' config girdileri:

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

Önerilere göre superblock'ları temizledim ve diziyi --assume-cleanseçenekle yeniden yarattım ama şanssız kaldım .

Verilerin en azından bazılarını canlandırmama yardımcı olacak herhangi bir araç var mı? Birisi bana verileri ne zaman ve ne yaptığını söyleyebilir mi?

Baskın yapıldıktan sonra fsck.ext4 / dev / md0 komutunu çalıştırdım ve çıktı

root @ tanserv: / etc / mdadm # fsck.ext4 / dev / md0 e2fsck 1.41.14 (22-Aralık-2010) fsck.ext4: Superblock geçersiz, yedekleme blokları deneniyor ... fsck.ext4: Süper sihirli kötü sayı / dev / md0 açmaya çalışırken engelle

Süper blok okunamadı veya doğru bir ext2 dosya sistemi tanımlamıyor. Aygıt geçerliyse ve gerçekten bir ext2 dosya sistemi içeriyorsa (ve takas yapmaz ya da başka bir şey yapmazsa), süper blok bozuktur ve e2fsck'i alternatif bir süper blokla çalıştırmayı deneyebilirsiniz: e2fsck -b 8193

Shanes'in önerisine göre ben denedim

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

ve her yedekleme bloğu ile fsck.ext4 komutunu çalıştırın, ancak tümü aşağıdakileri döndürür:

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>

Baska öneri?

Saygılarımızla!

Tamam - sorununuzla ilgili bir şey beni rahatsız ediyordu, bu yüzden beklenmesi gereken davranışa dalmak için bir VM başlattım. Bir dakikada beni neyin rahatsız ettiğini bulacağım; ilk önce şunu söylememe izin ver:

Bir şey denemeden önce bu sürücüleri yedekleyin !!

Resenkronin yaptıklarının ötesinde zaten hasar almış olabilirsiniz; derken ne demek istediğini açıklayabilir misin:

Önerilere göre süper blokları temizledim ve diziyi --assume-clean seçeneğiyle yeniden yaptım ama hiç şansım olmadı.

Eğer koştuysan mdadm --misc --zero-superblock, iyi olmalısın.

Her neyse, bazı yeni diskleri temizleyin ve bu disklere daha fazla yazı yazabilecek herhangi bir şey yapmadan önce bunların tam görüntülerini alın.

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

Olduğu söyleniyor ... bu şeyler üzerinde depolanan veriler şok edici bir şekilde yeniden yollara dayanıklıdır. Okumaya devam et, umut var ve bu, cevap uzunluğu sınırına ulaştığım gün olabilir.

En İyi Durum Senaryosu

Senaryonuzu yeniden oluşturmak için bir sanal makine fırlattım. Sürücüler sadece 100 MB boyutundadır, bu yüzden her resync'de sonsuza dek beklememeliydim, ama bu aksi halde oldukça doğru bir sunum olmalı.

Diziyi olabildiğince genel ve varsayılan olarak oluşturduk - 512k topakları, sola simetrik düzen, harf sırasına göre diskler .. özel bir şey yok.

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>

Çok uzak çok iyi; Hadi bir dosya sistemi yapalım ve üzerine biraz veri koyalım.

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

Tamam. Üzerinde bir dosya sistemimiz ve bazı verilerimiz ("data" datafile, ve bu SHA1 karma ile 5MB değerinde rastgele veriler randomdata) var; Yeniden yarattığımızda ne olacağını görelim.

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 bu küçük disklerle çok hızlı bir şekilde bitti, ancak gerçekleşti. İşte beni daha önce rahatsız eden şeydi; senin fdisk -lçıkışı. mdAygıtta hiçbir bölüm tablosu olması hiç sorun değil, bekleniyor. Dosya sisteminiz hiçbir bölüm tablosu olmayan doğrudan sahte blok aygıtında bulunur.

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

Evet, bölme masası yok. Fakat...

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

Bir resync sonra mükemmel geçerli bir dosya sistemi. Yani bu iyi; veri dosyalarımızı kontrol edelim:

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

Katı - veri bozulması yok! Ancak bu aynı ayarlarla yapıldığı için, iki RAID grubu arasında hiçbir şey farklı bir şekilde eşlenmedi. Kırmaya çalışmadan önce bu şeyi bırakalım.

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

Bir Adım Geri Gitmek

Bunu kırmaya çalışmadan önce, neden kırılmasının zor olduğunu konuşalım. RAID 5, dizideki diğer tüm disklerdeki bloklarla aynı boyutta bir alanı koruyan bir eşlik bloğu kullanarak çalışır. Eşlik yalnızca belirli bir diskte değil, normal işletimde okuma yükünü diskler boyunca daha iyi yaymak için disklerin etrafında eşit şekilde döndürülmüş.

Eşlik hesaplamak için XOR işlemi şöyle görünür:

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

Böylece, parite diskler arasında yayılır.

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

Ölü veya eksik bir diski değiştirirken tipik olarak bir resync yapılır; mdadm createdisklerdeki verilerin RAID'in geometrisinin neye benzemesi gerektiği ile aynı hizada olmasını sağlamak için yapılır . Bu durumda, dizi spec içindeki son disk 'ile senkronize edilmiş' dır - diğer disklerdeki mevcut verilerin tümü senkronizasyon için kullanılır.

Böylece, 'yeni' diskteki tüm veriler silinir ve yeniden oluşturulur; Ya orada olması gerekenler için eşlik bloklarından taze veri blokları oluşturmak ya da başka bir yere yeni eşlik blokları inşa etmek.

Asıl sorun, her ikisi için de aynı prosedürün aynı olmasıdır: disklerin geri kalanından gelen verilerde bir XOR işlemi. Bu durumda yeniden senkronizasyon işlemi, belirli bir bloğun bir eşlik bloğu olması gerektiği düzeninde olabilir ve aslında eski bir veri bloğu yeniden oluştururken yeni bir eşlik bloğu oluşturduğunu düşünür. Yani bunu inşa ettiğini düşünüyor olsa da :

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

... sadece DISK5yukarıdaki düzenden yeniden oluşturuluyor olabilir .

Dolayısıyla, dizinin yanlış yapılması durumunda bile verilerin tutarlı kalması mümkündür.

Eserlere Bir Maymun Atma

(İngiliz anahtarı değil; bütün maymun)

Test 1:

Diziyi yanlış sırada yapalım! sdc, sonra sdd, sonra 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>

Tamam, hepsi iyi ve iyi. Bir dosya sistemimiz var mı?

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>

Hayır! Neden? Çünkü veriler oradayken yanlış sırada; Bir zamanlar 512KB A, sonra 512KB B, A, B ve diğerleri, şimdi B, A, B, A'ya karıştırıldı. Çıktısı mdadm --misc -D /dev/md1bize daha fazla ayrıntı verir; Bu gibi görünüyor:

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

Böyle görünmesi gerektiğinde:

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

Yani, hepsi iyi ve iyi. Bu sefer yeni parite bloklarıyla dolu bir sürü veri bloğunun üzerine yazdık. Şimdi doğru sıraya göre yeniden oluşturun:

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

Güzel, orada hala bir dosya sistemi var! Hala veri var mı?

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

Başarı!

Test 2

Tamam, hadi yığın boyutunu değiştirelim ve bakalım bize biraz kırılmaya neden olacak mı.

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>

Evet, evet, böyle ayarlandığında hortumludur. Fakat iyileşebilir miyiz?

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

Yine başarı!

Test 3

Verileri kesin olarak öldüreceğini düşündüğüm şey bu - hadi farklı bir düzen algoritması yapalım!

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

Korkutucu ve kötü - bir şey bulduğunu düşünüyor ve biraz tamir etmek istiyor! Ctrl+ C!

Clear<y>? cancelled!

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

Tamam, kriz önlendi. Bakalım, yanlış düzende yeniden yapılandırma işleminden sonra verilerin hala sağlam olup olmadığını görelim:

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

Başarı!

Test 4

Ayrıca, süper blok sıfırlamanın gerçekten hızlı bir şekilde zararlı olmadığını kanıtlayalım:

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

Evet, önemli değil.

5. Test

Sadece sahip olduğumuz her şeyi fırlatalım. Önceki 4 testin hepsi bir araya getirildi.

• Yanlış cihaz sırası
• Yanlış yığın boyutu
• Yanlış yerleşim algoritması
• Sıfırlı süper bloklar (bunu iki yaratım arasında da yapacağız)

İleri!

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

Karar?

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

Vay.

Yani, bu eylemlerin hiçbiri herhangi bir şekilde veri bozmuş gibi görünüyor. Açıkçası bu sonuçtan oldukça şaşırdım; Öbek boyutu değişiminde orta düzeyde veri kaybı ve yerleşim değişikliği konusunda kesin bir kayıp bekleniyor. Bugün bir şey öğrendim.

Yani .. Verilerimi nasıl alabilirim?

Eski sistem hakkında sahip olduğunuz bilgi sizin için son derece yararlı olacaktır. Dosya sistemi türünü biliyorsanız, /proc/mdstatsürücü sırasına, algoritmaya, yığın boyutuna ve meta veri sürümüne ilişkin bilgileri içeren eski kopyalarınız varsa . Mdadm'ın e-posta uyarıları ayarlandı mı? Eğer öyleyse, eski bir tanesini bulun; değilse, kontrol edin /var/spool/mail/root. ~/.bash_historyOrijinal yapınızın orada olup olmadığını kontrol edin .

Yapmanız gereken şeylerin listesi:

1. Bir ddşey yapmadan önce diskleri yedekleyin !!
2. fsckGeçerli, aktif md'yi deneyin - daha önce olduğu gibi aynı sırada oluşturmuş olabilirsiniz. Dosya sistemi türünü biliyorsanız, bu yararlıdır; o özel fsckaleti kullanın. Araçlardan herhangi biri bir şeyi düzeltmeyi teklif ederse, gerçekten geçerli bir dosya sistemi bulduğundan emin değilseniz, izin vermeyin! Bir fsckşeyi sizin için çözme teklifleri varsa, gerçekten yardımcı olup olmadığını veya sadece verileri taramak üzere bir yorum bırakmaktan çekinmeyin.
3. Diziyi farklı parametrelerle oluşturmayı deneyin. Eğer /proc/mdstatyaşınız varsa, gösterdiklerini taklit edebilirsiniz; eğer değilse, o zaman karanlıktasınız - tüm farklı sürüş emirlerini denemek mantıklıdır, ancak mümkün olan her yığın boyutuna her olası siparişle kontrol etmek boşunadır. Her biri fsckiçin umut verici bir şey alıp almadığınızı görmek için.

Demek bu o. Roman için üzgünüm, herhangi bir sorunuz varsa ve iyi şanslar varsa yorum bırakmak için çekinmeyin!

dipnot: 22 bin karakterin altında; 8k + uzunluk sınırının utangaç

Eğer varsa şanslı dosyalarınızı kırık RAID-5 dizi okuyabilir kurtarma yazılımı ile geri alma ile bazı başarılar sahip olabilir. Sıfır Varsayım Kurtarma daha önce başarabildiğim bir tanesi.

Ancak, yeni bir dizi oluşturma işleminin tüm verileri gittiğinden ve yok ettiğinden emin değilim, bu nedenle bu son bir şans çabası olabilir.

Benzer bir problemim vardı:
bir yazılım RAID5 dizisinin başarısızlığından sonra mdadm --createvermeden ateş ettim --assume-cleanve diziyi artık monte edemedim. İki haftalık kazmadan sonra nihayet tüm verileri geri yükledim. Umarım aşağıdaki prosedür birisinin zamanını koruyacaktır.

Uzun lafın kısası

Sorun, mdadm --createorijinalinden farklı olan yeni bir dizi yapmış olmasından kaynaklandı :

• farklı bölüm sırası
• farklı RAID veri kayması

Parlak gösterilmiş oluyor gibi Shane Madden tarafından cevap , mdadm --createçoğu durumda veri yok etmez! Bölüm sırasını ve veri ofsetini bulduktan sonra diziyi geri yükleyebilir ve ondan tüm verileri çıkarabilirim.

Ön şartlar

RAID superblock'larının hiçbir yedeği yoktu, bu yüzden tek bildiğim, Xubuntu 12.04.0'ın kurulumu sırasında oluşturulan 8 bölümdeki bir RAID5 dizisi olduğuydu. Bir ext4 dosya sistemine sahipti. Bir başka önemli bilgi parçası da RAID dizisinde saklanan bir dosyanın kopyasıydı.

Araçlar

Tüm işleri yapmak için Xubuntu 12.04.1 canlı CD kullanıldı. Durumunuza bağlı olarak, aşağıdaki araçlardan bazılarına ihtiyacınız olabilir:

veri ofsetini belirtmeyi sağlayan mdadm sürümü

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

bgrep - ikili veri aranıyor

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

hexdump, e2fsck, mount ve onaltılık hesap makinesi - depolardan gelen standart araçlar

Tam Yedeklemeyle Başlayın

Cihaz dosyalarının isimlendirilmesi, örneğin, /dev/sda2 /dev/sdb2vb. Kalıcı değildir, bu nedenle sürücülerinizin seri numaralarını yazmak daha iyidir.

sudo hdparm -I /dev/sda

Ardından harici bir HDD bağlayın ve RAID dizinizin her bölümünü aşağıdaki gibi yedekleyin:

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

Orijinal RAID5 Mizanpajını Belirleme

Burada çeşitli düzenler açıklanmaktadır: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Orijinal dizide veri şeritlerinin nasıl düzenlendiğini bulmak için rastgele görünen bir dosyanın kopyasına ihtiyacınız olduğunu dizide saklanır. Şu anda tarafından kullanılan varsayılan öbek boyutu mdadm512KB. N bölümden oluşan bir dizi için, en azından (N + 1) * 512KB boyutunda bir dosyaya ihtiyacınız var. Bir jpeg veya video, nispeten benzersiz ikili veri alt dizileri sağladığı için iyidir. Dosyamızın çağrıldığını varsayalım picture.jpg. 100k'dan başlayıp 512k'yi artıran N + 1 konumlarında 32 bayt veri okuduk:

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

Daha sonra tüm ham bölümlerimizde bu bytest dizelerinin oluşumlarını araştırırız, yani toplamda (N + 1) * N komutları, şöyle:

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

Bu komutlar farklı diskler için paralel olarak çalıştırılabilir. 38GB'lık bir bölümün taranması 12 dakika kadar sürdü. Benim durumumda, her 32 baytlık dize, sekiz sürücü arasında yalnızca bir kez bulundu. Bgrep tarafından döndürülen ofsetleri karşılaştırarak şöyle bir resim elde edersiniz:

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

Normal bir sol simetrik düzen görüyoruz , bunun için varsayılandır mdadm. Daha önemlisi, şimdi bölümlerin sırasını biliyoruz. Bununla birlikte, dizideki ilk bölümün hangi döngüsel olarak kaydırılabileceğini bilmiyoruz.

Ayrıca bulunan ofsetler arasındaki mesafeyi de not edin. Benim durumumda 512KB idi. Öbek boyutu aslında bu mesafeden daha küçük olabilir; bu durumda asıl düzen farklı olacaktır.

Orijinal Parça Boyutu Bul

Aynı dosyayı picture.jpg32 byte veriyi birbirinden farklı aralıklarla okumak için kullanıyoruz . Yukarıdan biliyoruz ki, /dev/sdh2ofset 100k'daki veriler yalan söylüyor , ofset 612k'de /dev/sdb2ve 1124k'de /dev/sdd2. Bu, yığın boyutunun 512KB'den büyük olmadığını gösterir. 512KB'den küçük olmadığını onaylıyoruz. Bunun için bytestring'i 356k ofsetine atıyoruz ve hangi bölüme oturduğuna bakıyoruz:

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

Öbek boyutunun 256KB olmadığını belirten 612k ofsetiyle aynı bölümdedir. Benzer şekilde daha küçük yığın boyutlarını da ortadan kaldırırız. Tek olasılık olan 512KB parça ile bitirdim.

Mizanpajdaki İlk Bölümü Bulun

Şimdi bölümlerin sırasını biliyoruz, ancak hangi bölümün ilk olması gerektiğini ve hangi RAID veri ofsetinin kullanıldığını bilmiyoruz. Bu bilinmeyenleri bulmak için, doğru yığın düzenine ve küçük bir veri kaymasına sahip bir RAID5 dizisi oluşturacağız ve bu yeni dizide dosya sistemimizin başlangıcını arayacağız.

Öncelikle, daha önce bulduğumuz doğru bölüm sırasına sahip bir dizi oluşturuyoruz:

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

Siparişin verilişine uyulduğunu doğrularız.

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

Şimdi RAID dizisindeki bytestrings tarafından bilinen N + 1 ofsetlerini belirliyoruz. Bir gece için bir komut dosyası çalıştırıyorum (Live CD sudo'da parola istemiyor :):

#!/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

Yorumlu çıktı:

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

Bu verilere göre 3. dize bulunamadığını görüyoruz. Bu, adresindeki öbeğin /dev/sdd2parite için kullanıldığı anlamına gelir . Yeni dizideki parite konumlarının gösterimi:

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

Amacımız, parite parçalarını doğru yere kaydırmak için diziyi hangi bölümden başlayacağınızı saptamaktır. Eşlik iki parça sola kaydırılmalıdır, bölümleme sırası iki adım sağa kaydırılmalıdır. Böylece bu veri kayması için doğru düzen şöyledir 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 

Bu noktada RAID dizimiz doğru biçimde veri içeriyor. RAID veri kayması, orijinal dizideki ile aynı olduğu için şanslı olabilirsiniz ve ardından büyük olasılıkla bölümü bağlayabileceksiniz. Maalesef bu benim durumum değildi.

Veri Tutarlılığını Doğrula

Diziden bir kopyasını çıkararak verilerin bir parça şeridi üzerinde tutarlı olduğunu doğrularız picture.jpg. Bunun için 100k'deki 32 baytlık dizgenin ötelemesini buluruz:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

Daha sonra sonuçtan 100 * 1024 çıkarır ve elde edilen ondalık değeri skip=parametresinde kullanırız dd. count=Boyutudur picture.jpgbayt:

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

extract.jpgAynı olduğunu kontrol edin picture.jpg.

RAID Veri Ofsetini Bul

Bir sidenote: mdadm3.2.3 sürümü için varsayılan veri kayması 2048 sektördür. Ancak bu değer zaman içinde değişmiştir. Orijinal Dizi daha küçük veriler akımından daha ofset kullandıysanız mdadm, o mdadm --createolmadan --assume-cleandosya sisteminin başlayan üzerine yazabilirsiniz.

Önceki bölümde bir RAID dizisi oluşturduk. Bireysel bölümlerin bazıları için yayınlayarak hangi RAID verilerinin mahsup edildiğini doğrulayın:

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

2048 512 bayt sektör 1 MB'dir. Öbek boyutu 512KB olduğundan, geçerli veri kayması iki öbektir.

Bu noktada iki parçalı bir ofsetiniz varsa, muhtemelen yeterince küçüktür ve bu paragrafı atlayabilirsiniz.
Bir 512KB chunk veri ofsetine sahip bir RAID5 dizisi oluşturuyoruz. Bir öbeğin daha erken başlatılması eşliği bir adım sola kaydırır, böylelikle bölme sırasını bir adım sola kaydırarak telafi ederiz. Dolayısıyla 512KB veri ofset için doğru düzen hbdcefga. mdadmVeri ofsetini destekleyen bir sürümünü kullanıyoruz (bkz. Araçlar bölümü). Kilobayt olarak ofset alır:

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

Şimdi geçerli bir ext4 süper bloğu arıyoruz. Süperblokta yapısı burada bulunabilir: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
Biz sihirli sayı tekrarlarını için dizinin başlangıcını tarama s_magicizledi s_stateve s_errors. Aranacak bytestrings şunlardır:

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

Örnek komut:

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

Sihirli sayı, süper blokta 0x38 byte başlar, bu yüzden ofseti hesaplamak ve tüm süper bloğu incelemek için 0x38 çıkartırız:

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                              

Bu geçerli bir süper blok gibi gözüküyor. s_log_block_size0x18'deki alan 0002, yani blok büyüklüğü 2 ^ (10 + 2) = 4096 bayttır. s_blocks_count_lo0x4'te, 254 GB olan 03f81480 bloktur. İyi görünüyor.

Şimdi kopyalarını bulmak için superblock'un ilk baytlarının oluşumlarını araştırıyoruz. Hexdump çıktısına göre bayt saygısına dikkat edin:

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

Bu, superblock'ların beklenen pozisyonlarıyla mükemmel bir şekilde uyum sağlar:

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

Bu nedenle, dosya sistemi, 0xdc80000 ofsetinde başlar, yani bölüm başlangıcından 225792KB. Biri parite için 8 bölümümüz olduğundan, ofseti 7'ye böldük. Mevcut RAID veri kayması bir yığın olduğundan ve orijinal veri kaymasının 64 parça ya da 32768KB olduğu sonucuna vardık. Kaydırma hbdcefgasağa 63 kez düzenini verir bdcefgah.

Sonunda doğru RAID dizisini oluşturduk:

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

Voila

Ben de benzer bir sorun yaşadım. İşletim sistemimi / önyükleme diskimi temiz bir Ubuntu 12.04 kurulumu ile biçimlendirdim ve yeniden kurdum, sonra mdadm --create ... komutunu çalıştırdım ve takamadım.

Geçerli bir süper blok veya bölüm olmadığını söyledi.

Dahası, mdadm baskınını durdurduğumda, normal cihazı artık monte edemedim.

Süper bloğu mke2fs ve e2fsck ile tamir edebildim:

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

Ardından koştu:

e2fsck -b 32768 -y /dev/sdc1

Bu, süper bloğu restore ederek sürücüyü takıp okuyabiliyordum.

Dizinin, kullandığım süper bloğu veya bölümleri yok etmeden çalışmasını sağlamak için build:

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

Verileri doğruladıktan sonra diğer sürücüyü ekleyeceğim:

mdadm --add /dev/md0 /sdd1

Sadece daha önce verilen bilgilerin bir kısmını güncelliyorum. Anakartım öldüğünde 3 diskli bir raid5 dizisi çalışıyordu. / Dev / md2 dizisi / home bölüm 1.2TB ve / dev / md3 / / var bölüm 300GB olarak tutulur.

İnternetin çeşitli yerlerinden aldığım ve gerçekten bırakmam gereken ve seçici bir şekilde bıraktığım iki yedek "önemli" şey ve bir sürü rastgele şey vardı. Yedeklerin çoğu 25 GB veya daha küçük bir .tar.gz dosyasına bölünmüştür ve ayrı bir / etc kopyası da yedeklenmiştir.

Dosya sisteminin geri kalanı 38GB'lık iki küçük baskın0 diskte yapıldı.

Yeni makinem eski donanıma benziyordu ve sadece beş diski de takarak ve eski bir genel çekirdeği seçerek makineyi çalıştırdım. Bu yüzden temiz disk sistemli beş diskim vardı, ancak disklerin doğru sırada olduğundan emin olamadım ve gerektiğinde makineyi güncelleyebileceğimden ve diğerlerini ayıracağımdan emin olmak için Debian Jessie'nin yeni bir sürümünü kurmam gerekti. sorunları.

İki Raid0 disk üzerine kurulu yeni jenerik sistem sayesinde, dizileri bir araya getirmeye başladım. Disklerin doğru sırada olduğundan emin olmak istedim. Yapmam gereken şey:

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

Ama yapmadım. Anlaşılan mdadm oldukça akıllı ve uuid, hangi sürücülerin nereye gittiğini bulabiliyor. Bios / dev / sdc'yi / sda olarak tanımlasa bile, mdadm doğru bir şekilde bir araya getirecektir (YMMV olsa da).

Bunun yerine yayınladım: mdadm --create /dev/md2 without the --assume-cleanve / dev / sde1'deki resync'in tamamlanmasına izin verdim. Yaptığım bir sonraki hata, / dev / md2, / sde1'deki son sürücü yerine / dev / sdc1 üzerinde çalışmaktı. Ne zaman mdadm bir sorun olduğunu düşünürse, atılan ya da yeniden senkronize edilen son sürücü budur.

Ondan sonra, mdadm herhangi bir süper blok bulamadı ve e2fsck -n de bulamadı.

Bu sayfayı bulduktan sonra, sürücülerin sırasını bulma işlemini (bitmiş), geçerli verileri kontrol etmeyi (9MB dosya doğrulandı 6MB), doğru sıradaki diskleri aldım, cde uuid'leri yakaladı / md2 ve / md3'ün eski / etc / mdadm.conf dosyasından ve birleştirmeyi denedi.

Peki, /dev/md3başladı ve mdadm --misc -D /dev/md3üç sağlıklı bölüm ve diskleri doğru sırayla gösterdi. /dev/md2dosya sistemini monte etmeye çalışana kadar da iyi görünüyordu.

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

Dosya sistemi monte edilmeyi reddetti ve e2fsck herhangi bir süper blok bulamadı. Ayrıca, yukarıda tarif edildiği gibi süper bloklar kontrol edilirken, a880 0076 veya a880 0076 veya 5500 1176 olarak bulunan toplam blok sayısı, 1199.79 disk kapasitesi boyutuyla uyuşmadığını bildirdi. Ayrıca, "süper blokların" konumlarından hiçbiri yukarıdaki yazılardaki verilerle aynı hizada değil.

Hepsini değiştirdim / var ve diskleri silmek için hazırladım. Sadece / md2 'nin silinmesinin mümkün olup olmadığını görmek için, (Bu noktada kaybedecek başka bir şeyim yoktu).

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

UUİD’deki değişiklik dışında, hepsi iyi görünüyordu. Birkaç kontrolden sonra 600GB yedeklenmiş veri / dev / md2'ye yazdım. Ardından, söküldü ve sürücüyü yeniden takmaya çalıştı:

# 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

Benimle dalga mı geçiyorsun? dosyadaki 600 GB'im ne olacak?

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

Ah - kolayca sabitlenir. /etc/mdadm.conf içinde uncommented bir satır

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