Ana içeriğe geç
Doz Teknoloji Logo
DozTeknoloji
TRUENAS & NAS

TrueNAS: Snapshot, Replikasyon ve Yedekten Geri Dönüş

ZFS snapshot, yerel/uzak replikasyon ve bağımsız yedeği ayrı koruma katmanları olarak tasarlayın; RPO/RTO’yu restore testiyle ölçün.

İçerik güncellemesi:

Mimari ve çalışma modeli

Snapshot belirli bir andaki dataset veya zvol görünümünü korur; başlangıçta tüm veriyi yeniden kopyalamaz. Değişen eski bloklar retention boyunca yer tüketebilir. Aynı pool’daki snapshot disk/pool kaybında bağımsız kopya değildir ve storage yönetimini ele geçiren saldırgana karşı otomatik olarak immutable sayılmaz. Yerel dosya geri dönüşü için yararlı olması felaket kurtarma planının tamamı olduğu anlamına gelmez.

Replikasyon snapshot’ları başka dataset, pool veya sisteme taşır. Aynı kasa farklı pool donanım riskinin bir kısmını ayırabilir fakat yangın, güç, yönetim hesabı ve lokasyon riskini paylaşabilir. Uzak hedefin ayrı kimlik, erişim ve retention sınırını planlayın. Push/pull seçiminde hangi tarafın hangi yetkiyle bağlantı başlattığını kaydedin; sadece veri başka yerde diye saldırı yayılımı engellenmiş sayılmaz.

Yedekleme yazılımı ile NAS repository tasarımında protokol, destek matrisi, kilit davranışı, yazma ve geri okuma performansı, bağımsız kopya ve koruma politikası birlikte değerlendirilir. SMB/NFS hedefinin kullanılabiliyor olması o hedefi Linux hardened repository veya WORM yapmaz. Immutable özelliği seçilen ürün, sürüm ve retention kilidinde gerçekten uygulanmalı ve yetkili silme denemesiyle test edilmelidir.

Dosya sistemi snapshot’ı uygulama tutarlılığını tek başına kanıtlamaz. Veritabanı, sanal makine ve e-posta verileri için quiesce, uygulama backup API’si veya desteklenen koordinasyon gerekebilir. İşlem logları ve restore sırası uygulamanın yöntemine göre belirlenir. Crash-consistent kopyadan açılabilen uygulamanın tüm işlemleri veya iş kurallarını koruduğunu varsaymayın.

Retention, snapshot seçim filtresi, recursive dataset kapsamı ve hedefte silme davranışını birlikte kontrol edin. İlk full transfer ile artımlı transferin bant genişliği ihtiyacı farklıdır. Son başarılı job saatine ek olarak hedefteki son kullanılabilir snapshot zamanını ölçün; job’un başarılı olması eski veya kapsam dışı verinin güncel olduğunu kanıtlamaz. Kaynak ve hedef saatlerini eşitleyin, kopma ve kapasite uyarılarını gerçek teslimle sınayın.

Restore’u tercihen izole hedefe yapın; üretim üzerine rollback daha yeni değişiklikleri kaybettirebilir. Dosya içeriği, ACL, sahiplik, uygulama açılışı, bağımlılıklar ve kullanıcı kabulü aynı testte doğrulanır. Şifrelenmiş kopyalar için kurtarma anahtarının erişilebilirliği yalnız yetkili ekip tarafından sınanır. Anahtar ve konfigürasyon kaybını veri kopyasından ayrı bir risk olarak yönetin.

  1. 1Kapsam ve RPO/RTO
  2. 2Ayrı kopya ve yetki
  3. 3İzole restore
  4. 4Kabul ve rapor
Kopya başarısını gerçek geri dönüş ve erişim sınırıyla doğrulayın.

Tasarım parametreleri

Koruma sınırı
Snapshot, aynı kasa ve uzak hedefin ortak risklerini belirtin.
Son kullanılabilir nokta
RPO’yu hedefte doğrulanmış veri zamanıyla ölçün.
Uygulama tutarlılığı
Dosya görünümüne ek olarak uygulama restore yöntemini doğrulayın.
Retention ve silme
Kaynak/ hedef silme ve bağımsız koruma koşullarını test edin.

Hesap ve uygulama örneği

Örnek olayda son kullanılabilir uzak snapshot 10:40, olay 11:00 ise veri kaybı aralığı 20 dakikadır. Hizmet 11:50’de kabul edilirse RTO 50 dakikadır. Job 10:59’da çalışmış olsa da 10:40 snapshot’ını taşıdıysa RPO’yu 1 dakika diye raporlamak yanlıştır. Bunlar yöntem örneğidir, gerçek hizmet süresi taahhüdü değildir.

