Snapshot yedekleme gerçek backup yerine geçer mi?

Snapshot (anlık görüntü) teknolojisi VDS/VPS platformlarında hızlı geri dönüş vaadiyle öne çıkar. Ancak snapshot her zaman “gerçek backup” değildir; özellikle silme, bozulma (korruption) ve fidye yazılımı (ransomware) senaryolarında beklentiyi karşılamayabilir. Bu yazıda snapshot’ın ne sunduğunu, hangi risklerde yetersiz kaldığını ve RPO/RTO hedeflerinizle nasıl net karar vereceğinizi öğreneceksiniz.

Snapshot nedir, backup nedir? Aradaki temel fark

Önce kavramları ayrıştıralım.

Snapshot (anlık görüntü) ne yapar?

• Sanal diskin belirli bir zaman noktasındaki durumunu kaydeder.
• Çoğu sağlayıcıda snapshot, yazma (write) akışını kesmeden veya kısa bir anlık süreçle “kurtarılabilir bir disk durumu” oluşturur.
• Geri dönüşte genellikle disk katmanında hızlı bir rollback sağlanır.

Gerçek backup (yedek) ne yapar?

• Yedek kopyası, yalnızca diskin o anki halini değil; çoğu zaman dosya/uygulama tutarlılığını (application consistency) hedefler.
• Genellikle ayrı saklama (storage) alanında tutulur.
• Saklama politikası (retention), sürümleme (versioning) ve uzun süreli tutma (ör. 30/90/180 gün) planı sunar.
• Geri yükleme (restore) süreci düzenli test edilir.

Net ifade: Snapshot “hızlı geri dönüş aracı” olabilir; gerçek backup ise “tutarlı, saklanan ve test edilen kurtarma planı”dır.

Snapshot her zaman güvenli backup sayılır mı?

Hayır. Snapshot’ı backup yerine koymadan önce şu senaryolarda ne olacağını bilmeniz gerekir.

1) Silme (delete) ve yanlışlıkla dosya/VM işlemi

• Kullanıcı yanlışlıkla klasörü sildiyse veya veritabanında kritik bir işlem yaptıysa, çoğu snapshot “sileceğiniz işlemden sonra” alınmışsa işe yaramaz.
• Ayrıca bazı platformlar snapshot alma ile eş zamanlı “uygulama tutarlılığı” garantisi vermeyebilir.

2) Fidye yazılımı (ransomware) ve bulaş sonrası bozulma

• Ransomware, dosyaları şifrelemeden önce/sonra alınan snapshot’larda fark yaratır.
• Snapshot’lar, bulaş vektörünü (örn. aynı ağda paylaşılan kimlik bilgileri) temizlemez. Bulaş tekrar başlarsa aynı imajdan yeniden kalkabilirsiniz.

3) Veritabanı tutarlılığı (application consistency)

• Snapshot alındığında veritabanı içinde “tam commit olmamış” değişiklikler olabilir.
• Bazı sistemlerde bu risk journal/WAL mekanizmalarıyla kısmen yönetilir; ancak bu garanti değildir.
• Sonuç: snapshot’tan geri döndüğünüzde uygulama ayağa kalksa bile tutarlılık hataları görebilirsiniz.

4) Sağlayıcı tarafında snapshot silinmesi veya kısıtlar

• Snapshot’lar “limit”e veya “plan dahilinde belirli sayı/kapasite”ye tabi olabilir.
• Saklama bitince snapshot otomatik silinirse gerçek backup katmanı zayıflar.

Net karar kuralı: Snapshot, “diski anlık kurtarma” için güçlüdür; fakat yapılandırma, uygulama tutarlılığı, saklama ve doğrulama şartlarını sağlamıyorsa gerçek backup yerine geçmez.

RPO ve RTO ile netleştirme: Snapshot hangi limitlerde kalır?

Karar vermenin en pratik yolu hedeflerinizi ölçmektir. İki kavram kullanacağız.

RPO (Recovery Point Objective)

RPO, verinizin geri dönüşte en fazla ne kadar “eskide” kabul edilebileceğini gösterir. - Örnek: 15 dakikalık RPO hedefi varsa snapshot aralığınız 15 dakikayı geçmemelidir.

RTO (Recovery Time Objective)

RTO, sistemin ne kadar sürede ayağa kalkması gerektiğini söyler. - Snapshot rollback disk seviyesinde hızlı olabilir; ancak uygulama, servis başlatma, veritabanı recovery ve doğrulama süreleri eklenir.

Snapshot vs backup için pratik eşleşme

Aşağıdaki tablo, tipik beklentileri netleştirir. Gerçek değerler sağlayıcıya göre değişebilir.

Sağlayıcıdan isteyeceğiniz kontrol listesi (snapshot’ı değerlendirmek için)

Snapshot’ın “backup” olup olmadığını anlamak için sözleşme ve teknik dokümanda şu maddeleri kontrol edin.

1) Saklama (retention) politikası

