FreeBSD'deki ZFS: veri bozulmasından kurtarma


44

Veri bozulmasından dolayı erişemediğim bir havuzda çok değerli kişisel verilerim var. Havuz başlangıçta 2009 yılında, bir VMWare sanal makinesinde çalışan bir Ubuntu 8.04 sisteminin üstünde çalışan bir FreeBSD 7.2 sistemine kurulmuştu. FreeBSD VM hala kullanılabilir ve çalışıyor, sadece ana işletim sistemi şimdi Debian 6 olarak değiştirildi. Sabit diskler, VMWare jenerik SCSI cihazları ile toplamda 12 konuk VM'ye erişilebilir hale getirildi.

2 havuz var:

  • zpool01: 2x 4x500GB
  • zpool02: 1x 4x160 GB

İşe yarayan boş, kırılan önemli tüm verileri tutar:

[user@host~]$ uname -a
FreeBSD host.domain 7.2-RELEASE FreeBSD 7.2-RELEASE #0: \
  Fri May  1 07:18:07 UTC 2009                          \
  root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

[user@host ~]$ dmesg | grep ZFS
WARNING: ZFS is considered to be an experimental feature in FreeBSD.
ZFS filesystem version 6
ZFS storage pool version 6

[user@host ~]$ sudo zpool status
  pool: zpool01
 state: UNAVAIL
 scrub: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    zpool01     UNAVAIL      0     0     0  insufficient replicas
      raidz1    UNAVAIL      0     0     0  corrupted data
        da5     ONLINE       0     0     0
        da6     ONLINE       0     0     0
        da7     ONLINE       0     0     0
        da8     ONLINE       0     0     0
      raidz1    ONLINE       0     0     0
        da1     ONLINE       0     0     0
        da2     ONLINE       0     0     0
        da3     ONLINE       0     0     0
        da4     ONLINE       0     0     0

  pool: zpool02
 state: ONLINE
 scrub: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    zpool02     ONLINE       0     0     0
      raidz1    ONLINE       0     0     0
        da9     ONLINE       0     0     0
        da10    ONLINE       0     0     0
        da11    ONLINE       0     0     0
        da12    ONLINE       0     0     0

errors: No known data errors

Birkaç hafta önce havuza girebildim. O zamandan beri, ana makinenin donanımının hemen hemen tamamını değiştirmek ve birkaç ana bilgisayar işletim sistemi kurmak zorunda kaldım.

Şüphe ediyorum ki, bu işletim sistemi kurulumlarından birinin 500GB'lık sürücülerden birine (ya da her neyse) bir önyükleyici (ya da her neyse) yazması ve bazı zpool meta verilerini (ya da her neyse) imha etmesi - ya da her neyse, bunun çok belirsiz bir fikir olduğu anlamına gelir. ve bu konu tam olarak benim güçlü tarafım değil.


ZFS hakkında birçok web sitesi, blog, posta listesi vb. Var. Verilerimi geri almak için aklı başında, yapılandırılmış, kontrollü, bilgili, bilgili bir yaklaşım için yeterli bilgiyi toplamama yardımcı olacağı umuduyla bu soruyu burada yayınlarım - ve umarım aynı durumda başka birine yardım eder.


'Zfs recover' için arama yapıldığında ilk arama sonucu , Solaris ZFS Yönetim Kılavuzu'nun ZFS Sorun Giderme ve Veri Kurtarma bölümüdür. İlk ZFS Arıza Modları bölümünde 'Bozuk ZFS Verileri' paragrafında yazıyor:

Veri bozulması her zaman kalıcıdır ve onarım sırasında özel dikkat gerektirir. Temeldeki cihazlar tamir edilse veya değiştirilse bile, orijinal veriler sonsuza dek kaybolur.

Biraz bulaşık suyundan.

Ancak, ikinci google arama sonucu Max Bruning'in blogu ve orada okudum

Geçenlerde, 10TB ZFS havuzunda saklanan 15 yıllık video ve müzik olan birinin, bir elektrik kesintisinden sonra arızalandığı bir e-posta gönderildi. Maalesef yedeği yoktu. FreeBSD 7'de ZFS sürüm 6 kullanıyordu [...] Diskteki verileri incelemekle yaklaşık 1 hafta geçirdikten sonra, temelde hepsini geri yükleyebildim.