Pilot testte bir dosya silinir, bir ACL değiştirilir ve örnek uygulama verisi güncellenir. İzole restore hedefinde doğru sürüm, yetki ve uygulama işlemi kabul edilir. Ayrı testte kaynak yöneticisinin hedef kopyayı silip silemediği ve hedef erişimi kesilince uyarı geldiği doğrulanır.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Replikasyon başarılı ama veri eskiYanlış snapshot filtresi veya kaynak görev zamanı olabilir.Hedef snapshot timestamp ve recursive kapsamı kontrol edin.
Pool sağlam, restore eksikAlt dataset, log veya uygulama bağımlılığı dışarıda kalmış olabilir.Kapsamı uygulama kabul listesiyle eşleştirin.
Korunan kopya silinebiliyorYalnız snapshot/readonly erişim kullanılmış olabilir.Gerçek retention kilidi ve yönetim yetkisini test edin.

Kabul ve doğrulama kontrolleri

  1. Kopya başarısını gerçek geri dönüş ve erişim sınırıyla doğrulayın.
  2. Snapshot’ı bağımsız yedekle karıştırmayın.
  3. Hedef retention ve silme davranışını test edin.
  4. Uygulama tutarlılığı ve kapsamı doğrulayın.
  5. Son kullanılabilir veri noktasını kaydedin.
  6. ACL ve kullanıcı kabulüyle restore’u tamamlayın.

İlgili kavramlar

Replikasyonun kapsamı

Replikasyon veri veya durum değişikliklerini başka bir kopyaya aktarır. Senkron aktarım gecikme ve bağlantı bağımlılığı yaratabilir; asenkron aktarım ise geride kalabilir. Kopyanın güncel olması, yanlış değişikliklerden korunması anlamına gelmez: silme veya bozulma da taşınabilir. Gecikmeyi yalnız bağlantı durumu üzerinden değil, uygulamanın tamamlanan son işlemiyle karşılaştırın. Kaynak düğüm kaybedildiğinde yazma yetkisinin hangi kopyaya geçeceğini ve eski düğüm geri gelince nasıl uzlaştırılacağını tanımlayın. Replikasyon gecikmesi ile gerçek kurtarma noktasını ayrı raporlayın.

RPO ve gerçek veri kaybı penceresi

RPO, olay sonrasında kabul edilebilecek veri kaybı süresidir. Yedek zamanlaması tek başına RPO kanıtı değildir; işin başarısız olması veya kopyanın karşı merkeze geç ulaşması pencereyi büyütebilir. Olay anı ile kullanılabilir son tutarlı kurtarma noktasının zamanını karşılaştırın. Örneğin olay 14.00'te, doğrulanmış kopya 13.20'deyse o testteki veri kaybı penceresi 40 dakikadır. Hedefi uygulama bazında belirleyin: dosya arşivi ile sürekli sipariş alan veritabanının gereksinimleri aynı olmayabilir.

RTO ve uçtan uca kurtarma süresi

RTO, bir hizmetin olaydan sonra ne kadar sürede kullanılabilir hale gelmesi gerektiğini ifade eder. Yedek dosyasının indirilmesi veya sanal makinenin açılması bu sürenin yalnız bir bölümüdür. Olayı tanıma, onay, altyapı hazırlığı, veri aktarımı, uygulama açılışı ve iş biriminin doğrulaması ayrı zaman kalemleri olarak kaydedilmelidir. Bir testin kronometresini hangi olayda başlatıp bitirdiğinizi açıkça yazın. Aynı teknik geri dönüş süresi, bağımlılık veya erişim beklenmesi nedeniyle farklı iş süreçlerinde farklı kesinti süresine dönüşebilir.

Değiştirilemezlik ve silme yetkisi

Immutable saklama, belirlenen süre içinde verinin değiştirilmesini veya silinmesini sınırlayan bir kontrol mekanizmasıdır. Uygulamanın verdiği söz, depolama katmanındaki zorunlu koruma ve fiziksel izolasyon aynı şey değildir. Kilit süresi, saat yönetimi, yönetici yetkileri ve veri silme yolu birlikte incelenmelidir. Süre dolunca verinin otomatik silinip silinmediği de ürün politikasına bağlıdır. Kontrollü bir test kopyası üzerinde normal ve ayrıcalıklı hesapla silme denemesi yapın; ardından korunan kopyadan geri dönüşü doğrulayın. Koruma, okunabilirlik testinin yerine geçmez.

Saklama politikası ve kapasite

Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayın.

Uygulama tutarlılığı

Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedek ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.

Birincil teknik dokümantasyon

Hazırlama yöntemi

Doz Teknoloji Teknik Ekibi tarafından hazırlanan bu rehberde üreticilerin resmi dokümanları temel alınır. Örnek senaryolar ve hesaplar yöntemi açıklamak içindir; tamamlanmış müşteri testleri değildir. Uygulamadan önce sürüm, lisans, istemci desteği, güvenlik koşulları ve geri dönüş planını kendi ortamınızda doğrulayın. Seçim mevcut ürünlerinize ve iş yükünüze göre yapılır.

Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!