Soru Yeniden kullanmak yerine yeni dizi oluşturulduktan sonra RAID 5 verilerini kurtarın


Millet lütfen yardım - ben elimde büyük bir baş ağrısı ile bir newb (mükemmel fırtına durumu).

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

mdadm --create -f...

yerine komut

mdadm --assemble

.................................................................... Dizisi bozuldu ve bina ile senkronize edildi ve 10 saat süren senkronizasyon gerçekleştirildi. Geri döndükten sonra dizinin başarılı bir şekilde çalışmaya başladığını gördüm ama baskın değil

Tek tek sürücüler bölümlenmiş (bölüm tipi) f8 ) fakat md0 cihaz değil. Korku içinde gerçekleştirdiğim şeyi yaptım bazı çözümler bulmaya çalışıyorum. Ben sadece dua ediyorum --create sabit sürücünün tüm içeriğinin üzerine yazmadı.

Birisi bana bu konuda yardımcı olabilir misiniz - sürücüde olan veriler çok önemli ve benzersiz ~ 10 yıl fotoğraf, docs, vb.

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

mdadm --examine --scan 

Ben gibi bir şey elde ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0

İlginçtir ki adı 'baskın' olarak kullanılmıştı ve ana bilgisayarla birlikte hame değil: 0 eklendi.

İşte 'sanitized' yapılandırma girişleri:

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 süper blokları temizledim ve diziyi yeniden oluşturdum --assume-clean Seçenek, ama hiç şanssız.

En azından bazı verileri canlandırmamda bana yardımcı olacak bir araç var mı? Birisi bana mdadm --create'ın verileri yok etmek için ne zaman ve nasıl yaptıklarını söyleyebildiğini söyleyebilsin, böylece ne yapıldıysa yapmamam için bir araç yazabilirim?

Raid yeniden yaratıldıktan sonra fsck.ext4 / dev / md0 çalıştırıyorum ve çıktı

root @ tanserv: / etc / mdadm # fsck.ext4 / dev / md0 .................................................................... fsck.ext4: Superblock geçersiz, yedek blokları deniyor ... fsck.ext4: / dev / md0 açmaya çalışırken süper blokta kötü sihirli sayısı

Süper blok okunamadı veya doğru bir ext2 açıklamıyor dosya sistemi. Cihaz geçerliyse ve gerçekten bir ext2 içeriyorsa dosya sistemi (ve takas veya ufs veya başka bir şey değil), sonra süper blok bozuktur ve alternatif bir süper blok ile e2fsck'i çalıştırmayı deneyebilirsiniz:     e2fsck -b 8193


Shanes'in önerisine göre 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 fsck.ext4'ü her yedekleme bloğuyla çalıştırın, ancak tümü aşağıdakileri döndürdü:

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>

Herhangi bir öneri?

Saygılarımızla!


34
2018-01-07 06:24


Menşei


Belki de bir gün insanlar RAID5'in neden korkunç bir fikir olduğunu anlayabilirler. O zamana kadar, 1) insanlar veri kaybedecek. 2) Bunlar gibi sorular alırız. - Tom O'Connor
@Tom O'Connor ... çünkü açıkça, RAID5 kullanıcı hatası için suçluyor. : Rolleyes: - Reality Extractor
Umarım, Shane'in cevabı verileri kaydedebilir, ancak yine de RAID'in neden tek başına depolama için en iyi olmadığını kanıtlayabilir. Yedeklemeye de ihtiyacınız var. (ancak soruya verilen ve sonuçlanan epik cevap için +1) - tombull89
Sık sık tekrarlandığını biliyorum ama baskın bir çözüm değil. Mesajın gerçekten eve gitmesi gerekiyor. - Sirex


Cevaplar:


Tamam - senin sorunun hakkında bir şeyler beni rahatsız ediyordu, bu yüzden beklenen bir davranışa dalmak için bir VM'yi ateşledim. Bir dakikalığına beni rahatsız eden şeylere ulaşacağım; önce şunu söyleyeyim:

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

Yeniden oluşturmanın ötesinde bir hasar yapmış olabilirsiniz; dediğin zaman ne demek istediğini açıklayabilir misin:

Önerilere göre süper blokları temizledim ve diziyi --assume-clean seçeneğiyle yeniden oluşturdum, ama hiç şansı yok.

Koşarsan mdadm --misc --zero-superblockO zaman iyi olmalısın.

Her neyse, yeni diskleri temizleyin ve bu disklere daha fazla yazı yazabilecek herhangi bir şey yapmadan önce bunların tam olarak geçerli resimlerini alın.

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

Şöyle söyleniyor ki, bu şeylerde saklanan veriler, görünüşe göre resyncs'a karşı şok edici bir şekilde dayanıklıdır. Okumaya devam, umut var ve bu cevap uzunluğu sınırına ulaştığım gün olabilir.


En İyi Durum Senaryosu

Senaryoyu yeniden oluşturmak için bir VM atadım. Sürücüler sadece 100 MB'tır, bu yüzden her resync'de beklemeyi beklemezdim, ama aksi takdirde bu oldukça doğru bir sunum olmalı.

Diziyi mümkün olduğunca genel ve varsayılan olarak oluşturduk - 512k parçalar, sol simetrik düzen, harf sırasındaki 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; bir dosya sistemi yapalım ve üzerine biraz veri yazalı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. Bir dosya sistemimiz ve bazı verilerimiz var. datafileve bu SHA1 hash ile 5MB değerinde rastgele veri randomdata) üstünde; Yeniden oluşturduğumuzda 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 çabuk bitti, ama gerçekleşti. Bu yüzden, beni daha önce bulamıyorum; sizin fdisk -l çıktı. Üzerinde bölüm tablosu yok md Cihaz hiç sorun değil, bekleniyor. Dosya sisteminiz, doğrudan bölüm tablosu bulunmayan sahte blok cihazı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ölüm tablosu 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'den sonra mükemmel bir dosya sistemi. Yani bu iyi; veri dosyalarımıza bakalı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

Katı - hiç veri bozulması yok! Ancak bu, aynı ayarlarla aynı olduğundan, iki RAID grubu arasında hiçbir şey farklı şekilde eşlenmedi. Kırmaya kalkmadan önce bu şeyi indirelim.

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

Bir adım geri almak

Bunu kırmaya çalışmadan önce, neden kırılmasının zor olduğu hakkında konuşalım. RAID 5, bir alanı, dizideki diğer tüm disklerdeki blokla aynı boyutta koruyan bir parite bloğu kullanarak çalışır. Parite sadece belirli bir disk üzerinde değil, normal kullanımda diskler üzerinden okunan yükü daha iyi yaymak için disklerin etrafında eşit olarak döndürülüyor.

Parite 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

Bir ölü veya eksik diski değiştirirken genellikle bir resync yapılır; ayrıca bitti mdadm create Disklerdeki verilerin, RAID'in geometrisinin neye benzemesi gerektiği ile hizalanmasını sağlamak. Bu durumda, dizi özelliğindeki son disk, "senkronize" olanı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 bulunmuş olması ya da yeni parite blokları oluşturması için parite bloklarının dışında yeni veri blokları oluşturuyor.

Harika olan şey, her ikisinin de prosedürünün tam olarak aynı olmasıdır: disklerin geri kalanından gelen verilerde bir XOR işlemi. Bu durumda resync süreci, belirli bir bloğun bir parite bloğu olması gerektiğine ve aslında eski bir veri bloğunu yeniden oluşturduğuna göre yeni bir parite bloğu oluşturduğunu düşünüyor olabilir. Yani olsa bile düşünüyor Bunu inşa ediyor:

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

... sadece yeniden inşa edilebilir DISK5 yukarıdaki düzende.

Dolayısıyla, dizi yanlış yapılmış olsa bile verilerin tutarlı kalması mümkündür.


İşlere bir maymun atmak