ve

ZFS verilerinizi kaybettiğinde, bundan şüpheliyim. Verilerinizin orada olduğundan şüpheleniyorum, ancak bunu elde etmenin doğru yolunu bulmanız gerekiyor.

(duymak istediğim bir şeye benziyor ...)

İlk adım : Sorun tam olarak nedir?

Zpool'un neden tam olarak bozuk olduğunu bildirdiğini nasıl teşhis edebilirim? Web’de hiçbir yerde Sun veya Oracle tarafından resmi olarak belgelenmemiş görünen zdb olduğunu görüyorum. Man sayfasından:

NAME
       zdb - ZFS debugger

SYNOPSIS
       zdb pool

DESCRIPTION
       The  zdb  command is used by support engineers to diagnose failures and
       gather statistics. Since the ZFS file system is  always  consistent  on
       disk  and is self-repairing, zdb should only be run under the direction
       by a support engineer.

       If no arguments are specified, zdb, performs basic  consistency  checks
       on  the pool and associated datasets, and report any problems detected.

       Any options supported by this command are internal to Sun  and  subject
       to change at any time.

Ayrıca, Ben Rockwood ayrıntılı bir makale yayınladı ve Max Bruning’in 28 Haziran 2008’de Prag’da düzenlenen Open Solaris Developer Conference’da (ve mdb) konuştuğu bir video var .

Kırık zpool'da zdb'yi root olarak çalıştırmak aşağıdaki çıktıyı verir:

[user@host ~]$ sudo zdb zpool01
    version=6
    name='zpool01'
    state=0
    txg=83216
    pool_guid=16471197341102820829
    hostid=3885370542
    hostname='host.domain'
    vdev_tree
        type='root'
        id=0
        guid=16471197341102820829
        children[0]
                type='raidz'
                id=0
                guid=48739167677596410
                nparity=1
                metaslab_array=14
                metaslab_shift=34
                ashift=9
                asize=2000412475392
                children[0]
                        type='disk'
                        id=0
                        guid=4795262086800816238
                        path='/dev/da5'
                        whole_disk=0
                        DTL=202
                children[1]
                        type='disk'
                        id=1
                        guid=16218262712375173260
                        path='/dev/da6'
                        whole_disk=0
                        DTL=201
                children[2]
                        type='disk'
                        id=2
                        guid=15597847700365748450
                        path='/dev/da7'
                        whole_disk=0
                        DTL=200
                children[3]
                        type='disk'
                        id=3
                        guid=9839399967725049819
                        path='/dev/da8'
                        whole_disk=0
                        DTL=199
        children[1]
                type='raidz'
                id=1
                guid=8910308849729789724
                nparity=1
                metaslab_array=119
                metaslab_shift=34
                ashift=9
                asize=2000412475392
                children[0]
                        type='disk'
                        id=0
                        guid=5438331695267373463
                        path='/dev/da1'
                        whole_disk=0
                        DTL=198
                children[1]
                        type='disk'
                        id=1
                        guid=2722163893739409369
                        path='/dev/da2'
                        whole_disk=0
                        DTL=197
                children[2]
                        type='disk'
                        id=2
                        guid=11729319950433483953
                        path='/dev/da3'
                        whole_disk=0
                        DTL=196
                children[3]
                        type='disk'
                        id=3
                        guid=7885201945644860203
                        path='/dev/da4'
                        whole_disk=0
                        DTL=195
zdb: can't open zpool01: Invalid argument

Sanırım sonunda 'geçersiz argüman' hatasının zpool01 aslında olmadığından ortaya çıkıyor: Çalışan zpool02 üzerinde oluşmuyor, ancak başka bir çıktı da görünmüyor.

Tamam, bu aşamada, makale çok uzun sürmeden önce bunu yayınlamak daha iyi olur.

Belki birisi bana buradan nasıl ilerleyeceğime dair bazı tavsiyeler verebilir ve bir cevap bekliyorum, videoyu izleyeceğim, yukarıdaki zdb çıktısının ayrıntılarına bakacağım, Bens makalesini okuyacağım ve ne olduğunu anlamaya çalışacağım. ne...


+ 1000 20110806-1600

01 Güncellemesi:

