Hızlı cevap: ZFS havuzu import olmuyorsa ilk kural diskleri bozmamaktır. Önce her üyenin salt okunur bir sektör imajını alın (ddrescue), sonra kurtarmayı imaj kopyaları üzerinde deneyin. ZFS her yazmayı bir işlem grubuna (txg) bağlar ve her vdev etiketinde 128 girişlik bir uberblock halkası tutar, bu yüzden son birkaç txg bozulsa bile zpool import -F veya -T <txg> ile tutarlı eski bir noktaya geri sarılabilir. Havuz hâlâ gelmezse zpool import -o readonly=on ve zdb ile derin inceleme yapılır. RAIDZ dizisinde kayıp disk sayısı parite seviyesini aşmışsa (RAIDZ1 için iki, RAIDZ2 için üç) veya yanlış resilver üzerine yazmışsa havuz gerçekten kaybolur.

ZFS, bütünlük garantileri en güçlü dosya sistemlerinden biridir. Kopyala yaz (copy on write) mimarisi, uçtan uca sağlama toplamı ve işlem grubu modeli sayesinde normalde çökme sonrası bile tutarlı kalır. Fakat aynı özellikler bir havuz gerçekten bozulduğunda kurtarmayı klasik dosya sistemlerinden farklı kılar. Bu rehber, bir TrueNAS, Proxmox veya Linux sunucudaki ZFS havuzunun neden import olmadığını, hangi iç yapıların kurtarmayı mümkün kıldığını ve hangi müdahalelerin durumu geri dönülmez biçimde kötüleştirdiğini uzman seviyede anlatır.

Önce dur: her müdahale havuzu değiştirebilir

ZFS kurtarmasında en pahalı hatalar ilk saatlerde yapılır. zpool import -f, zpool clear, disk değiştirme ve resilver komutları havuza yazar. Bozuk bir havuzda yazma, kurtarılabilir eski bir txg durumunun üzerine yeni meta veri yazarak geri sarma penceresini kapatabilir.

Doğru sıra şudur. Önce tüm havuz üyelerini salt okunur bağlayın veya fiziksel olarak çıkarıp bir kurtarma tezgahına alın. Her diskin tam sektör imajını alın; arızalı veya tıkırtı yapan diskler için bu iş donanım görüntüleyici gerektirir ve arızalı diskten imaj alma rehberimizde ile ham sektör kopyalama yazımızda anlattığımız yöntem izlenir. Tüm kurtarma denemeleri bu imaj kopyaları üzerinde yapılır, orijinal diskler kasaya kaldırılır. Bu, hem bir delil zinciri ihtiyacı için hem de başarısız bir denemeden sonra baştan başlayabilmek için şarttır.

ZFS disk üzerinde nasıl durur

Kurtarma kararlarını anlamak için dört yapıyı bilmek gerekir.

Vdev etiketleri. Her fiziksel aygıtın başında iki, sonunda iki olmak üzere dört kopya etiket bulunur. Etiket, havuz adını, GUID değerlerini, vdev ağaç yapısını ve uberblock halkasını taşır. Dört kopyanın varlığı, bir disk baş veya son bölgesi hasar görse bile yapılandırmanın okunabilmesini sağlar.

Uberblock halkası. Her etiket, dairesel bir tampon içinde 128 uberblock saklar. Uberblock, havuzun o andaki kök blok işaretçisini (MOS, yani meta nesne kümesi kökü) ve işlem grubu numarasını (txg) tutar. ZFS her txg tamamlandığında bir sonraki yuvaya yeni bir uberblock yazar. Böylece diskte son 128 tutarlı duruma kadar bir geçmiş kalır.

İşlem grupları (txg). ZFS yazmaları tek tek değil, saniyeler içinde biriken gruplar halinde atomik olarak işler. Bir txg ya tamamen yazılır ya da hiç. Bu model, güç kaybında yarım kalmış bir duruma düşmeyi engeller ve kurtarmada geri sarılacak doğal noktaları verir.

Kopyala yaz ağacı. Hiçbir blok yerinde değiştirilmez. Değişen her blok yeni bir konuma yazılır ve üstteki işaretçiler yukarı doğru yeni bloklara güncellenir. Bu yüzden eski meta veri çoğu zaman diskte bir süre daha durur ve geri sarma işe yarar.

Havuz neden import olmuyor: belirtiye göre yol

