Kurumsal depolama sistemleri çöktüğünde mesele tek bir diskin arızasından çok daha büyüktür. Bir ZFS havuzu faulted duruma düştüğünde, bir Windows Storage Spaces sanal diski detached olarak işaretlendiğinde ya da bir SAN üzerindeki LUN yanlışlıkla yeniden başlatıldığında, kaybolan şey sadece bloklar değildir. Şirketin muhasebe veritabanı, sanallaştırma datastore'ları, e-posta sunucusunun mailbox dosyaları ve yıllarca biriken belgeler aynı anda erişilemez hale gelir. Bu yüzden kurumsal depolama veri kurtarma, tek disk kurtarmadan tamamen farklı bir disiplindir. Burada hata yapma payı çok düşüktür ve yanlış bir komut, kurtarılabilir bir durumu kalıcı veri kaybına çevirebilir.

DSET olarak 2003'ten beri Ankara Hacettepe Teknokent'ten kurumsal müşterilere hizmet veriyoruz. ZFS havuzları, Storage Spaces alanları, fiber kanal ve iSCSI ile bağlı SAN dizileri, NAS üniteleri ve sanallaştırma altyapıları üzerinde çalıştık. Yıllar içinde gördüğümüz en yıkıcı senaryolar neredeyse her zaman aynı kalıbı takip ediyor: bir disk arızalanıyor, sistem yöneticisi paniğe kapılıyor, hızlı bir onarım, rebuild ya da resilver başlatıyor ve bu işlem zaten yorgun olan diğer diskleri de öldürerek diziyi tamamen çökertiyor. Bu yazının amacı, bu tuzakları teknik derinlikle anlatmak ve neden kurumsal dizilerde her zaman önce imaj alınması gerektiğini ortaya koymaktır.

Aşağıdaki bölümlerde ZFS havuz mimarisinin neden bu kadar hassas olduğunu, Storage Spaces'in parity ve mirror düzenlerinde nelerin ters gidebileceğini, SAN LUN bozulması ve yeniden başlatma kazalarını, iSCSI hedef sorunlarını ve en önemlisi imaj-öncelikli kurtarma metodolojisini ele alacağız. Amaç, kurumsal bir depolama olayında ilk müdahaleyi yapan kişinin doğru kararı vermesini sağlamaktır.

Hızlı Cevap

Kurumsal bir depolama dizisi (ZFS, Storage Spaces, SAN veya iSCSI) çöktüğünde yapılması gereken ilk ve en önemli şey, yazma işlemlerini durdurmak ve hiçbir onarım, rebuild ya da resilver başlatmamaktır. Diziyi salt-okunur duruma alın, üye diskleri fiziksel sırasıyla etiketleyin ve profesyonel kurtarma için her diskin bire bir sektör imajını almasını bekleyin. ZFS havuzlarında zpool clear, zpool scrub veya force import gibi komutlar bozuk metadata üzerinde çalıştırıldığında kurtarılabilir veriyi kalıcı olarak silebilir. Storage Spaces'te detached bir sanal diski yeniden bağlamaya zorlamak parity bilgisini bozabilir. SAN tarafında yanlışlıkla initialize edilen bir LUN'un üzerine kurtarma denemesi yapmak yeni yazmalar üretir. Tüm bu durumlarda doğru yaklaşım aynıdır: dur, imajla, sonra imaj kopyaları üzerinde çalış. Orijinal disklere asla dokunma.

ZFS Havuz Mimarisi ve Neden Bu Kadar Kırılgan Görünür

ZFS, copy-on-write bir dosya sistemi ve volume yöneticisidir. Veriyi vdev (virtual device) adı verilen yapı taşları üzerine yazar ve bu vdev'ler bir araya gelerek havuzu (pool) oluşturur. Bir vdev mirror, raidz1, raidz2 veya raidz3 olabilir. Havuzun bütünlüğü tüm vdev'lerin sağlığına bağlıdır: tek bir vdev kalıcı olarak kaybolursa, o vdev tek başına yedeksiz olduğu için havuzun tamamı faulted duruma düşer. Bu, ZFS hakkında en çok yanlış anlaşılan noktadır. İnsanlar raidz2'nin iki disk arızasına dayanabileceğini bilir ama bu tolerans her vdev içinde geçerlidir, vdev'ler arasında değil.