Sanırım temel sebebi buldum: Max Bruning, bir e-postayı çok hızlı bir şekilde yanıtlayarak nabzını tutmayı istedi zdb -lll. Havuzun 'iyi' raidz1 yarısındaki 4 sabit diskten herhangi birinde, çıktı yukarıda gönderdiklerime benzer. Ancak, 'kırık' yarıda bulunan 4 sürücünün ilk 3'ünde, etiket 2 ve 3 için zdbraporlar failed to unpack label. Havuzdaki dördüncü sürücü tamam görünüyor zdb, tüm etiketleri gösteriyor.

Google'ın bu hata mesajı bu yazı getiriyor . Bu gönderiye verilen ilk yanıttan:

ZFS ile, her fiziksel vdev'de 4 özdeş etiket, bu durumda tek bir sabit sürücü. Vdev'in başlangıcında L0 / L1 ve vdev'in sonunda L2 / L3.

Havuzdaki 8 sürücünün tümü aynı model Seagate Barracuda 500GB'dir . Ancak, havuza 4 sürücüyle başladığımı, sonra birisinin öldüğünü ve Seagate tarafından değiştirildiğini değiştirdiğimi hatırlıyorum. Daha sonra 4 sürücü daha ekledim. Bu nedenle, sürücü ve ürün yazılımı tanımlayıcıları farklıdır:

[user@host ~]$ dmesg | egrep '^da.*?: <'
da0:  <VMware, VMware Virtual S 1.0> Fixed Direct Access SCSI-2 device 
da1:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da2:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da3:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da4:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da5:  <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device 
da6:  <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device 
da7:  <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device 
da8:  <ATA ST3500418AS CC35> Fixed Direct Access SCSI-5 device 
da9:  <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 
da10: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 
da11: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 
da12: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 

Tüm sürücülerin aynı boyutta olmasına rağmen hatırlıyorum. Şimdi sürücülere bakıldığında, boyutların üçü için değiştiğini, 2 MB küçüldüğünü gösteriyor:

[user@host ~]$ dmesg | egrep '^da.*?: .*?MB '
da0:   10240MB (20971520  512 byte sectors: 255H 63S/T 1305C)
da1:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da2:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da3:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da4:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da5:  476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da6:  476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da7:  476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da8:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da9:  152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da10: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da11: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da12: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)

Bu nedenle, 'sürücülere bir önyükleyici yazdı' (daha önce tahmin ettiğim gibi) işletim sistemi kurulumlarından biri değildi, aslında 2 MB'lık bir ana bilgisayar oluşturan yeni bir anakarttı (bir ASUS P8P67 LE ). ZFS meta verilerimi bozan üç sürücünün sonunda koruma alanı .

Neden tüm sürücülerde bir HPA yaratmadı? Bunun nedeni, HPA oluşturma işleminin yalnızca Seagate sabit disk BIOS güncellemesiyle daha sonra giderilen bir hatayı içeren eski sürücülerde yapılmasıdır: Bu olay birkaç hafta önce başladığında, olup olmadığını kontrol etmek için Seagate'in SeaTools'unu çalıştırdım. sürücülerde fiziksel olarak yanlış bir şey varsa (hala eski donanımda) ve bazı sürücülerimin BIOS güncellemesine ihtiyacı olduğunu belirten bir mesaj aldım. Şu anda bu iletinin ayrıntılarını ve ürün yazılımı güncelleme indirmesinin bağlantısını yeniden oluşturmaya çalıştığım için, anakart HPA'yı oluşturduğundan beri, her iki SeaTools DOS sürümü de söz konusu sabit sürücüleri algılayamadı - hızlı invalid partitionya da benzer bir şey başladıklarında yanıp söner, işte bu. İronik olarak, yine de bir dizi Samsung sürücü buldular.

(Ağa bağlı olmayan bir sistemde bir FreeDOS kabuğuna takılmanın acı verici, zaman alıcı ve sonuçta verimsiz detaylarını atladım.) Sonunda, SeaTools Windows'u çalıştırmak için ayrı bir makineye Windows 7'yi kurdum. sürüm 1.2.0.5. DOS SeaTools ile ilgili son bir söz: Onları teker teker başlatmaya çalışırken zahmet etmeyin - bunun yerine, birkaç dakika yatırım yapın ve harika Ultimate Boot CD'si ile önyüklenebilir bir USB bellek yapın - DOS SeaTools'dan başka pek çok şey kullanışlı araçlar.