Belirti Olası neden İlk yaklaşım
cannot import: no such pool etiketler okunamıyor, disk sırası veya yolu değişti zpool import -d /dev/by-id ile tarama, imajları by-id ile sunma
one or more devices is currently unavailable üye disk eksik veya arızalı eksik diski imajdan sunun, RAIDZ ise degraded import deneyin
pool was previously in use from another system farklı hostid, temiz export yapılmamış zpool import -f yerine önce salt okunur deneyin
import donuyor veya SUSPENDED son txg bozuk, meta veri hatası zpool import -F ile son txg geri sarma
insufficient replicas kayıp disk parite seviyesini aştı her üyeyi imajla, zayıf diskleri kurtarıp yeniden deneyin
mount sonrası I/O hatası, panik derin meta veri bozulması readonly=on ile import, zdb ile çözümleme

txg geri sarma: kademeli ve güvenli yol

Son yazılan birkaç işlem grubu bozulduysa (tipik olarak ani güç kaybı, kontrolcü hatası veya yarım yazma sonrası) çözüm en son tutarlı txg değerine geri sarmaktır. Kademeli ilerleyin.

Önce zarar vermeyen bir deneme: salt okunur import. Bu, hiçbir şey yazmadan havuzu ve veriyi görünür kılarsa veriyi hemen başka bir hedefe kopyalayabilirsiniz.

zpool import -o readonly=on -d /dev/by-id <havuz>

Bu çalışmazsa sıradaki adım kurtarma modunda import denemesidir. -F, ZFS'in son birkaç txg değerini atıp bulabildiği en son tutarlı uberblock ile gelmesini ister. -n ile önce kuru deneme yapıp ne kadar veri kaybı olacağını görün.

zpool import -F -n <havuz>      # kuru deneme, sadece raporlar
zpool import -F <havuz>          # gerçek geri sarma

Daha agresif gerekiyorsa -X olağan dışı derin geri sarmayı açar (daha çok txg atılabilir) ve belirli bir hedef txg biliniyorsa -T <txg> ile o noktaya gidilir. Hangi txg değerlerinin diskte olduğunu zdb ile görürsünüz.

zdb -l /dev/by-id/<uye-disk>     # vdev etiketleri ve uberblock txg aralığı
zdb -ul /dev/by-id/<uye-disk>    # uberblock halkasındaki tüm girişler ve txg
zpool import -FX -T <txg> <havuz>

Önemli uyarı: -F, -X ve -T havuza yazar. Bu yüzden bu komutları yalnızca imaj kopyaları üzerinde, orijinal diskler güvende iken çalıştırın.

RAIDZ mantığı ve yeniden oluşturma

RAIDZ, donanım RAID 5 ve 6 ile aynı parite fikrini kullanır ama ZFS içinde yazılım olarak, değişken genişlikli şeritlerle ve blok başına sağlama toplamıyla uygulanır. RAIDZ1 bir disk, RAIDZ2 iki disk, RAIDZ3 üç disk kaybına dayanır.

