Sunucuda güncellemeden önce snapshot almak yararlı bir geri dönüş adımı olabilir. Fakat bu özellik, uygulama yedeği ve bağımsız veri kopyasıyla aynı anlamı taşımaz. Özellikle sipariş, muhasebe veya e-posta gibi sürekli değişen veri bulunan sistemlerde hangi noktaya geri dönüleceği önemlidir. Temel saklama yaklaşımı için 3-2-1 yedekleme rehberi tamamlayıcıdır; burada anlık görüntünün sınırlarını ele alıyoruz.
Özelliğin gerçek kapsamını sorun
Hizmetinizde snapshot var mı, hangi diskleri kapsıyor, nerede tutuluyor ve geri yüklemeyi kim yapabiliyor? Bu sorular yanıtlanmadan güvence varsayılmamalıdır. Microsoft Hyper-V checkpoint belgesi, standart ve üretim checkpoint türlerini ayırır; standart snapshot’ın tam yedek olmadığını vurgular. Bu açıklama Hyper-V’ye aittir. Başka sanallaştırma altyapısında aynı özelliklerin ve varsayılanların bulunduğunu kabul etmeyin.
Sağlayıcının panelinde bir düğme görünmesi, verinin farklı bir altyapıda bağımsız kopyalandığını kanıtlamaz. Saklama süresi, silinme koşulları, depolama bağımlılığı ve geri dönüş prosedürü yazılı olarak netleşmelidir. VDS hizmetini seçerken paket kapasitesiyle yedek kapsamını ayrı değerlendirin; bu yazı belirli bir pakette snapshot bulunduğu sözü vermez.
Çalışan uygulamanın verisi ayrıca düşünülmeli
Bir veritabanının dosyalarını kopyalayabilmek, uygulamanın sağlıklı biçimde geri açılacağını tek başına göstermez. Üreticinin desteklediği yedek veya tutarlılık yöntemi önemlidir. Veri dosyası, ayar, şifreleme anahtarı ve gerekli bağımlılıkları listeleyin. Rastgele servis durdurma veya dosya kopyalama tarifi yerine uygulamanın belgelenmiş yöntemini izleyin. Container kullanıyorsanız Docker volume ve kalıcılık rehberi veri yerleşimini anlamanıza yardım eder.
Geri dönülen saatten sonra ne kaybolabilir?
Dün geceki noktaya dönüş, bugün oluşan siparişlerin, kullanıcı değişikliklerinin veya gönderilmiş rapor kayıtlarının da eski hâle gelmesine yol açabilir. Dış sistemler aynı noktaya dönmediği için çift işlem veya kayıt uyuşmazlığı riski doğabilir. Hangi veri kaybının kabul edilebilir olduğunu ve hangi işlerin yeniden uzlaştırılacağını önceden yazın. İş sahibiyle teknik ekibin aynı saati ve kapsamı konuşması gerekir.
Geri yüklemeyi dosya varlığıyla sınırlamayın
Bir test planında uygulamanın açılması, örnek verinin okunması, kritik işlemin çalışması ve dış bağlantıların güvenli biçimde sınırlandırılması bulunmalıdır. Test ortamından gerçek müşteriye e-posta veya sipariş gönderilmemesine dikkat edin. Yedeği geri yükleme testi rehberi kontrol mantığını anlatır; sunucu uygulamanızın adımları ayrıca özelleştirilmelidir.
Canlıya geri dönüş gerekiyorsa bakım penceresi, mevcut verinin korunması, yetkili onay ve geri alma planı gerekir. Snapshot’ı uzun süreli arşiv veya fidye yazılımına karşı tek savunma olarak kullanmayın. Doğru yaklaşım, hızlı geri dönüş aracını bağımsız yedek ve uygulama kurtarma planıyla tamamlamaktır.
Geri dönüş planında karar yetkisini de yazın: işlemi kim onaylayacak, kim uygulayacak ve uygulama sahibi sonucu nasıl kabul edecek? Kullanıcıların sisteme tekrar veri yazmaya başlayacağı an netleşmelidir. Teknik olarak açılmış bir makine, henüz iş açısından doğrulanmamış olabilir; bu ayrımı yapmak özellikle dış hizmetlerle veri alışverişi olan sistemlerde önemlidir.
Sıkça Sorulan Sorular
Snapshot tam yedek yerine geçer mi?
Genel olarak aynı şey değildir. Kapsam, saklama yeri ve altyapı bağımlılığı hizmete göre değişir; bağımsız yedek ayrıca planlanmalıdır.
Snapshot’a dönünce yeni siparişler ne olur?
Geri dönülen noktadan sonra oluşan verilerin kaybı veya tutarsızlığı söz konusu olabilir; uygulamaya özel kurtarma planı gerekir.
Her sağlayıcının snapshot özelliği aynı mı?
Hayır. Teknoloji, erişim ve tutarlılık yöntemi değişebilir. Hizmette var olduğunu veya belirli türde olduğunu varsaymayın.
Test için canlı sisteme geri döneyim mi?
Hayır. Mümkünse izole test ortamında doğrulama planlayın; canlı geri dönüşü bakım ve veri koruma planıyla yapın.