ZFS her bloğu bir checksum ile korur ve metadata'nın çoklu kopyasını tutar. Havuzun durumu uberblock adı verilen bir yapı tarafından yönetilir. Her diskte uberblock'un birden fazla geçmiş kopyası bir döngüsel dizide saklanır. Sistem normalde en güncel ve tutarlı uberblock'u kullanır. Diskler aniden kesildiğinde ya da bir güç kaybı yarım kalan bir transaction group'u (TXG) bıraktığında, en son uberblock tutarsız olabilir. Sağlıklı bir senaryoda ZFS bir önceki tutarlı TXG'ye geri döner. Ancak metadata ağacının üst seviyeleri zarar gördüğünde, havuz import edilemez hale gelir ve cannot import: I/O error veya one or more devices is currently unavailable gibi mesajlarla karşılaşırsınız.

Degraded ve faulted ayrımı kritiktir. Degraded bir havuz hâlâ çevrimiçidir ve veriye erişilebilir, sadece bir veya daha fazla vdev azalmış redundancy ile çalışmaktadır. Faulted havuz ise erişilemez durumdadır. Bir sistem yöneticisinin yapabileceği en tehlikeli şey, faulted bir havuzu hemen geri getirmeye çalışmaktır. zpool import -F ile force import, ZFS'in son birkaç TXG'yi geri sararak tutarlı bir noktaya dönmesini sağlar; bazen işe yarar ama altta yatan disk bütünlüğü zaten bozuksa bu işlem yeni yazmalar üretir ve durumu kötüleştirir. İmaj almadan force import denemek, kumar oynamaktır.

ZFS havuzlarında veri kurtarmanın doğru yolu, havuzu oluşturan tüm fiziksel disklerin imajını almak, ardından bu imajları salt-okunur olarak bir kurtarma ortamına bağlamak ve havuzu read-only modda (zpool import -o readonly=on) ya da imaj kopyaları üzerinde okuma yaparak çözümlemektir. Eksik bir disk varsa, raidz redundancy matematiği kullanılarak eksik veri yeniden oluşturulabilir, ancak bu hesaplama orijinal disklere değil imajlara karşı yapılır. Linux tarafındaki diğer dosya sistemleriyle ilgili daha fazla teknik detay için Linux sunucu veri kurtarma rehberimize bakabilirsiniz.

ZFS'te Eksik Cihazlar, Bozuk Metadata ve Uberblock Sorunları

Bir ZFS havuzu import edilemediğinde ilk soru, sorunun fiziksel mi yoksa mantıksal mı olduğudur. Fiziksel sorunlarda bir veya daha fazla disk tamamen kayıptır ya da read hatası veriyor. zpool status çıktısı UNAVAIL veya REMOVED durumundaki cihazları gösterir. Burada en yaygın hata, eksik diski yeniden takıp sistemin onu yeniden senkronize etmesine izin vermektir. Eğer diğer diskler de marjinal durumda ise, başlayan resilver işlemi onları da yorar ve havuz tamamen çöker.

Mantıksal sorunlar daha sinsidir. Yarım kalan bir TXG, bozulmuş bir space map ya da zarar görmüş bir MOS (Meta Object Set) havuzu açılamaz hale getirebilir. ZFS'in geriye doğru uberblock döndürme yeteneği güçlüdür ama her zaman yeterli değildir. Bazı durumlarda doğru uberblock seçilse bile, o uberblock'un işaret ettiği metadata blokları başka bir nedenle zarar görmüş olabilir. Bu noktada zdb (ZFS Debugger) ile havuzun yapısını salt-okunur olarak incelemek gerekir. zdb -e -bcsvL gibi komutlar havuzu mount etmeden bütünlük taraması yapar ve hangi nesnelerin okunabilir olduğunu gösterir.

