RAID0 veri kurtarma ve kurtarma stratejisi doğrulama

NAS cihazıma bağlı bir Synology genişlemesine (DX213) sahibim. 2 TB 2 disk içerir ve RAID0 yapılandırmasındadır (korkunç bir fikir, biliyorum ve bir hatırlatmaya ihtiyacım yok;)). Geçen hafta sonu dizi başarısız oldu ve artık RAID dizisini başlatamıyorum.

Konunun arka panelden (DX213) kaynaklandığına ve diskte görünmediğine inanmaya başladım çünkü iyi görünüyorlar. Kesinlikle ölmediler (henüz). Onları bir linux makineye bağlı tutuyorum ve onları iyi görebiliyorum:

$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 1.8 TiB, 2000396746752 bytes, 3907024896 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000a85dd

Device     Boot   Start        End    Sectors  Size Id Type
/dev/sdb1           256    4980735    4980480  2.4G 83 Linux
/dev/sdb2       4980736    9175039    4194304    2G 82 Linux swap / Solaris
/dev/sdb3       9437184 3907024064 3897586881  1.8T 83 Linux

$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 1.8 TiB, 2000396746752 bytes, 3907024896 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0004dd4e

Device     Boot   Start        End    Sectors  Size Id Type
/dev/sdc1           256    4980735    4980480  2.4G 83 Linux
/dev/sdc2       4980736    9175039    4194304    2G 82 Linux swap / Solaris
/dev/sdc3       9437184 3907024064 3897586881  1.8T 83 Linux

Diskleri incelerken, mdadmbaskın dizisini hala tanıyabilir ve her iki disk de temiz durumda görünüyor, ancak her iki diskteki süper bloklar da açıkça senkronize değil.