Başlatıldığında, Windows için SeaTools bu iletişim kutusunu açar:

SeaTools Firmware Güncelleme İletişim Kutusu

Bağlantılar, Seri Numarası Denetleyicisine (bir nedenle bir captcha - mine tarafından korunan 'İstilacı kullanıcılar'dı) ve ürün yazılımı güncellemesi hakkında bir bilgi bankası makalesine yol açar . Muhtemelen sabit sürücü modeline ve bazı indirmelere özel bağlantılar var, ne yok, ama şu an için bu yolu izlemeyeceğim:

Bölümleri kısaltılmış ve bozuk bir depolama havuzunun parçası olan bir seferde üç sürücünün donanım yazılımını güncellemeye acele etmeyeceğim. Bu sorun istiyor. Yeni başlayanlar için, ürün yazılımı güncellemesi büyük olasılıkla geri alınamaz - ve bu verilerimi geri alma şansımı geri dönülmez şekilde bozabilir.

Bu nedenle, daha sonra yapacağım ilk şey sürücüleri görüntülemektir ve kopyalarla çalışır, bu yüzden bir şeyler ters giderse geri dönecek bir orijinal var. Bu, ZFS muhtemelen sürücülerin değiştirildiğini fark edeceğinden (sürücü seri numarası veya başka bir UUID veya her neyse), aynı sabit sürücü modeline biraz kopyalanmasına rağmen muhtemelen ek bir karmaşıklığa neden olabilir. Üstelik zpool canlı bile değil. Evlat, bu zor olabilir.

Bununla birlikte, diğer seçenek, orijinallerle çalışmak ve yansıtılmış diskleri yedek olarak tutmak olacaktır, ancak daha sonra orijinallerde bir şeyler ters gittiğinde muhtemelen karmaşıklığa rastlayacağım. Naa, iyi değil.

Bozuk havuzda bulunan buggy BIOS'lu üç sürücü için görüntülü değiştirme işlevi görecek üç sabit sürücüyü temizlemek için, şu anda orada olan şeyler için bir miktar depolama alanı oluşturmam gerekiyor, bu yüzden şimdi derinlerde kazacağım. donanım kutusunu ve bazı eski sürücülerden geçici bir zpool toplayın - ZFS'nin değiştirilen dd'd sürücüleri ile nasıl başa çıkacağını test etmek için de kullanabilirim.

Bu biraz zaman alabilir...


+ 1100 20111213-1930

02 Güncellemesi:

Bu gerçekten biraz zaman aldı. Aylarca masamda çeşitli sabit disk yığınlarının takıldığı birkaç bilgisayar kasası açtım ve ayrıca birkaç gece kulak tıkacıyla uyudum, çünkü makineyi uzun bir kritik operasyon geçirdiği için yatmadan önce durduramadım. . Ancak, sonunda galip geldim! :-) Bu süreçte de çok şey öğrendim ve bu bilgiyi burada benzer durumdaki herkes için paylaşmak istiyorum.

Bu makalede, ZFS dosya sunucusu olan ve işlem yapmayan herkesin okumaya vakti olduğu için çok daha uzun, bu yüzden burada ayrıntılara girip aşağıda bulunan temel bulgularla bir cevap oluşturacağım.

Arızalı sürücülerin yansıtıldığı 500 GB'lık disklerden eşyalarını çıkarmak için yeterli depolama alanı oluşturmak için eski donanım kutusuna derin bir kazma yaptım. Ayrıca birkaç sabit sürücüyü USB kasalarından sökmek zorunda kaldım, bu yüzden onları SATA üzerinden doğrudan bağlayabiliyordum. İlgili, ilgisiz bazı sorunlar vardı ve eski sürücülerden bazıları, bir zpool'un değiştirilmesini gerektiren bir işlemi tekrar başlattığımda başarısız olmaya başladı, ancak bunu atlayacağım.

İpucu: Bir aşamada, buna dahil olan toplam yaklaşık 30 sabit disk vardı. Bu kadar donanımda, düzgün bir şekilde istiflenmeleri çok büyük bir yardımcıdır; masanızdan düşen kabloların gevşemesi ya da sabit sürücü kullanılması kesinlikle süreçte yardımcı olmaz ve veri bütünlüğünüze daha fazla zarar verebilir.

