Hızlı Cevap

QNAP NAS cihazınız erişilemez hale geldiğinde yapmanız gereken ilk şey cihazı kapatmak ve diskleri olduğu gibi bırakmaktır. En kritik kural şudur: rebuild başlatmayın, depolama havuzunu başa döndürmeyin (initialize), yapılandırmayı sıfırlamayın ve disk takıp çıkarmayın. Yanlış bir tek işlem, hâlâ kurtarılabilir olan verinin kalıcı olarak yok olmasına yol açabilir.

QNAP Veri Kaybı Neden Yüksek Risklidir

QNAP NAS cihazları küçük ve orta ölçekli işletmelerin sanal sunucularını, muhasebe yedeklerini, ortak proje dosyalarını ve gözetim kayıtlarını tek bir yerde topladığı için bir arıza anında riske giren veri hacmi çok büyüktür. Üstelik birçok işletme NAS cihazını "yedek" olarak gördüğü için ayrı bir yedeği olmaz. RAID korumalı bir sistem tek diskin arızasına dayanabilir, ancak RAID asla yedek yerine geçmez. İki diskin aynı anda zayıflaması, hatalı bir firmware güncellemesi veya yanlışlıkla silinen bir birim, tüm veriyi bir anda erişilemez hale getirebilir.

Synology tarafında benzer senaryoları ayrıca ele aldık: Synology NAS coktu. Bu yazı özellikle QNAP cihazlarına, QTS ve QuTS hero mimarilerine ve onların kendine özgü kurtarma zorluklarına odaklanıyor.

QNAP Cihazlarında Sık Görülen Arıza Senaryoları

  • Tek disk arızası sonrası bozulmuş (degraded) RAID dizisi.
  • Rebuild sırasında ikinci bir diskin arızalanması.
  • Yanlışlıkla silinmiş depolama birimi (volume) veya LUN.
  • Firmware veya QTS güncellemesi sonrası cihazın açılmaması, sürekli yeniden başlaması.
  • Depolama havuzunun "not active" durumuna düşmesi.
  • ext4 dosya sistemi bozulması veya süperblok hasarı.
  • ZFS havuzunda metadata tutarsızlığı ya da içe aktarılamayan (unimportable) pool.
  • Şifreli birimin parola veya anahtar dosyası kaybı.
  • Birden fazla diskte fiziksel sektör hatası, takırtı veya kafa arızası.

QTS ile QuTS hero Farkı ve Kurtarmaya Etkisi

QNAP iki ayrı işletim sistemi sunar ve bunların kurtarma yöntemleri temelden farklıdır.

QTS, dosya sistemi olarak ext4 kullanır ve altta Linux mdadm yazılımsal RAID ile LVM katmanını barındırır. Birimler thick veya thin olabilir ve thin birimler LVM ince hazırlama (thin provisioning) üzerine kuruludur. Kurtarmada amaç, mdadm meta verisini doğru okuyarak RAID dizisini sanal olarak yeniden kurmak, ardından LVM yapısını ve ext4 dosya sistemini çözümlemektir.

QuTS hero ise ZFS tabanlıdır. ZFS, copy on write yapısı, kontrol toplamları (checksum), kendi RAID benzeri yapısı olan RAID Z ve bütünleşik snapshot mekanizması ile gelir. Bu yapı veri bütünlüğü açısından güçlüdür, ancak metadata zincirinde bir kopukluk olduğunda kurtarma çok daha karmaşıktır. ZFS pool yanlış bir komutla içe aktarılmaya zorlanırsa, transaction grubu yapısı bozulabilir ve geri dönüşü olmayan kayıplar oluşabilir. Bu yüzden QuTS hero sistemlerde "zpool import -f" benzeri zorlayıcı komutlar kesinlikle denenmemelidir.

Snapshot teknolojisi her iki tarafta da kurtarmayı bazen kolaylaştırır. Eğer birim silinmiş ama snapshot zinciri sağlamsa, eski tutarlı durum geri getirilebilir. Ancak snapshot alanının üzerine yazıldıysa veya havuz aktif değilse bu şans ortadan kalkar.

Neden Bozuk Bir RAID'i Rebuild Etmek Veriyi Yok Eder

Bozulmuş bir dizide tek bir disk arızalandığında, sistem hâlâ paritesiyle çalışmaya devam eder. Yeni disk takıp rebuild başlattığınızda, denetleyici kalan disklerin tamamını baştan sona okuyarak eksik veriyi yeniden hesaplar ve yeni diske yazar. Sorun şudur: kalan disklerden biri zaten zayıfsa, yani yer yer okunamayan sektörlere sahipse, rebuild bu sektörlere ulaştığında ya tamamen durur ya da hatalı veriyi parite ile yayar. RAID 5 dizilerinde bu, ikinci diskin de devre dışı kalması ve dizinin tamamen çökmesi demektir.

Daha tehlikeli olan, rebuild sırasında yapılan yazma işlemlerinin diskler üzerindeki orijinal düzeni değiştirmesidir. Profesyonel bir kurtarma için disklerin rebuild öncesi haldeki ham görüntüsü gerekir. Rebuild başladıktan sonra bu ham hal kalıcı olarak bozulur. Bu konuyu RAID 5 özelinde derinlemesine işledik: RAID 5 kurtarma sureci ve maliyet.

Thin Birim, LUN ve Depolama Havuzu Özellikleri