$ sudo mdadm --examine /dev/sd[bc]3 
/dev/sdb3:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 1d7dd58f:dd7dd3d2:b646173b:afd51417
           Name : mist-nas:2
  Creation Time : Tue Nov 26 19:47:24 2013
     Raid Level : raid0
   Raid Devices : 2

 Avail Dev Size : 3897584833 (1858.51 GiB 1995.56 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1968 sectors, after=0 sectors
          State : clean
    Device UUID : 46933df7:36901a5b:7a1239fe:e999c419

    Update Time : Sat Aug 27 20:14:12 2016
       Checksum : 42117b5b - correct
         Events : 8

     Chunk Size : 64K

   Device Role : Active device 0
   Array State : A. ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdc3:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 1d7dd58f:dd7dd3d2:b646173b:afd51417
           Name : mist-nas:2
  Creation Time : Tue Nov 26 19:47:24 2013
     Raid Level : raid0
   Raid Devices : 2

 Avail Dev Size : 3897584833 (1858.51 GiB 1995.56 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1968 sectors, after=0 sectors
          State : clean
    Device UUID : e4b60f4c:604b2e27:359cb71b:24453937

    Update Time : Tue Nov 26 19:47:24 2013
       Checksum : 997fa41a - correct
         Events : 4

     Chunk Size : 64K

   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)

Tek fark, son güncelleme zaman damgası ve olay sayımıdır. Dizilim düştüğünde ve her iki disk de temiz durumda olduğunda yazma işlemlerinin devam etmediğini biliyorum, bu yüzden verilerime erişebildiğimden eminim. Yine de, iyileşmek için diziyi yeniden yaratmam ya da hatalı süper blokla oynamam gerekecek ve bu beni korkutuyor, en azından ...

ddAptalca bir şey yapmam durumunda yedekleme yapabilmek için her iki sürücüyü de yeni sürücülere kopyaladım . Yeni sürücüler 4096'lık bir sektör boyutuna sahip olsalar da (3 ve 4 TB diskler), eski sürücüler 512'lik bir sektör boyutuna sahip. bölmenin boyutunu bir sonraki sektöre yuvarlamak zorunda kaldım. Umarım bu bir problem değildir?

Çalıştırmayı düşündüğüm komut:

$ sudo mdadm --create --readonly --assume-clean --level=0 -n2 /dev/md2 /dev/sdb3 /dev/sdc3

Bu komut muhtemelen şu anki süper blokların üzerine yazacak, bu yüzden verilerimin geri kazanılma şansını mahvetmeyeceğinden kesinlikle emin olmak istiyorum. Bu komutun sonucu ne olacak?

Ayrıca, gerçekten harekete geçmeden önce stratejimi doğrulamak istiyorum. Bir USB anahtarı üzerinde 2 4 GB'lık bölüm oluşturdum, onlarla bir RAID0 dizisi oluşturdum, dizide bir EXT4 dosya sistemi oluşturdum, monte ettim ve bazı dosyaları kopyaladım. Sorun, 4TB dizisi ile olan durumumuzu yeniden oluşturmak için bölümlerden birinin süper bloğunu nasıl değiştirebileceğim.

Süper bloğu elle değiştirmek için onaltılı bir editör kullanmayı düşünüyordum, ama o zaman da sağlama toplamını yeniden hesaplamam gerekecekti. Bunu nasıl yapmalıyım?

Sürücüyü diziden kaldırmalı, sistemden kaldırmalı, diskleri yeniden araştırmalı ve ardından sürücüyü tekrar diziye eklemelisiniz.

Arızalı sürücüyü diziden çıkartın.

mdadm --manage --set-faulty

Sürücüyü fiziksel olarak sistemden / sistemden çıkarın ve yeniden takın (veya aygıt silme ve scsi ana bilgisayar yeniden taramasını kullanarak).

Şimdi sürücünün tekrar bulunup bulunmadığını kontrol edin ve doğru çalışıp çalışmadığını kontrol edin. Dmesg çıktısını görebilir veya / proc / partitions dosyasına bakabilirsiniz. Bir pv <cihazda çalıştırın .

Sonra sürücüyü diziye yeniden ekleyin mdadm.

Ardından, cat /proc/mdstatbaşarılı olup olmadığınızı görmek için son bir kontrol yapın .

Verilerimi geri almayı başardım, ancak önemsiz bir şekilde olmasın (spoiler uyarısı: hex editörleri ve bazı tersine mühendislik içeriyor). Gelecekte referans olması için yaklaşımımı gönderiyorum.

Yani benim RAID0 dizim eşleşmeyen süper bloklardan dolayı bozuldu. RAID0'da artıklık mdadmolmadığından, tüm süper bloklar eşleşmediği sürece RAID0 dizisini başlatamaz. Disklerim iyi görünüyordu ama süper bloklar senkronize değildi.

Çözüm: Süper blokları tekrar eşleştirin.

İlk fikir: Yukarıdaki komutu çalıştırmak, RAID dizisini eskisi gibi yeniden yaratır, fakat mevcut süper blokların üzerine yazar.

İlk fikir değerlendirmesi: riskli. mdadmDiziyi eskisi gibi aynı şekilde yeniden oluşturacağının garantisi yoktur . Belki bazı parametreleri unutabilirim, belki mdadmistediğimden başka yerlerde yazabilir, temel dosya sistemimi ve verilerimi mahvedebilir, hatta başka bir şey bile.

Sonuç: Kötü fikir.

İkinci fikir Onaltılı bir editör kullanarak süper blokları kendim yönet.

Artıları:

• Aptalca bir hata yapmazsam, önemli olmayan baytlarda hiçbir değişiklik yapılmayacak, kontrolümdeyim.
• Yalnızca süper bloğun eşleşmeyen değerleri değiştirilir, bu nedenle dizinin düzeni etkilenmez.

Zorluklar:

• Süper blok diskte nerede bulunur?
• Nasıl görünüyor?
• Doğru baytları tanımlayabilir mdadm --examineve onaltılık değerleri okumaktan çıktısını yeniden oluşturabilir miyim ?
• Niteliklerin değiştirilmesi, süper blok sağlama toplamını geçersiz kılar, geçerli bir sağlama toplamı nasıl alabilirim?

Anlaşıldığı üzere, bu zorlukların üstesinden gelmek oldukça kolaydır. Linux baskın wiki'de harika bir sayfa var: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats . V1 süper bloğunu ve diskte nerede bulacağını belgeler. V1.2 superblock için, diskin başından itibaren 4K'da bulunur ve bir sonraki 4K'da yazılmıştır (çünkü sektör hizalıdır ve yeni diskler üzerinde kullanıldığı disk 512 bayt sektöre sahip olsa bile 4K sektörlerini kullanır) .

Ayrıca, okunması zor olmayan v1 süper bloğunun kaynak koduna da başvurabilirsiniz: https://github.com/neilbrown/mdadm/blob/master/super1.c

Dikkatli bir analizden sonra bu plana yerleştim:

1. İlk olarak, her diskin ilk 8K'sını yedekleyin. Bu şekilde her zaman orijinal durumuna geri dönebilirim.

   dd eğer = / dev / sdXY = sdXY.backup bs = 1 sayım = 8K

2. Her diskin süper bloklarını çıkarın. Bu kolayca yapılabilir

   dd eğer = / dev / sdXY, = sdXY.superblock bs = 1 sayım = 4K atla = 4K

3. Bir hex editörde süper blokta okuyun. Web tabanlı http://hexed.it çok iyi buldum .

4. Gerekli özellikleri değiştirin, sağlama toplamını olduğu gibi bırakın. Zaman damgalarını değiştirirken dikkatli olun. Bir linux zaman damgası 32 bit veya 4 bayt mdadmalır , bir zaman damgasında 64 bit veya 8 bayt alır. Diğer 4'ü kopyalamayı unutmayın. Süper blok, dizinin her üyesi için 256 bayt + 2 bayttır. Bu son baytlar, bir üye kimliği veya rol dizisidir.

5. Süper bloğu diske yazın.

   dd if = sdXY.superblock = / dev / sdXY bs = 1 sayım = 4K arama = 4K

6. Süper bloğu ile inceleyin mdadm --examine /dev/sdXY. Size sağlama toplamı geçersiz olduğunu gösterir, ancak beklenen sağlama toplamı da gösterir.

7. Sağlama toplamını doğru olana değiştirin. Onaltılı düzenleyicide baytlar ters çevrilir, bu yüzden onaltılı düzenleyicide `99 7F A4 1A becomes1A A4 7F 99`.

8. Yeni süper bloğu, 5. adımla aynı komutla diske yazın.

9. Her disk için tekrarlayın.

Her iki süper blok birbirine uyduğunda, diziyi tekrar başlatmayı başardım. Dosya sistemini kontrol ettim ve temiz görünüyordu. Dosya sistemini monte ettim ve her şeyi, yakında UPS ile de koruyacağım bir RAID5 dizisine kopyaladım.

Çok şanslı oldum ve bu çok korkutucu anları unutmayacağım. Her zaman sakinliğimi korudum ve diziyi nasıl birleştirebileceğimi düşünmeye devam ettim.

Sorunu iyice analiz etmeden önce bozuk dizinizle oynamayı şiddetle tavsiye ediyorum. Ayrıca, başlamadan önce planımı yazdım, böylece bir adımı atlamamıştım, böylece veri kaybı riskiyle karşı karşıya kaldım.