Birkaç dakika harcadım karton sabit disk armatürleri oluşturmak için harcadım;

telafi saklama alanının bir kısmı sadece bir demet vida artı biraz karton Fan tam olarak gerekli değil, yığın önceki bir projeden geliyor mesafe parçaları da gerekli değildir ...

İronik olarak, eski sürücüleri ilk defa bağladığımda, bazı eski sürümleriyle test etmek için yaratmam gereken eski bir zpool olduğunu fark ettim, ancak kaybolan tüm kişisel veriler değil biraz azaltılmış, bu da dosyaların ileri geri kaydırılması anlamına geliyordu.

Sonunda sorunlu sürücüleri yedek sürücülere yansıtdım, zpool için kullandım ve orjinallerinin bağlantısını kesti. Yedekleme sürücülerinde daha yeni bir ürün yazılımı bulunur, en azından SeaTools gerekli ürün yazılımı güncellemelerini rapor etmez. Bir cihazdan diğerine basit bir gg ile yansıtma yaptım, örneğin

sudo dd if=/dev/sda of=/dev/sde

ZFS'nin donanım değişikliğini fark ettiğine inanıyorum (bazı sabit sürücü UUID veya her neyse), ancak umursamıyor.

Bununla birlikte, zpool hala aynı durumda idi, kopyaları yetersiz / veri bozuk.

Daha önce bahsedilen HPA Wikipedia makalesinde belirtildiği gibi, bir Linux korumalı alanın varlığı Linux önyüklenirken ve hdparm kullanılarak incelenebilir . Bildiğim kadarıyla FreeBSD'de hdparm aracı yok, ancak bu zamana kadar, FreeBSD 8.2 ve Debian 6.0'ı çift önyükleme sistemi olarak kurdum, bu yüzden Linux'a başladım:

user@host:~$ for i in {a..l}; do sudo hdparm -N /dev/sd$i; done

   ...
/dev/sdd:
 max sectors   = 976773168/976773168, HPA is disabled
/dev/sde:
 max sectors   = 976771055/976773168, HPA is enabled
/dev/sdf:
 max sectors   = 976771055/976773168, HPA is enabled
/dev/sdg:
 max sectors   = 976771055/976773168, HPA is enabled
/dev/sdh:
 max sectors   = 976773168/976773168, HPA is disabled
   ...

Bu yüzden sorun açıkça yeni anakartın, sürücünün sonunda üst iki ZFS etiketini 'saklayan', yani ZFS'nin onları görmesini engelleyen birkaç megabaytlık bir HPA yaratmasıydı.


HPA ile uğraşmak tehlikeli bir iş gibi görünüyor. Hdparm man sayfasından -N parametresi:

Get/set max visible number of sectors, also known as the Host Protected Area setting.
  ...
To change the current max (VERY DANGEROUS, DATA LOSS IS EXTREMELY LIKELY), a new value
should be provided (in base10) immediately following the -N option.
This value is specified as a count of sectors, rather than the "max sector address"
of the drive. Drives have the concept of a temporary (volatile) setting which is lost on
the next hardware reset, as well as a more permanent (non-volatile) value which survives
resets and power cycles.  By default, -N affects only the temporary (volatile) setting.
To change the permanent (non-volatile) value, prepend a leading p character immediately
before the first digit of the value. Drives are supposed to allow only a single permanent
change per session. A hardware reset (or power cycle) is required before another
permanent -N operation can succeed.
  ...

Benim durumumda, HPA şöyle kaldırılır:

user@host:~$ sudo hdparm -Np976773168 /dev/sde

/dev/sde:
 setting max visible sectors to 976773168 (permanent)
 max sectors   = 976773168/976773168, HPA is disabled

HPA bulunan diğer sürücüler için de aynı şekilde. Yanlış sürücü veya belirlediğiniz boyut parametresiyle ilgili bir şey alırsanız, mantıklı değildir, hdparm aşağıdakileri anlamak için yeterince akıllıdır:

user@host:~$ sudo hdparm -Np976773168 /dev/sdx

/dev/sdx:
 setting max visible sectors to 976773168 (permanent)
Use of -Nnnnnn is VERY DANGEROUS.
You have requested reducing the apparent size of the drive.
This is a BAD idea, and can easily destroy all of the drive's contents.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.