Thin birimler, gerçek disk alanını yalnızca veri yazıldıkça ayırır. Bu, kurtarmada bir zorluk katmanı ekler: dosya sistemi mantıksal olarak büyük görünse de fiziksel tahsisat parça parça dağılmıştır. iSCSI LUN yapılarında ise LUN'un tahsis haritası ve dosya sisteminin kendisi ayrı katmanlardadır. Yanlışlıkla silinen bir thin LUN'da, alan havuza iade edilmiş olsa bile veri henüz üzerine yazılmadıysa sektör seviyesinde geri getirilebilir. Bu nedenle silme sonrası cihaza hiçbir yeni veri yazılmaması hayati önem taşır.

Kesinlikle Yapılmaması Gerekenler

  • Initialize (başa döndürme) yapmayın. Bu işlem havuz yapısını sıfırlar.
  • Yapılandırmayı sıfırlamayın, fabrika ayarlarına dönmeyin.
  • Diziyi rebuild etmeye izin vermeyin, yeni disk takıp beklemeye başlamayın.
  • Diskleri körlemesine dosya sistemi onarımına (fsck, e2fsck, zpool clear) sokmayın.
  • Diskleri farklı yuvalara, farklı sırayla takmayın.
  • Şüpheli bir diski "biraz daha çalışsın" diye açık bırakmayın, fiziksel arıza varsa her dakika veriyi azaltır.
  • Online kurtarma yazılımlarını doğrudan canlı dizi üzerinde çalıştırmayın.

Profesyonel Laboratuvar Süreci

Aşama Yapılan İşlem Amaç
1. Teşhis Disklerin fiziksel ve mantıksal durumu değerlendirilir Risk haritası çıkarmak
2. Klonlama Her disk salt okunur olarak ddrescue ile birebir kopyalanır Orijinali korumak
3. Sanal birleştirme RAID dizisi klonlar üzerinden sanal olarak yeniden kurulur Disk sırası ve parametreleri bulmak
4. Parite analizi Şerit boyutu, disk sırası ve parite düzeni doğrulanır Doğru rekonstrüksiyon
5. Dosya sistemi ext4 ya da ZFS yapısı çözümlenir, snapshot zinciri kontrol edilir Dosyalara erişim
6. Çıkarma Veri ayrı bir hedef diske aktarılır ve doğrulanır Teslim

Profesyonel sürecin altın kuralı, hiçbir işlemin orijinal diskler üzerinde yapılmamasıdır. Önce her disk salt okunur modda, gerekirse donanımsal yazma engelleyici ile klonlanır. Zayıf diskler ddrescue gibi araçlarla, kötü bölgeleri atlayarak ve sonradan tekrar deneyerek imajlanır. Bütün analiz bu klonlar üzerinde, sanal RAID birleştirme tekniğiyle yapılır. Disk sırası, şerit boyutu ve parite rotasyonu deneme ile değil, ham veri desenleri ve dosya sistemi imzaları analiz edilerek belirlenir. Doğru parametreler bulunduğunda dosya sistemi tutarlı şekilde okunur ve veri güvenli bir hedefe çıkarılır.

DIY Ne Zaman Tehlikelidir

Tek bir disk arızalanmış ve dizi hâlâ sağlıklı çalışıyorsa, soğukkanlı bir kullanıcı verisini başka bir yere yedekledikten sonra diski değiştirebilir. Ancak dizi degraded durumdaysa, ikinci disk zayıfsa, birim silinmişse, firmware güncellemesi cihazı tuğlaya çevirmişse ya da ZFS havuzu içe aktarılamıyorsa, her ek deneme kurtarma şansını düşürür. Bu durumlarda en güvenli adım cihazı kapatıp uzman desteği almaktır.

Sık Sorulan Sorular (SSS)

QNAP cihazım açılmıyor, diskler sağlam mı?

Cihazın açılmaması her zaman disk arızası anlamına gelmez. Sorun çoğu zaman firmware, sistem bölümü ya da anakart kaynaklıdır. Diskler genellikle sağlam kalır ve başka bir ortamda okunabilir.

Yanlışlıkla sildiğim birim geri gelir mi?

Üzerine yeni veri yazılmadıysa ve depolama havuzu hâlâ aktifse geri getirilme şansı yüksektir. Silme sonrası cihaza hiçbir şey yazmamak en kritik noktadır.

Rebuild başlattım ve takıldı, ne yapmalıyım?

Cihazı hemen kapatın. Takılan bir rebuild genellikle ikinci bir diskin zayıf olduğunu gösterir. Bu noktadan sonra tek güvenli yol disklerin salt okunur klonlanmasıdır.

QuTS hero (ZFS) kurtarması QTS'ten daha mı zor?

Genelde evet. ZFS metadata zinciri bozulduğunda kurtarma daha karmaşıktır ve zorlayıcı import komutları durumu kötüleştirebilir. Bu yüzden ZFS havuzlarında müdahale öncesi uzman değerlendirmesi önemlidir.

Veri kurtarma ne kadar sürer ve maliyeti nedir?

Süre arızanın türüne ve disk sayısına göre değişir. Yaklaşık aralıklar için veri kurtarma fiyat listesi 2026 yazımızı inceleyebilirsiniz.

DSET ile İletişim

DSET, 2003 ten bu yana Ankara Hacettepe Teknokent Beytepe de hizmet veriyor. Veri kurtarmada başarı oranımız yüzde 99.4, ilk teşhis ücretsiz ve veri çıkmazsa ücret yok. QNAP NAS cihazınızla ilgili durumu değerlendirmek için bizi +90 536 662 38 09 numarasından arayabilirsiniz. Diskinize müdahale etmeden önce bir uzmanla konuşmak çoğu zaman verinizi kurtaran en önemli karardır.

Kaynaklar