Bir RAIDZ dizisi çöktüğünde karar, kaç üyenin gerçekten kayıp veya okunamaz olduğuna bağlıdır. Parite seviyesi içindeyseniz eksik veri pariteden yeniden hesaplanabilir. Parite seviyesini bir disk aşarsanız (RAIDZ1'de iki arızalı disk gibi) havuz veriyi tam olarak yeniden kuramaz. Bu durumda tek şans, zayıf diskleri donanım görüntüleyici ile olabildiğince kurtarıp (kötü sektörleri azaltıp) sonra havuzu degraded olarak import etmeyi denemektir. Parite ve sağlama toplamı sayesinde ZFS, kısmen okunabilen disklerden bile şaşırtıcı miktarda doğru veri geri getirebilir. Donanım RAID tarafındaki genel yaklaşımı ayrıca RAID 5 ve 6 dizi yeniden oluşturma yazımızda ele aldık.

En tehlikeli hata, parite seviyesi aşıldığında diskleri değiştirip resilver başlatmaktır. Resilver, kalan disklere yazar ve kurtarılabilir eski durumu yok edebilir. Çöken bir dizide önce imaj, sonra teşhis, en son yazma kuralı mutlaktır.

zdb ile derin inceleme ve veriyi dışarı taşıma

zdb, ZFS'in hata ayıklama aracıdır ve kurtarmada havuzu yazmadan çözümlemek için kullanılır. Havuz yapısını, veri kümelerini, spacemap tutarlılığını ve belirli blok işaretçilerini okuyabilir.

zdb -e -p /imaj/dizini <havuz>        # export edilmiş havuzu imajlardan incele
zdb -e -bcsvL <havuz>                 # blok sayımı ve tutarlılık taraması
zdb -e -d <havuz>                     # veri kümelerini ve nesne sayılarını listele

Havuz salt okunur import olur olmaz hedef tek şey, veriyi tamamen ayrı ve sağlam bir depoya kopyalamaktır. Snapshot varsa zfs send ile tutarlı bir akış almak en güvenli yoldur. Havuz mount edilemiyor ama zdb nesneleri görebiliyorsa, uzman laboratuvar ortamında nesne düzeyinde çıkarım yapılır. Kurumsal ortamlarda bu kurtarmanın hemen ardından yedekleme ve felaket kurtarma planı gözden geçirilmelidir; konuyu iş sürekliliği ve felaket kurtarma yazımızda ve kurumsal yedekten dönüş yazımızda inceledik.

Havuz gerçekten ne zaman kaybolur

Dürüst olmak gerekir: ZFS her şeyi kurtaramaz. Şu durumlarda veri kalıcı olarak kaybolur. Parite seviyesini aşan sayıda disk fiziksel olarak okunamıyorsa ve donanım kurtarması da başarısızsa yeniden oluşturacak yeterli veri yoktur. zpool destroy sonrası havuza yeni veri yazıldıysa eski meta veri üzerine binmiş olabilir. Yanlış bir resilver veya format kurtarılabilir txg geçmişini sildiyse geri sarılacak nokta kalmaz. SSD tabanlı bir havuzda TRIM, silinen blokları fiziksel olarak boşalttıysa o bloklar geri gelmez; bu mekanizmayı SSD TRIM ve FTL yazımızda ayrıntılandırdık. Bu sınırları baştan kabul etmek, boşa emek ve yanlış umut harcamamak için önemlidir.

DSET yaklaşımı

DSET olarak ZFS ve RAIDZ kurtarmalarını Ankara Hacettepe Teknokent bünyesindeki laboratuvarımızda, önce imaj alma ilkesiyle yürütürüz. Her havuz üyesinin salt okunur sektör imajı alınır, orijinal diskler delil güvenliğiyle saklanır, tüm geri sarma ve zdb çözümlemesi imaj kopyaları üzerinde yapılır. Zayıf veya tıkırtılı diskler için donanım görüntüleyici kullanırız; konuya PC-3000 laboratuvar donanımı yazımızda değindik. Kurtarmanın mümkün olup olmadığını kuru denemelerle önden görür, abartılı söz vermeyiz. Bir TrueNAS, Proxmox veya Linux ZFS havuzu import olmuyorsa havuza hiçbir yazma komutu çalıştırmadan DSET ile iletişime geçin. Linux sunucu dosya sistemleri için ext4, Btrfs ve LVM kurtarma yazımız ve kurumsal NAS için QNAP NAS kurtarma yazımız da yol gösterir.

Sık sorulan sorular

zpool import -f ile -F arasındaki fark nedir? -f yalnızca farklı bir sistemden gelen veya temiz export edilmemiş bir havuzu zorla import eder, veri yapısını değiştirmez ama havuza host bilgisi yazar. -F ise kurtarma modudur: son birkaç bozuk txg değerini atar ve bulabildiği en son tutarlı duruma geri sarar, bu da küçük bir veri kaybı anlamına gelebilir. Önce -F -n kuru denemesiyle ne kaybedileceğini görmek doğrudur.

RAIDZ2 dizimde iki disk arızalandı, veri gitti mi? Hayır, RAIDZ2 iki disk kaybına dayanacak şekilde iki parite tutar, yani iki diskle havuz hâlâ gelmelidir. Üçüncü bir disk de arızalanır veya kalan disklerde çok sayıda okunamaz sektör olursa sorun başlar. Bu noktada doğru hamle resilver değil, zayıf diskleri donanım görüntüleyici ile imajlayıp degraded import denemektir.

Havuza hiç dokunmadan veriyi kurtarabilir misiniz? Çoğu durumda evet. Hedefimiz havuza mümkün olduğunca az, tercihen hiç yazmamaktır. Salt okunur import ve imaj kopyaları üzerinde çalışma sayesinde veriyi, orijinal diskleri değiştirmeden ayrı bir hedefe taşırız. Bu hem veri güvenliği hem de olası bir dava için delil bütünlüğü açısından en doğru yöntemdir.

Kaynaklar