Burada altını çizmemiz gereken kritik nokta şudur: agresif onarımlar tehlikelidir. zpool clear komutu, hata sayaçlarını sıfırlar ve bazen ZFS'i sorunlu cihazları tekrar kullanmaya zorlar. Eğer bir cihaz aslında bozuk veri döndürüyorsa, clear sonrası ZFS o veriyi geçerli kabul edip checksum koruması altında yeniden yazabilir; bu, sessiz veri bozulmasının üzerine yazmak demektir. Benzer şekilde, faulted bir havuzda scrub başlatmak, hâlâ zayıf olan diskleri uzun bir okuma maratonuna sokar ve bu süreçte ikinci bir disk arızası havuzu kurtarılamaz hale getirebilir.

Doğru metodoloji, orijinal disklere hiç yazmadan çalışmaktır. Her diskin imajı alındıktan sonra, kurtarma uzmanı imaj kopyaları üzerinde farklı uberblock'ları deneyebilir, farklı TXG noktalarına geri dönebilir ve hangi senaryonun en fazla tutarlı veri verdiğini güvenle test edebilir. Bir imaj denemesi başarısız olursa, başka bir kopya alınır ve baştan başlanır. Orijinal disk korunduğu sürece sonsuz sayıda deneme yapma hakkı vardır. Bu, ZFS kurtarmanın temel felsefesidir.

Windows Storage Spaces: Parity, Mirror ve Detached Sanal Diskler

Windows Storage Spaces, fiziksel diskleri bir storage pool içinde toplayıp üzerinde sanal diskler (virtual disk veya storage space) oluşturan bir soyutlama katmanıdır. Bir storage space üç resiliency tipinden biriyle yapılandırılabilir: simple (redundancy yok, performans odaklı), mirror (iki ya da üç yönlü kopya) ve parity (RAID 5 benzeri, alan verimli ama yazma performansı düşük). Storage Spaces verileri slab adı verilen bloklar halinde fiziksel disklere dağıtır ve bu eşleme metadata pool içinde tutulur.

Kurumsal ortamlarda en sık karşılaştığımız Storage Spaces sorunu, sanal diskin detached duruma düşmesidir. Bu durum genellikle pool'daki yeterli sayıda fiziksel disk çevrimdışı olduğunda meydana gelir. Örneğin iki yönlü mirror bir alanda her iki kopyayı barındıran diskler kaybolursa ya da parity bir alanda tolerans sınırının üzerinde disk arızalanırsa, Windows sanal diski detached olarak işaretler ve veri erişilemez hale gelir. Daha incelikli bir senaryo, disklerin aslında sağlam olması ama bir denetleyici, kablo ya da backplane sorunu nedeniyle geçici olarak görünmez olmasıdır. Bu durumda diskler geri geldiğinde sanal disk hâlâ detached kalabilir çünkü pool metadata tutarsız bir durumda donmuştur.

Parity alanlarda durum daha karmaşıktır çünkü Storage Spaces parity, klasik donanım RAID 5'ten farklı çalışır. Slab'lar ve parity bilgisi diskler arasında Windows'a özgü bir düzende dağıtılır ve bir disk eksik olduğunda eksik slab'ların yeniden oluşturulması Windows'un kendi algoritmasına göre yapılır. Eksik bir diski yerine koyup pool'u yeniden onarmaya zorlamak (repair-virtualdisk), eğer diğer diskler marjinal durumda ise tehlikelidir. Repair işlemi pool genelinde yoğun okuma ve yazma üretir ve bu yük altında ikinci bir disk arızalanırsa parity alan kurtarılamaz hale gelir.

Detached bir sanal diski PowerShell ile zorla bağlamaya çalışmak (Connect-VirtualDisk ya da read-write attach), metadata zaten tutarsızsa pool yapısına yeni yazmalar yapar ve durumu kötüleştirebilir. Doğru yaklaşım yine aynıdır: pool'a ait tüm fiziksel disklerin imajını al, imajlar üzerinde Storage Spaces metadata yapısını çözümle, slab eşlemesini yeniden kur ve verileri imaj kopyalarından çıkar. Storage Spaces'in slab tabanlı yapısı karmaşık olduğu için bu çözümleme uzmanlık gerektirir. Genel sunucu kurtarma senaryoları için sunucu veri kurtarma sayfamız sürecin nasıl işlediğini anlatır.