Ondan sonra, zpool'un başlangıçta yaratıldığı FreeBSD 7.2 sanal makinesini yeniden başlattım ve zpool durumu tekrar bir çalışma havuzu bildirdi. YUPPİ! :-)

Havuzu sanal sisteme ihraç ettim ve onu ana bilgisayar FreeBSD 8.2 sistemine tekrar aktardım.

Bazı daha büyük donanım yükseltmeleri, başka bir anakart takası, ZFS 4 / 15'e yönelik bir ZFS havuzu güncellemesi, kapsamlı bir ovma ve şimdi zpool'um 8x1 TB artı 8x500GB raidz2 bölümlerinden oluşuyor:

[user@host ~]$ sudo zpool status
  pool: zpool
 state: ONLINE
 scrub: none requested
config:

NAME        STATE     READ WRITE CKSUM
zpool       ONLINE       0     0     0
  raidz2    ONLINE       0     0     0
    ad0     ONLINE       0     0     0
    ad1     ONLINE       0     0     0
    ad2     ONLINE       0     0     0
    ad3     ONLINE       0     0     0
    ad8     ONLINE       0     0     0
    ad10    ONLINE       0     0     0
    ad14    ONLINE       0     0     0
    ad16    ONLINE       0     0     0
  raidz2    ONLINE       0     0     0
    da0     ONLINE       0     0     0
    da1     ONLINE       0     0     0
    da2     ONLINE       0     0     0
    da3     ONLINE       0     0     0
    da4     ONLINE       0     0     0
    da5     ONLINE       0     0     0
    da6     ONLINE       0     0     0
    da7     ONLINE       0     0     0

errors: No known data errors

[user@host ~]$ df -h
Filesystem         Size    Used   Avail Capacity  Mounted on
/dev/label/root     29G     13G     14G    49%    /
devfs              1.0K    1.0K      0B   100%    /dev
zpool              8.0T    3.6T    4.5T    44%    /mnt/zpool

Son söz olarak, bana öyle geliyor ki ZFS havuzları öldürmek çok ama çok zor. Bu sistemi yaratan Sun'ın adamları, dosya sistemlerinde son söz olarak adlandırılan tüm nedenlere sahipler. Saygı!


2
Bir şey yapmadan önce, bu sürücüleri resmet! Daha da kötüye gitmesi ihtimaline karşı 'bozulmuş' verilerinizin yedeğini alın.
MikeyB

evet, bu çok iyi bir nokta! ve bu makaleyi henüz ilerleme kaydetmeme rağmen güncellememişti - hala yedek sabit diskleri
silmekle

Yanıtlar:


24

Sorun, yeni anakartın BIOS'unun bazı sürücülerde ana bilgisayar korumalı bir alan (HPA) yaratmasıydı; OEM'lerin genellikle sabit sürücünün sonunda bulunan sistem kurtarma amacıyla kullanılan küçük bir bölümü.

ZFS, bölüm meta bilgisine sahip 4 etiket bulundurur ve HPA, ZFS'nin üst ikisini görmesini önler.

Çözüm: Linux'u başlatın, HPA'yı incelemek ve kaldırmak için hdparm kullanın. Çok dikkatli olun, bu kolayca verilerinizi kolayca imha edebilir. Ayrıntılar için makaleye ve hdparm kılavuz sayfasına (parametre -N) bakın.

Sorun sadece yeni anakartta meydana gelmedi, sürücüleri bir SAS denetleyici kartına bağlarken de benzer bir sorunla karşılaştım. Çözüm aynı.


5

Yapmanızı tavsiye edeceğim ilk şey, biraz daha fazla sabit sürücü edinmek ve bu verilerle sahip olduğunuz 8 sürücünün kopyalarını bu ddkomutu kullanarak kopyalamak . Bu şekilde, onları kurtarma girişimlerinizde işleri daha da kötüleştirirseniz, hala bu temel çizgiye geri dönebilirsiniz.

Bunu daha önce yaptık ve bunu gerek yoktu zamanlar oldu, ama ben kere yaptım ihtiyacını bu çabaya tamamen buna değer yaptı.

Net olmadan çalışmayın.