(bir 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, bu iyi ve güzel. 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ü tüm veriler oradayken, yanlış sırayla; Bir zamanlar 512 KB A, sonra 512 KB B, A, B ve benzerleri şimdi B, A, B, A'ya karıştırıldı. Disk artık dosya sistemi denetleyicisine cılız gibi görünüyor, işe yaramıyor. Çıktı mdadm --misc -D /dev/md1 bize daha fazla detay verir; Şuna benziyor:

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 güzel. Bu zaman zarfında yeni parite blokları ile bir sürü veri bloğu yazdık. Şimdi doğru siparişle yeniden oluştur:

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

Temiz, 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, yığın boyutunu değiştirelim ve bu bize biraz kırıklık olup olmadığına bakalı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 kurulduğunda gözyaşı dökülür. Ama 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 budur - 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).

Korkunç ve kötü - bir şey bulduğunu düşünüyor ve bazı sabitleme yapmak istiyor! Ctrl+C!

Clear<y>? cancelled!

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

Tamam, kriz önlendi. Yanlış düzen ile yeniden senkronize edildikten 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üperblock sıfırlamanın gerçek hızlı bir zararlı olmadığını da 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.

Test 5

Sadece elimizde olan herşeyi atalım. Birleştirilmiş 4 önceki test.

  • Yanlış cihaz sırası
  • Yanlış parça boyutu
  • Yanlış düzen algoritması
  • Sıfırlanmış süper bloklar (bunu her iki kreasyon arasında 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 bozulmamış gibi görünüyor. Bu sonuçtan oldukça şaşırdım, açıkçası; Bench boyutu değişiminde orta düzeyde veri kaybı ve düzen değişikliği üzerindeki bazı kesin kayıpları bekledim. Bugün bir şey öğrendim.


Peki .. Verilerimi nasıl alabilirim?

Eski sistem hakkında sahip olduğunuz kadar bilgi sizin için son derece yararlı olacaktır. Dosya sistemi türünü biliyorsanız, eski kopyalarınız varsa /proc/mdstat sürücü sırası, algoritma, yığın boyutu ve meta veri sürümü hakkında bilgi. Mdadm'ın e-posta uyarıları ayarlandı mı? Eğer öyleyse, eski bir tane bulun; değilse, kontrol edin /var/spool/mail/root. Kontrol edin ~/.bash_history Orijinal yapınızın orada olup olmadığını görmek için.

Yani, yapmanız gereken şeylerin listesi:

  1. İle diskleri yedeklemek dd bir şey yapmadan önce!
  2. Deneyin fsck Geçerli, aktif md - daha önce olduğu gibi aynı sırayla inşa edilmiş olabilirsiniz. Dosya sistemi türünü biliyorsanız, bu yararlı olur; o spesifik kullan fsckaracı. Araçlardan herhangi biri herhangi bir şeyi düzeltmek için teklif veriyorsa, geçerli dosya sistemini gerçekten bulduğundan emin olmadıkça bunları izin vermeyin! Eğer fsck Sizin için bir şey düzeltmek için teklifler, gerçekten yardım etmek ya da sadece veri nuke hakkında sormak için bir yorum bırakmak için çekinmeyin.
  3. Diziyi farklı parametrelerle oluşturmayı deneyin. Eski bir tane varsa /proc/mdstatsonra sadece gösterdiği şeyleri taklit edebilirsin; eğer değilse, o zaman karanlıktasınız - farklı sürücü emirlerinin tümünü denemek mantıklıdır, ancak olası her bir emirle olası her bir mermi boyutunu kontrol etmek nafile. Her biri için, fsck umut verici bir şey elde edip etmediğini görmek için.

Yani, bu kadar. Roman için üzgünüm, herhangi bir sorunuz varsa ve iyi şanslar varsa yorum bırakabilirsiniz!

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


87
2018-01-08 08:27



Bu harika bir cevap. - Antoine Benkemoun
Ne söyleyeceğimi bile bilmiyorum ... BRAVO !!! Shane Madden için Kudos. Diskleri yedekleyeceğim ve önerilerinize başlayacağım. Teşekkürler, gerçekten büyük bir teşekkür! - Brigadieren
Ben sadece ... vay canına. Parlak cevap. Bence 30,000 karakter sınırını aşmanın tek cevabı Evan Andersons'un "Altyapı Nasıl Çalışır" denemesidir. - tombull89
Endişelendiğim kadarıyla SF'nin en iyi cevabı. - Chopper3
Siz efendim, interneti kazanın. - Mark Henderson♦


Eğer sen şanslı Bozuk bir RAID-5 dizisini okuyabilen kurtarma yazılımı ile dosyalarınızı geri almanızla ilgili bazı başarılarınız olabilir. Sıfır varsayım kurtarma Ben daha önce biriyle başarılı oldum.

Bununla birlikte, yeni bir dizi oluşturma sürecinin tüm verileri geçip geçmediğinden emin değilim, bu yüzden bu son şans olabilir.


5
2018-01-07 07:33



Çok teşekkürler Mark. Bir deneyeceğim. Sürücüleri değiştirip değiştirmediğini biliyor musunuz? Eğer öyleyse bir disk kopyası yapacağım ve diğer araçlarla da deneyeceğim. - Brigadieren
@Brigadieren - hayır, üzgünüm, RAID5'in nasıl çalıştığıyla ilgili yeterince aşina değilim. - Mark Henderson♦
@ Brigadieren göre mdadm belgeleriOluşturma işlemi veriyi yok etmeyecek, sadece resync - ancak orijinalinizle uyuşmayan bir geometri seçtiyse, yeni parite yazımıyla verileri yok edebilir. Daha sonra boş vaktim varsa, herhangi bir içgörü ekleyip ekleyemeyeceğimi görmek için durumunuzu bir VM'de yeniden oluştururken görebiliyorum. Disklere yazacak herhangi bir kurtarma adımı denemeden önce sürücülerin tam kopyalarını tutmanızı tavsiye ederim - kopya yapmak için fazladan disk almak isteyebilirsiniz. - Shane Madden♦
Senkronizasyona neyin neden olduğu konusunda emin değilim - dizinin ilk sırada (elektrik kesintisi nedeniyle) ya da başka bir şeyde düştüğü gerçeği mi? Mdadm --create, başlangıçta verilmiş olandan daha farklı bir sürücü siparişi belirtip belirlemediğimi ayırt edip etmediğini merak ediyorum. - Brigadieren
@Brigadieren Sync her zaman yaratımda oluşur. - Shane Madden♦


Benzer bir sorunum vardı:
Bir yazılım RAID5 dizisi başarısızlıktan sonra kovuldum mdadm --create vermeden --assume-cleanve artık diziyi bağlayamadım. İki haftalık kazma işleminden sonra tüm verileri geri yükledim. Umarım aşağıdaki prosedür bir kişinin zamanını kurtaracaktır.

Uzun lafın kısası

Sorun aslında mdadm --create orijinalden iki açıdan farklı olan yeni bir dizi yaptı:

  • bölümlerin farklı sırası
  • farklı RAID veri ofseti

Zeki olarak gösterildiği gibi Shane Madden cevap, mdadm --create çoğu durumda verileri yok etmez! Bölüm sırası ve veri ofsetini bulduktan sonra diziyi geri yükleyebilir ve ondan tüm verileri ayıklayabilirim.

Ön şartlar

RAID süper blokları yedeklemem yoktu, tek bildiğim Xubuntu 12.04.0 kurulumu sırasında oluşturulan 8 bölümlü bir RAID5 dizisi olduğunu biliyordum. Bir ext4 dosya sistemi vardı. Diğer önemli bir bilgi parçası da RAID dizisinde saklanan bir dosyanın kopyasıydı.

Araçlar

Xubuntu 12.04.1 canlı CD tüm çalışmaları yapmak için kullanıldı. Durumunuza bağlı olarak, aşağıdaki araçlardan bazılarına ihtiyaç duyabilirsiniz:

veri ofseti belirlemeye izin veren 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 bir hesap makinesi - repostan standart araçlar

Tam Yedekleme ile Başlayın

Aygıt dosyalarının adlandırılması, ör. /dev/sda2  /dev/sdb2 vb. kalıcı değildir, bu yüzden sürücülerin seri numaralarını yazmanız daha iyidir.

sudo hdparm -I /dev/sda

Sonra harici bir HDD takın ve RAID dizinizin her bir bölümünü aşağıdaki gibi yedekleyin:

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

Orijinal RAID5 Düzenini Belirle

Çeşitli düzenler burada açıklanmıştır: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Veri dizilerinin orijinal dizide nasıl düzenlendiğini bulmak için, dizide saklandığını bildiğiniz rastgele görünen bir dosyanın kopyasına ihtiyacınız vardır. Şu an tarafından kullanılan varsayılan yığın boyutu mdadm 512KB. Bir N bölümü dizisi için, en azından (N + 1) * 512KB boyutunda bir dosyaya ihtiyacınız vardır. Bir jpeg veya video, ikili verinin nispeten benzersiz alt dizelerini sağladığı için iyidir. Dosyamızın çağrıldığını varsayalım picture.jpg. N + 1 pozisyonlarında 100k'dan başlayan ve 512k'lık artışla 32 bayt veri okuyoruz:

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 bu ham bölümlemelerin tümünün yinelenen kısımlarını araştırırız, böylece toplamda (N + 1) * N komutları, bunun gibi:

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 taraması yaklaşık 12 dakika sürdü. Benim durumumda, her 32 baytlık dize, sekiz sürücünün sadece bir kez bulundu. Bgrep tarafından döndürülen ofsetleri karşılaştırarak, aşağıdaki gibi 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 görüyoruz Sol-simetrik için varsayılan düzen mdadm. Daha da önemlisi, artık bölümlerin sırasını biliyoruz. Bununla birlikte, döngüsel olarak kaydırılabileceğinden, dizideki hangi bölümün hangi bölüm olduğunu bilmiyoruz.

Ayrıca bulunan sapmalar arasındaki mesafeye dikkat edin. Benim durumumda 512KB oldu. Öbek boyutu aslında bu mesafeden daha küçük olabilir, bu durumda gerçek düzen farklı olacaktır.

Orijinal Chunk Boyutunu Bul

Aynı dosyayı kullanıyoruz picture.jpg Birbirinden farklı aralıklarla 32 bayt veri okumak. Yukarıdan 100 k ofsetindeki verilerin açık olduğunu biliyoruz. /dev/sdh2, 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ı doğrularız. Bunun için 356k ofset değerine tökezliyoruz ve hangi bölüme oturduğuna bakalım:

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

Öbek büyüklüğünün 256 KB olmadığına işaret eden offset 612k ile aynı bölümdedir. Benzer boyuttaki daha küçük boyuttaki parçaları da ortadan kaldırıyoruz. Tek olasılık olan 512KB parçaları ile bitti.

Düzeninde İlk Bölümü Bul

Artık bölümlerin sırasını biliyoruz, ancak hangi bölümün hangisinin ilk olduğunu ve hangi RAID veri ofsetinin kullanıldığını bilmiyoruz. Bu iki bilinmeyen noktayı bulmak için, doğru yığın düzeni ve küçük bir veri ofseti ile bir RAID5 dizisi oluşturacağız ve bu yeni dizide dosya sistemimizin başlangıcını arayacağız.

Başlangıç ​​olarak, daha önce bulduğumuz bölümlerin doğru düzenine 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şe 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 bilinen bytestrings N + 1 ofsetlerini belirliyoruz. Bir gece için senaryo hazırlıyorum (Canlı CD sudo şifresi 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

Yorumlarla çı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 dayanarak 3. dizenin bulunmadığını görüyoruz. Bunun anlamı, /dev/sdd2 parite için kullanılır. İşte yeni dizideki eşlik pozisyonlarının bir örneğidir:

| 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 başlatmak için hangi bölümün çıkacağını belirlemektir. Parite iki parça sola kaydırıldığından, bölüm sırası iki adım sağa kaydırılmalıdır. Böylece bu veri ofseti için doğru düzen 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çerir. RAID veri ofseti, orijinal dizidekiyle aynı olduğundan ve büyük olasılıkla bölümleri monte edebileceğiniz için şanslı olabilirsiniz. Ne yazık ki bu benim durumum değildi.

Veri Tutarlılığını Doğrulayın

Verilerin bir kopyasını bir kopyasını çıkararak bir parça şerit üzerinde tutarlı olduğunu doğrularız picture.jpg diziden. Bunun için 100 baytta 32 baytlık dizginin ofsetini buluyoruz:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

Daha sonra sonuçtan 100 * 1024 ayrılır ve elde edilen ondalık değer kullanılır. skip= parametresi dd. count= büyüklüğü picture.jpg bayt cinsinden:

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

Şunu kontrol et extract.jpg aynıdır picture.jpg.

RAID Veri Ofsetini Bul

Bir sidenote: için varsayılan veri ofseti mdadm 3.2.3 sürümü 2048 sektördür. Fakat bu değer zamanla değişti. Orijinal dizi, akımınızdan daha küçük bir veri ofseti kullandıysa mdadm, sonra mdadm --create olmadan --assume-clean dosya sisteminin başlangıcını üzerine yazabilir.

Bir önceki bölümde bir RAID dizisi oluşturduk. Bazı bölümler için yayınlayarak hangi RAID verilerinin dengelendiğini doğrulayın:

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

2048 512 bayt sektörler 1 MB'dir. Chunk boyutu 512KB olduğundan, mevcut veri ofseti iki parçadır.

Bu noktada iki bölümlü bir ofsetiniz varsa, muhtemelen yeterince küçüktür ve bu paragrafı atlayabilirsiniz.
Bir 512KB yığınının veri ofseti ile bir RAID5 dizisi oluşturuyoruz. Bir parça daha önce başlamak parite bir adım sola kaydırır, böylelikle bölme dizisini bir adım sola kaydırarak telafi ederiz. Bu nedenle 512KB veri ofseti için doğru düzen hbdcefga. Bir sürümünü kullanıyoruz mdadm Bu, veri ofsetini destekler (bkz. Araçlar bölümü). Kilobayt cinsinden dengelenir:

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 bloku arıyoruz. Süper blok yapısı burada bulunabilir: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
Sihirli sayının oluşumları için dizinin başlangıcını taradık s_magic bunu takiben s_state ve s_errors. Aramak için bytestrings şunlardır:

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

Örnek komut:

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

Sihirli sayı, süperblock içine 0x38 bayt başlar, böylece ofseti hesaplamak ve tüm süper bloğu incelemek için 0x38'i çıkarı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örünüyor. s_log_block_size 0x18'deki alan 0002'dir, yani blok boyutu 2 ^ (10 + 2) = 4096 bayttır. s_blocks_count_lo 0x4 de 254GB olan 03f81480 bloklarıdır. İyi görünüyor.

Artık kopyalarını bulmak için süper blokun ilk baytının oluşumlarını taraıyoruz. Bayt, hexdump çıkışı ile karşılaştırıldığında saygısız not alın:

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, yedekleme süper bloklarının beklenen konumlarıyla mükemmel bir şekilde hizalanır:

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

Dolayısıyla dosya sistemi, başlangıçtan itibaren 0xdc80000, yani 225792KB ofset ile başlar. Biri parite için olan 8 bölüme sahip olduğumuzdan, ofset'i 7'ye böleriz. Bu, her bölümde, tam olarak 63 RAID parça olan 33030144 bayt ofsetini verir. Mevcut RAID veri ofseti bir yığın olduğundan, orijinal veri ofsetinin 64 veya 32768KB olduğu sonucuna vardık. değişken hbdcefgaSağa 63 kez düzen 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


4
2017-07-08 01:19



Mükemmel bir örnek. Bir not - 53EF00000100, EXT4 başlığı için geçerli bir bağlantı gibi görünmüyor. Göre ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block 53EF'den sonra iki bayt sadece 0100, 0200 veya 0400 olabilir. - matt


Benzer bir sorunum vardı. OS / boot sürücümü biçimlendirdim ve Ubuntu 12.04'ü temiz bir şekilde kurdum, ardından mdadm - create ... komutunu çalıştırdım ve takamıyorum.

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

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

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

Sonra koştu:

e2fsck -b 32768 -y /dev/sdc1

Bu süperblocku geri yükledi, böylece sürücüyü monte edip okuyabileydim.

Diziyi oluşturmak için süper blok veya bölümleri yok etmeden çalışmam için:

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

0
2018-01-10 23:34





Daha önce verdiğim bazı bilgileri güncelliyorum. Anakartım öldüğünde 3 diskli bir raid5 dizisi çalışıyordu. Dizi / dev / md2 / ev bölümü 1.2TB ve / dev / md3 / var bölüm 300GB olarak tutuldu.

İnternetin çeşitli bölümlerinden aldığım ve seçtiğim bir şekilde terk ettiğim iki farklı "önemli" malzeme ve bir dizi rastgele şeylerim vardı. Yedeklerin çoğu 25 GB veya daha az .tar.gz dosyalarına ayrıldı ve ayrı bir / etc kopyası da yedeklendi.

Dosya sisteminin geri kalanı, 38GB'lık iki küçük raid0 diskinde tutuldu.

Yeni makinem eski donanıma benziyordu ve beş diski takıp eski bir jenerik çekirdeği seçerek makineyi çalıştırdım. Bu yüzden, diskler doğru sırada olduklarından emin olmasam da temiz dosya sistemlerine sahip beş diskim vardı ve gerektiğinde makineyi yükseltebildiğinden emin olmak için Debian Jessie'nin yeni bir sürümünü yüklemem gerekiyordu ve diğerlerini sıraladım. sorunları.

İki Raid0 diske kurulan yeni jenerik sistemle dizileri tekrar bir araya getirmeye başladım. Doğru sırayla disklerim olduğundan emin olmak istedim. Yapmam gerekeni yapmak:

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

Ama ben yapmadım. Görünüşe bakılırsa mdadm oldukça zeki ve uuid verildi, hangi sürücülerin nereye gittiğini anlayabiliyor. Bios / dev / sdc / sda olarak adlandırılmış olsa bile, mdadm onu ​​doğru şekilde bir araya getirecektir (YMMV olsa).

Bunun yerine yayınladım: mdadm --create /dev/md2 without the --assume-cleanve / dev / sde1 üzerindeki resync komutunun tamamlanmasına izin verildi. Bir sonraki hata / dev / md2 / sde1'deki son sürücü yerine / dev / sdc1 üzerinde çalışmaktı. Herzaman mdadm bir sorun olduğunu düşünür, baştan çıkarılan veya yeniden senkronize edilen son sürücüdür.

Bundan sonra, mdadm hiçbir süperblok bulamadı ve e2fsck -n da olamazdı.

Bu sayfayı bulduktan sonra, sürücüler için diziyi bulmayı denedim (geçerli), geçerli verileri kontrol et (9MB'lık bir dosyanın 6MB'sı doğrulandı), diskleri doğru sırada aldım, cde, uuid'i yakaladım. / etc / md2 / / md3 /etc/mdadm.conf dosyasından ve birleştirilmeye çalışıldı.

İyi, /dev/md3 başladı ve mdadm --misc -D /dev/md3 üç sağlıklı bölüm ve diskleri doğru sırada gösterdi. /dev/md2Dosya sistemini kurmaya çalışana kadar 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 bulunamadı. Ayrıca, yukarıda açıklandığı gibi süper blokları kontrol ederken, 1180.76 veya a8080 0076 veya 5500 1176 olarak bulunan toplam blok sayısı 1199.79 disk kapasitesi ile eşleşmedi. Ayrıca, "süper blokların" konumlarının hiçbiri, yukarıdaki gönderilerdeki verilerle hizalı değildir.

Tüm / var yedekledim ve diskleri silmeye hazırlandım. Sadece / md2'yi silmek mümkün olup olmadığını görmek için, (bu noktada kaybedecek başka bir şeyim yoktu) Aşağıdakileri yok sayıyorum:

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

Her şey yolunda gitti, uuid'deki değişiklik dışında. Birkaç kez daha kontrol ettikten sonra, 600 GB yedeklenmiş veriyi / dev / md2'ye yazdım. Daha sonra, takılı değil 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 600GB'm ne olacak?

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

Ah - kolayca düzeltildi. /etc/mdadm.conf 'un 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!


0
2018-02-04 14:19