• Snapshot’lar kaç gün/ay saklanır?
• Ek snapshot başına ücret veya kapasite limiti var mı?
• Otomatik silinme zamanı nedir?

2) Snapshot aralığı ve tetikleme

• Otomatik snapshot sıklığı nedir (örn. her 15 dk/1 saat/günlük)?
• Manuel snapshot alma opsiyonunda “tutarlılık” var mı?

3) Uygulama tutarlılığı desteği

• “Quiescing” (servisleri duraklatma) veya uygulama tutarlılığı sağlayan araçlar var mı?
• Özellikle WordPress, MySQL/MariaDB, PostgreSQL kullanan sistemlerde uygulama konsistensi kritik olur.

4) Depolama yeri ve yalıtım

• Snapshot’lar aynı fiziksel ortamda mı yoksa ayrı sistem/zonlarda mı saklanır?
• Aynı hesabın silme hatasında snapshot’lar da etkileniyor mu?

5) Geri yükleme (restore) testleri

• Sağlayıcı restore süresini raporlar mı?
• Platformda “restore sonrası servis doğrulama” adımı için doküman var mı?

Net senaryolar: Snapshot’ı ne zaman yeterli, ne zaman yetersiz saymalısınız?

Snapshot yeterli kabul edilebilecek durumlar

• VM/Ağ seviyesinde kısa süreli arıza, yanlış güncelleme rollback’i gibi olaylarda.
• Uygulama tutarlılığı gereksinimi düşük olan ve veritabanı yükü minimal olan statik servislerde.
• Snapshot dışında ayrıca konfigürasyon yedekleri ve dosya yedekleme de varsa (ör. uygulama kodu + kritik konfig).

Snapshot yetersiz sayılacak durumlar

• Veri kaybı toleransı düşük (RPO dakikalar) ve snapshot aralığı yetersizse.
• Uzun süreli geçmişe dönmeniz gerekiyorsa (örn. 90+ gün).
• Fidye yazılımı, masaüstü bulaşları gibi “temiz geri dönüş” gerektiğinde.
• Veritabanı recovery sürecini hiç test etmediyseniz.

“Snapshot var ama backup yok” hatası nasıl anlaşılır?

Şu belirtiler genellikle yanlış güvenin işaretidir.

Belirti 1: Restore test planı yok

Snapshot aldığınızı varsayalım. Peki: - Son snapshot’tan geri dönünce uygulama ayağa kalkıyor mu? - Veritabanında tutarlılık hatası görüyor musunuz? - Rollback sonrası ağ/SSL/konfig değişiklikleri tekrar ayarlanıyor mu?

Belirti 2: Snapshot saklama süresi belirsiz

“Anlık görüntü alıyoruz” cümlesi tek başına yetmez. Sağlayıcı dokümanında saklama süresi ve limit net olmalıdır.

Belirti 3: Tek kopya

Tek bir snapshot kopyası, depolama alanı sorunlarında veya yanlışlıkla snapshot silme durumunda sizi korumaz.

Aksiyon: Snapshot + gerçek backup için net mimari

Snapshot’ı tamamen atmak yerine, onu rolüne uygun konumlandırın.

Önerilen katmanlı yaklaşım

• Katman A: Hızlı rollback için snapshot (ör. saatlik veya olay bazlı manuel).
• Katman B: Gerçek backup için ayrı saklama ve uzun retention (ör. günlük/haftalık, 30-90 gün).
• Katman C: Konfigürasyon yedekleme (yedekleme) ve doğrulama: kontrol panel ayarları, DNS kayıtları, uygulama yapılandırmaları.

Pratik uygulama örneği (VM + veritabanı)

• Snapshot aralığını RPO hedefinize göre belirleyin.
• Veritabanı için uygulama tutarlılığı gerektiren yöntemleri kullanın.
• Günlük/haftalık yedekleri ayrı storage’da tutun.
• Her ay en az bir kez “restore testi” yapın:
• Ayrı bir ortamda (test ortamı) geri yükleme
• Uygulama check (health) ve veritabanı tutarlılık kontrolü

Sonuç: Snapshot’ı backup yerine koymadan önce 3 soruyu netleştirin

Snapshot yedekleme, doğru kurguda hızlı kurtarma sağlar; ancak “gerçek backup” beklediğiniz senaryolarda tek başına riskli olabilir. Karar vermek için şu 3 soruya net cevap bulun: 1) Snapshot saklama süresi ve otomatik silinme mekanizması nedir? 2) Snapshot geri dönüşte uygulama (özellikle veritabanı) tutarlı mı olur? 3) Restore işlemini düzenli test ediyor musunuz ve RPO/RTO hedeflerinizle uyumlu mu?

Bu üçü net değilse, snapshot’ı “yedek” değil “hızlı rollback aracı” olarak kabul edin ve ayrıca gerçek backup katmanını (ayrı saklama + uzun retention + doğrulanmış restore) ekleyin. Böylece veri kaybı ve kesinti senaryolarında kararınız tahmine değil ölçüme dayanır.