Aslında öneriyoruz ddrescueüzerinde dd. Sürücüler mükemmel bir şekilde çalıştığında gerçekten çok farklı çalışmıyor (ancak size iyi bir ilerleme göstergesi veriyor) ancak sorunlu sektörler veya bunun gibi bir şey varsa, kurtarma aracı bu durumu dd'den daha iyi ele alır (veya ben söylendi).
CVn

2

Bunu çözme yolunda gibisin. Başka, daha yeni bir bakış açısı istiyorsanız, Solaris 11 Express canlı CD'sini deneyebilirsiniz. Orada çalışan çok daha yeni bir kod var (Solaris'teki zpool şu anda sürüm 31'de, oysa sürüm 6'dasınız) ve daha iyi kurtarma olanakları sunabilir. Kaçma zpool upgradeEğer FreeBSD altında havuz monte tutmak istiyorsanız olsa Solaris altında.


Bahşiş için teşekkürler! :-) Bu ZFS işine başladığımda 2009 yılında OpenSolaris'e bakıyorum, ama ne yazık ki kullandığım denetleyicileri desteklemiyordu - sonuçta bu tüketici sınıfı bir donanım. Kısa süre önce OpenIndiana'ya da baktım ancak durumun değişip değişmediğinden emin değilim. Denetleyicileri bir aşamada SAS'a yükseltebilir ve o zaman geçirmeyi düşünebilirim.
ssc

Bence OpenIndiana yeni bir bakıma değebilir. Başka bir şey değilse, Oracle'dan daha ucuz "donanım" dostu olabilirler ... Canlı CD'yi önerdim çünkü denemesi kolay - bir VM'de de çalıştırabilirsiniz.
Jakob Borg

1

FreeBSD posta listeleri aramanız için iyi bir başlangıç ​​noktası olabilir. FreeBSD-Stable ve -Current'da benzer isteklerin olduğunu hatırladım. Verilerinizin önemine bağlı olarak, erişilemeyen veri depolama havuzlarına müdahale etmek işlerin daha da kötüleşmesi için iyi bir şans taşıdığı için profesyonel bir kurtarma firması ile iletişime geçmek isteyebilirsiniz.


1

FreeBSD 10.3'ten 11.1'e yükselttikten sonra da benzer bir sorunla karşılaştım, daha sonra zpool hatalıydı ve zdb -llldört etiketin de geçerli olmasına rağmen verileri kurtarmanın bir yolu yoktu .

Güncellemenin bir şekilde Intel depolama yönetimi sürücülerini disklerden yumuşak bir yansıtma oluşturmaya (belki de etkinleştirildi ancak geomgüncelleme sonrasında Intel sağlayıcısı tarafından desteklenmedi mi?) Ve ZFS'nin diskleri takmasını engellemesine neden oldu .

Onları Intel RST önyükleme zamanı bellenimi etkinleştirilmiş ve softraid'i devre dışı bırakarak başka bir bilgisayara bağlama ( çok önemli: softraid'i kırmanın iki yolu vardır , varsayılanı diskleri başlatır (aka biçimleri!). verilere dokunmadan devre dışı bırakın) sonra ZFS'nin aynada ilk diski tanımasını sağlayın, ancak yaptığım hiçbir şey kalan diskleri makinenin ön-güncellemesindeki ile aynı olarak tanımlamasına izin vermedi. Neyse ki yansıtılmış bir zpool'du ve sadece diskleri ayırıp havuza tekrar takabildim ve çözümleyici olay olmadan tamamlandı.

Yan not: Benim durumumda hdparm(canlı bir Ubuntu Sunucusu ISO'dan çalışan), HBA'nın tüm disklerde devre dışı bırakıldığını ve yardım edemediğini bildirdi.


-2

bu tür bir bölümleme sorunu olsaydı, sürücü bölümlerini + MBR'yi kullanırdım ve bölümü doğru boyuta getirirdim ...

bölümleme tablosu oluşturma veya değiştirme, bir bölümü biçimlendirmezseniz, hiçbir şey etkilemez (bu şekilde geri alabilirsiniz!), biçimlendirme olmadığı sürece, verilerin çoğu hala oradadır / yeni bölüm eklenmişse erişilebilir sürücünün sonunda bozuk dosyalara sahip olabilirsiniz, burada yeni şeyler yazıldığı için zordu. Bu nedenle, biçimlendirene kadar bu numara için tek iyi nedeniniz (yeni mbr, dosya tablosu vb.)

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.