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:
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;
İ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ı!