SAN LUN Bozulması ve Yanlışlıkla Yeniden Başlatma Kazaları

SAN (Storage Area Network) dizileri, kurumsal altyapının kalbidir. Birden fazla fiziksel disk, dizinin denetleyicisi tarafından RAID gruplarına (ya da modern dizilerde storage pool'lara) toplanır ve bu havuzlardan LUN (Logical Unit Number) adı verilen mantıksal birimler oyularak sunuculara fiber kanal ya da iSCSI üzerinden sunulur. Sunucu tarafında bir LUN, sıradan bir blok aygıtı gibi görünür ve üzerine NTFS, VMFS, ext4 ya da başka bir dosya sistemi yazılır. Bu çok katmanlı yapı, SAN kurtarmayı özellikle zorlaştırır çünkü sorun dizinin RAID seviyesinde, LUN haritalama seviyesinde ya da dosya sistemi seviyesinde olabilir.

En yıkıcı SAN kazalarından biri yanlışlıkla yapılan LUN initialize veya reinitialize işlemidir. Bir yönetici dizinin yönetim arayüzünde yanlış LUN'u seçip onu yeniden başlattığında ya da format ettiğinde, dizi o LUN'a ait haritalama tablosunu sıfırlar. İlginç olan, çoğu durumda altta yatan veri bloklarının fiziksel disklerde hâlâ duruyor olmasıdır; sadece LUN'un nerede başladığını ve nasıl haritalandığını anlatan metadata silinmiştir. Bu, kurtarma için bir umut penceresi yaratır, ancak yalnızca o LUN'a yeni veri yazılmadığı sürece. Eğer dizi reinitialize sonrası o LUN'u yeni bir görev için kullanmaya başlarsa, eski veri bloklarının üzerine yazılır ve kurtarma şansı her geçen dakika azalır.

LUN bozulması, fiziksel disk arızası olmadan da meydana gelebilir. Bir dizi denetleyicisi firmware hatası, kontrolsüz güç kaybı ya da çift denetleyicili dizilerde başarısız bir failover, LUN metadata'sını tutarsız bırakabilir. Bu durumda LUN sunucuya hâlâ sunuluyor olabilir ama üzerindeki dosya sistemi okunamaz hale gelir ya da sunucu LUN'u ham (RAW) olarak görür. Burada acemi bir refleks, sunucu tarafında dosya sistemini onarmaya çalışmaktır (chkdsk, fsck gibi). Bu çok tehlikelidir çünkü altta yatan blok düzeni LUN seviyesinde bozulmuşsa, dosya sistemi onarımı tutarsız metadata üzerinde değişiklikler yapar ve gerçek veri yapısını daha da karıştırır.

SAN kurtarmanın altın kuralı, sorunu sunucu tarafından değil dizi tarafından ele almaktır. İlk adım, diziye ait fiziksel disklerin tamamını fiziksel sırasıyla etiketleyip çıkarmak ve her birinin imajını almaktır. Modern dizilerde RAID düzeni ve LUN haritalama özel olabileceği için, kurtarma uzmanının bu üreticiye özgü düzeni imajlar üzerinde tersine çözümlemesi gerekir. Disklere yazma yapılmadığı sürece, yanlışlıkla initialize edilmiş bir LUN bile çoğu zaman yüksek oranda kurtarılabilir. Kritik olan, kaza fark edilir edilmez diziyi durdurmak ve hiçbir disk üzerinde rebuild ya da yeni görev atamasına izin vermemektir. RAID seviyesindeki çökme süreçleri ve maliyetleri hakkında daha fazla bilgi için RAID 5 çöktü kurtarma süreci yazımızı inceleyebilirsiniz.

iSCSI Hedef Sorunları ve Ağ Katmanının Getirdiği Riskler

iSCSI, SCSI komutlarını TCP/IP üzerinden taşıyan bir protokoldür ve fiber kanal donanımı olmadan SAN benzeri blok depolama erişimi sağlar. Bir iSCSI hedefi (target), bir depolama dizisi ya da yazılım tanımlı bir sunucu üzerinde tanımlanır ve initiator adı verilen istemciler bu hedefe bağlanarak uzaktaki blok aygıtını yerel bir disk gibi kullanır. Bu mimarinin esnekliği, kurumsal sanallaştırma ve veritabanı ortamlarında onu çok yaygın kılar, ancak ağ katmanı yeni risk vektörleri de getirir.

iSCSI kaynaklı veri kaybı senaryolarında en yaygın olanı, hedefin dayandığı depolama yapısının (bir ZFS zvol, bir LVM volume, bir dosya tabanlı image ya da bir donanım dizisi LUN'u) bozulmasıdır. iSCSI burada yalnızca taşıyıcıdır; gerçek veri arkadaki blok aygıtında durur. Bu nedenle bir iSCSI olayında ilk yapılması gereken, hedefin tam olarak neyin üzerine kurulu olduğunu belirlemektir. Örneğin hedef bir ZFS zvol ise, sorun aslında bir ZFS havuz sorunudur ve yukarıda anlattığımız ZFS metodolojisi geçerlidir.

Ağ katmanı kendine özgü tehlikeler getirir. iSCSI bağlantıları kararsız bir ağda kesilip yeniden bağlandığında, initiator tarafındaki dosya sistemi yarım kalan yazmalar görebilir ve tutarsız duruma düşebilir. Daha kötüsü, iki initiator'ın aynı iSCSI hedefini paylaşımlı olarak bağlaması (cluster-aware bir dosya sistemi olmadan) durumudur. Bu yapılandırma yanlışlığı, her iki sunucunun da aynı blok aygıtına bağımsız yazmalar yapmasına ve dosya sisteminin hızla bozulmasına yol açar. Bu tür split-brain bozulmalar, blok seviyesinde içiçe geçmiş iki farklı yazma kümesi içerdiği için kurtarması en zor senaryolardandır.

iSCSI hedef kurtarmasında doğru yaklaşım, initiator tarafında hiçbir onarım yapmadan, hedefin dayandığı blok aygıtının imajını almaktır. Eğer hedef bir donanım dizisi üzerindeyse, dizi tarafı kuralları geçerlidir. Eğer yazılım tanımlı bir sunucu üzerindeyse, o sunucudaki disklerin imajlanması gerekir. Bağlantıyı yeniden kurup dosya sistemini mount etmeye zorlamak, tutarsız metadata üzerinde yeni günlük (journal) yazmaları üretebilir. iSCSI ve NAS protokollerinin örtüştüğü ortamlar için NAS veri kurtarma hizmetimiz bu karma senaryoları da kapsar.

Rebuild ve Resilver Tehlikesi: Arızalı Disklerin Üzerine Yük Bindirmek

Kurumsal depolama kurtarmada tekrar tekrar gördüğümüz ve en çok veri kaybına yol açan kalıp, çöken bir dizide rebuild ya da resilver başlatmaktır. Bu işlemleri anlamak için neden tehlikeli olduklarını teknik olarak açıklamak gerekir. Bir RAID grubu, ZFS vdev'i ya da Storage Spaces parity alanı redundancy ile çalışır: bir disk arızalandığında, sistem o diskin verilerini diğer disklerdeki parite ya da ayna kopyalarından yeniden hesaplayabilir. Yeni bir disk takıldığında, rebuild (donanım RAID), resilver (ZFS) ya da repair (Storage Spaces) işlemi başlar ve bu işlem dizideki diğer tüm disklerin neredeyse tamamen okunmasını gerektirir.

Buradaki sorun şudur: bir dizide bir disk arızalandıysa, geri kalan diskler genellikle aynı partiden, aynı yaşta ve aynı çalışma ortamından gelmektedir. Yani bir disk öldüyse, diğerleri de ömürlerinin sonuna yaklaşmış olabilir. Rebuild işlemi bu yorgun diskleri saatler hatta günler süren kesintisiz bir okuma yüküne sokar. Bu yoğun yük altında ikinci, hatta üçüncü bir disk arızalanırsa, redundancy sınırı aşılır ve dizi kurtarılamaz hale gelir. Sektörde bu olaya rebuild sırasında çoklu disk arızası denir ve büyük kapasiteli disklerin rebuild süreleri uzadıkça bu risk artmıştır.

Latent sektör hataları bu riski daha da büyütür. Normal çalışmada hiç okunmayan diskler, sessizce okunamaz sektörler biriktirmiş olabilir. Bu sektörler ancak rebuild sırasında o veri ilk kez okunmaya çalışıldığında ortaya çıkar. Tam da kritik anda, sistem zaten arızalı bir diski telafi etmeye çalışırken, ikinci bir diskte okunamaz bir sektörle karşılaşmak rebuild'i durdurabilir ve diziyi yarım onarılmış, tutarsız bir durumda bırakabilir. ZFS'te resilver checksum doğrulaması yaptığı için sessiz bozulmaları yakalar, ama bu da işlemi yavaşlatır ve zayıf diskleri daha uzun süre yük altında tutar.

Bu yüzden kurtarma uzmanlarının ilk müdahalesi, başlamış bir rebuild ya da resilver'i mümkünse durdurmak ve hiçbir yenisini başlatmamaktır. Doğru sıra şudur: önce diziyi durdur, sonra her diski imajla, sonra rebuild mantığını imaj kopyaları üzerinde sanal olarak çalıştır. İmaj üzerinde bir disk okunamayan bir sektör verdiğinde bu kurtarma sürecini öldürmez; o sektör atlanabilir, başka bir kopyadan tamamlanabilir ya da pariteden hesaplanabilir. Orijinal donanım üzerinde bu tolerans yoktur. İmaj-öncelikli yaklaşımın en somut faydası tam olarak budur. RAID dışı sistemlerde bile, örneğin Synology SHR gibi esnek dizilerde aynı prensip geçerlidir; Synology NAS çöktü kurtarma yazımız bu özel durumu ele alır.

Neden Kurumsal Diziler İmaj-Öncelikli Kurtarma Gerektirir

Şimdiye kadar her bölümde tekrarlanan tek bir ilke var: önce yazmaları durdur, sonra üye diskleri imajla. Bu ilkenin neden kurumsal dizilerde tartışmasız olduğunu bütünsel olarak açıklamak gerekir. Bir kurumsal dizi, birbiriyle ilişkili çok sayıda fiziksel diskten oluşan tek bir mantıksal bütündür. Verinin doğru sırası, ancak tüm disklerin tutarlı bir anlık görüntüsü alındığında çözülebilir. Eğer kurtarma sırasında dizinin bazı diskleri değişmeye devam ederse, çözüm zemini sürekli kayar ve tutarlı bir rekonstrüksiyon imkansız hale gelir.

İmaj-öncelikli kurtarmanın ilk adımı yazma trafiğini tamamen kesmektir. Bu, sunucuları kapatmak, dizinin host bağlantılarını kaldırmak ya da diziyi salt-okunur duruma almak anlamına gelir. Ardından her fiziksel disk fiziksel slot sırasıyla etiketlenir. Bu etiketleme hayati önemdedir çünkü RAID ve ZFS rekonstrüksiyonu disk sırasına bağlıdır; diskler karışırsa düzen çözülemez. Sonra her disk, donanım yazma korumalı bir köprü üzerinden bire bir sektör kopyalama yöntemiyle imajlanır. Okuma hatası veren diskler için özel imajlama donanımı zayıf sektörleri tekrar tekrar deneyerek mümkün olduğunca çok veri çeker.

İmajlar alındıktan sonra tüm analiz ve rekonstrüksiyon yalnızca bu kopyalar üzerinde yapılır. Orijinal diskler güvenli bir kasada bekler ve bir daha asla değiştirilmez. Bu yaklaşımın sağladığı en büyük avantaj, sınırsız deneme hakkıdır. Kurtarma uzmanı ZFS'te farklı uberblock'ları, SAN'da farklı RAID parametrelerini ya da Storage Spaces'te farklı slab eşlemelerini deneyebilir. Her denemenin başarısız olması, sadece imaj kopyasını geri yüklemek ve baştan başlamak demektir. Hiçbir deneme orijinal veriyi riske atmaz.

İmaj-öncelikli yaklaşım aynı zamanda zaman baskısını da ortadan kaldırır. Canlı donanım üzerinde çalışırken her saniye zayıf bir diskin tamamen ölme riskini taşır. İmajlar alındıktan sonra bu baskı kalkar ve uzman, en zor mantıksal bozulmaları bile sabırla çözebilir. Kurumsal bir veri kaybında acele etmek en büyük düşmandır; imajlama, aceleyi metodik bir sürece dönüştürür. Hizmetlerimizin kapsamı ve süreç akışı hakkında hizmetler sayfamızdan ayrıntılı bilgi alabilirsiniz.

Kurumsal Veri ve Gizlilik: Şirket Verisinin Korunması

Kurumsal bir depolama kurtarma işi, teknik bir görevden çok daha fazlasıdır; aynı zamanda bir güven ilişkisidir. ZFS havuzlarında, SAN dizilerinde ve Storage Spaces alanlarında genellikle bir şirketin en hassas varlıkları bulunur: finansal kayıtlar, müşteri veritabanları, çalışan kişisel verileri, sözleşmeler, kaynak kodu ve fikri mülkiyet. Bu veriler kurtarma sürecinde üçüncü bir tarafın eline geçtiği için, gizliliğin korunması teknik başarı kadar önemlidir.

Profesyonel kurtarma süreci, alınan disk imajlarının erişimi kontrol edilen ortamlarda saklanmasını gerektirir. İmajlar, kurtarma tamamlandıktan ve müşteri verisini teslim aldıktan sonra mutabık kalınan politikaya göre güvenli biçimde imha edilir. Bu yaşam döngüsünün belgelenmesi, KVKK gibi veri koruma düzenlemelerine tabi şirketler için önemlidir; bir veri kurtarma sürecinin kendisi de işlenen kişisel verinin güvenliğini sağlamak zorundadır. Gizlilik anlaşmaları ve veri işleme sorumlulukları bu sürecin ayrılmaz parçasıdır.

NIST SP 800-34 gibi süreklilik planlaması çerçeveleri, kurtarma operasyonlarının bir felaket kurtarma ve iş sürekliliği planının parçası olarak ele alınmasını önerir. Bu, kurtarmanın yalnızca veriyi geri getirmekle kalmayıp, olayın nasıl gerçekleştiğini anlamayı ve gelecekte tekrarını önlemeyi de kapsadığı anlamına gelir. Bir kurumsal müşteriyle çalışırken sadece kayıp veriyi çıkarmıyor, aynı zamanda kök nedeni (yetersiz redundancy, izlenmeyen disk sağlığı, eksik yedekleme stratejisi) raporluyor ve gelecekteki dayanıklılık için öneriler sunuyoruz.

Bir kurumsal depolama olayı yaşandığında ilk temas çok önemlidir. Doğru ilk müdahale, kurtarma şansını belirler. Bu yüzden bir ZFS havuzu, Storage Spaces alanı, SAN LUN'u ya da iSCSI hedefi sorun yaşıyorsa, hiçbir onarım denemeden önce bizimle iletişime geçmenizi öneririz.

SSS

ZFS havuzum faulted durumda ve import edilemiyor. zpool import -F denemeli miyim? Hayır, önce denememelisiniz. zpool import -F ZFS'i son birkaç TXG'yi geri sararak tutarlı bir noktaya döndürmeye zorlar ve bazı durumlarda işe yarar, ancak altta yatan disk bütünlüğü zaten bozuksa yeni yazmalar üretir ve durumu kötüleştirebilir. Doğru yaklaşım, önce tüm havuz disklerinin imajını almak ve force import gibi denemeleri yalnızca imaj kopyaları üzerinde yapmaktır. Orijinal disklere yazma yapan hiçbir komut ilk müdahalede çalıştırılmamalıdır.

Storage Spaces sanal diskim detached oldu. PowerShell ile yeniden bağlamayı zorlayabilir miyim? Detached durum genellikle pool metadata'sının tutarsız kalmasından ya da yeterli sayıda fiziksel diskin çevrimdışı olmasından kaynaklanır. Sanal diski zorla bağlamak ya da repair-virtualdisk çalıştırmak, metadata zaten tutarsızsa pool yapısına yeni yazmalar yapar ve parity bilgisini bozabilir. Diğer diskler marjinal durumdaysa repair sırasında ikinci bir disk arızası alanı kurtarılamaz hale getirebilir. Önce tüm pool disklerini imajlamak ve slab yapısını imajlar üzerinde çözmek gerekir.

SAN'da yanlış LUN'u initialize ettik. Veri tamamen gitti mi? Çoğu durumda hayır, ancak hızlı hareket etmeniz gerekir. Bir LUN initialize işlemi genellikle yalnızca haritalama metadata'sını sıfırlar; altta yatan veri blokları fiziksel disklerde hâlâ durur. Ancak dizi o LUN'u yeni bir görev için kullanmaya başlar ve üzerine yazarsa, eski veri her geçen dakika kaybolur. Hemen diziye yazmayı durdurun, hiçbir disk üzerinde rebuild ya da yeni görev atamasına izin vermeyin ve disklerin imajlanması için profesyonel destek alın.

Disk arızalandı ve yeni disk takıp resilver başlattım, şimdi havuz daha kötü durumda. Ne oldu? Resilver, dizideki tüm disklerin neredeyse tamamen okunmasını gerektirir. Diğer diskler de aynı yaşta ve aynı ortamdan geldiği için yorgun olabilir ve bu yoğun okuma yükü altında ikinci bir disk arızalanmış olabilir. Latent sektör hataları da resilver sırasında ilk kez ortaya çıkar. Bu durumda yapılacak en doğru şey resilver'i durdurmak, hiçbir yeni işlem başlatmamak ve diskleri imajlayıp rekonstrüksiyonu imaj kopyaları üzerinde yapmaktır. İmajlarda okunamayan sektörler kurtarmayı öldürmez.

Kurtarma sırasında şirket verimizin gizliliği nasıl korunuyor? Alınan disk imajları erişimi kontrol edilen ortamlarda saklanır ve yalnızca kurtarma sürecine atanan uzmanlar erişebilir. Kurtarma tamamlanıp veri müşteriye teslim edildikten sonra imajlar mutabık kalınan politikaya göre güvenli biçimde imha edilir. Bu yaşam döngüsünün belgelenmesi, KVKK gibi düzenlemelere tabi kurumsal müşteriler için önemlidir. Gizlilik anlaşmaları sürecin ayrılmaz bir parçasıdır ve veri işleme sorumlulukları en baştan netleştirilir.

Sonuç

Kurumsal depolama veri kurtarma, tek disk kurtarmadan temelde farklı bir disiplindir. ZFS havuzları, Windows Storage Spaces alanları, SAN dizileri ve iSCSI hedefleri, birbiriyle ilişkili çok sayıda fiziksel diskten oluşan karmaşık mantıksal bütünlerdir ve bu yüzden ilk müdahalede yapılan bir hata kurtarılabilir bir durumu kalıcı kayba çevirebilir. Bu yazıda tekrar tekrar vurguladığımız ilke nettir: yazmaları durdurun, hiçbir onarım, rebuild ya da resilver başlatmayın ve üye diskleri önce imajlayın. Tüm analiz ve rekonstrüksiyon yalnızca imaj kopyaları üzerinde yapılmalı, orijinal diskler asla değiştirilmemelidir.

ZFS'te agresif force import ve clear komutlarından kaçınmak, Storage Spaces'te detached diskleri zorla bağlamamak, SAN'da yanlışlıkla initialize edilmiş LUN'lara yeni veri yazmamak ve arızalı diskler üzerinde resilver yükü bindirmemek; bunların hepsi aynı temel mantığa dayanır. Kurumsal veri aynı zamanda en hassas veridir ve gizliliğinin korunması teknik başarı kadar önemlidir.

DSET olarak 2003'ten beri Ankara Hacettepe Teknokent'ten kurumsal depolama kurtarma yapıyoruz. Bir ZFS havuzu, Storage Spaces alanı, SAN LUN'u ya da iSCSI hedefi sorun yaşıyorsa, hiçbir denemeden önce bizimle iletişime geçin. Doğru ilk müdahale, verinizin geri gelip gelmemesini belirler.

Kaynaklar