Ana içeriğe geç

Karşılaştırma · Sunucu ve Sanallaştırma

VM Snapshot, Checkpoint ve Bağımsız Yedek Farkı

Snapshot VM durumunun bir noktasını yakalamak için kullanılır; kapsam disk veya bellek dahil olabilir. Checkpoint sözcüğü platforma göre farklı anlam taşır. Libvirt disk checkpoint’i…

Teknik gözden geçirme:

Mimari ve çalışma modeli

Snapshot VM durumunun bir noktasını yakalamak için kullanılır; kapsam disk veya bellek dahil olabilir. Checkpoint sözcüğü platforma göre farklı anlam taşır. Libvirt disk checkpoint’i değişen blok takibi için metadata/bitmap kullanabilir; başka bir platformun checkpoint kavramıyla aynı kabul edilmemelidir.

Bağımsız yedek, kaynak depolamadan ayrı geri yüklenebilir kopya ve kurtarma prosedürü gerektirir. Snapshot zinciri kaynak datastore bozulunca kullanılamayabilir. Uygulama tutarlılığı, freeze/thaw veya uygulama entegrasyonuyla ayrıca doğrulanır; VM’nin açılması veritabanının tutarlı olduğunu göstermez.

  1. 1Tutarlılık noktası
  2. 2Snapshot/bitmap
  3. 3Kopyalama ve saklama
  4. 4Bağımsız restore
Platformdaki checkpoint anlamını doğrulayın.

Tasarım parametreleri

Kapsam
Disk, bellek, konfigürasyon ve harici volume kapsamını ayrı yazın.
Zincir yönetimi
Overlay büyümesini ve merge için ek alanı ölçün; merge sırasında IO gecikmesini izleyin.
Kurtarma bağımsızlığı
Kaynak host ve datastore erişilemezken kopyadan yeni ortama dönüşü test edin.

Platformlardaki uygulama karşılıkları

Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.

AraçAmaçTek başına sağlamadığı
SnapshotKısa süreli geri alma noktasıBağımsız felaket kurtarma
Libvirt disk checkpointDeğişen blok takibiKopyanın kendisi
YedekAyrı kopyadan kurtarmaTest edilmeden RTO garantisi

Hesap ve uygulama örneği

500 GB disk üzerinde snapshot sonrası günde 20 GB blok değişimi varsa yedi günde kaba üst plan 140 GB overlay olabilir; gerçek büyüme blok tekrarları ve formatla değişir. Geri alma ve merge için ek alan ayırın. Yedek kabulünde bu snapshot’ın bulunduğu datastore’u kullanmadan restore yapın.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Snapshot silinince IO yükseldiMerge veya zincir konsolidasyonu.Datastore gecikmesi ve merge ilerlemesini izleyin.
VM açılıyor, uygulama bozukCrash-consistent kopya veya kapsam dışı volume.Uygulama recovery logunu ve disk kapsamını inceleyin.

Kabul ve doğrulama kontrolleri

  1. Platformdaki checkpoint anlamını doğrulayın.
  2. Harici diskleri kapsama alın.
  3. Uygulama tutarlılığını sınayın.
  4. Zincir büyümesini alarm ile izleyin.
  5. Kaynak kapalıyken restore yapın.
  6. Merge için kapasite ayırın.

İlgili kavramlar

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.

Kalıcılaştırma ve güç kaybı

Commit edilmiş verinin güç kaybından sonra korunması veritabanı, işletim sistemi, dosya sistemi, kontrolcü ve diskin yazma garantilerinin birleşimine bağlıdır. Yazma önbelleği ve flush davranışını bilmeden performans için güvenlik ayarlarını kapatmayın. Güç kaybı korumalı depolama faydalıdır fakat bütün zincirin doğru yapılandırıldığını tek başına kanıtlamaz. Üretim yerine kontrollü laboratuvarda arıza ve recovery testi yapın. Veri bütünlüğünü örnek dosya açılmasıyla değil, uygulama kayıtları ve desteklenen tutarlılık kontrolleriyle doğrulayın.

Bağımlılık ve geri açılış sırası

Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Geri açılış sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayı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.

Kapasite ve kullanılabilir pay

Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.

Birincil teknik dokümantasyon

Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.

Bilgi Merkezi

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ı!