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

Snapshot (anlık görüntü) yedekleme; özellikle VDS/VPS tarafında hızlı kurtarma sağlayan pratik bir mekanizmadır. Yine de “snapshot aldım, backup bitti” yaklaşımı çoğu senaryoda doğru değildir. Bu rehberde snapshot’ın neyi doğru yaptığını, neyi yapamadığını ve gerçek backup ile farklarını net kriterlerle inceleyeceksiniz. Son bölümde ise kendi ortamınıza uygun net bir plan şablonu çıkaracağız.

Snapshot nedir, nasıl “yedek” sayılır?

Snapshot, belirli bir zaman noktasındaki disk durumunun (OS dahil kurulum dosyaları, veritabanı dosyaları vb. içeriğe bağlı olarak) kopya mantığıyla saklanmasıdır. Sağlayıcı altyapısında çoğu zaman depolama seviyesinde “copy-on-write” mantığıyla ilerler; bu sayede ilk alım sonrası depolama maliyeti daha düşük kalabilir ve geri dönüş hızlı olur.

Snapshot’ın güçlü olduğu kullanım alanları: - Hızlı geri dönüş: Sistem üzerinde yapılan değişiklik (yükseltme, paket kurulumları, konfig değişikliği) sonrası birkaç dakika/tenlerde eski duruma dönmek. - Geliştirme/staging benzeri işler: Sık değişen ortamda deneme-yanılma. - Uygulama düzeyinde değil, disk düzeyi kurtarma: Fail durumunda “sunucu açılır hale gelsin” hedefi.

Snapshot’ın zayıf kaldığı kullanım alanları: - Veri bütünlüğü ve uygulama tutarlılığı: Uygulamanın disk üzerindeki yazma işlemleri devam ederken snapshot almak, dosya sistemi veya veritabanı tutarlılığı açısından sorun çıkarabilir. - Büyük ölçekli felaket kurtarma: Depo bölgesi, hesap, erişim, silme/şifreleme gibi durumlarda snapshot tek başına yeterli olmayabilir. - Uygulama/altyapı bağımsızlığı: Gerçek backup, genellikle bağımsız saklama lokasyonunda ve erişim/erişilebilirlik kontrolüyle planlanır.

Snapshot ile “backup” arasındaki temel fark

Net bir ayrım yapmak gerekirse: - Snapshot, genellikle aynı altyapı hesabı ve aynı disk bağlamı içinde hızlı geri dönüş sağlar. - Gerçek backup ise verinin kopyasının bağımsız şekilde saklanması, şifrelenmesi, versiyonlanması, mümkünse farklı lokasyonda tutulması ve düzenli olarak kurtarma testi yapılması anlamına gelir.

Bu yüzden snapshot “yedek” kelimesini çağrıştırsa da, backup stratejisinin tamamını tek başına oluşturmaz.

Snapshot hangi durumlarda yeterli olabilir?

Aşağıdaki checklist snapshot’ın tek başına “yeterli” sayılabileceği durumları gösterir. Şu maddelerin tamamı sağlanıyorsa snapshot, geçici kurtarma ihtiyacı için pratik olabilir.

• Hedefin hızlı sistem geri dönüşü olması (saatler yerine dakikalar).
• Snapshot geri dönüşünden sonra uygulama/veritabanının tutarlı çalıştığının doğrulanması.
• Snapshot’ların uzun süre tutulması: örn. en az 14-30 gün; daha da önemlisi kritik veriler için daha uzun retensiyon.
• Snapshot’ın kazara silinmeye veya aynı hatada etkilenmeye karşı korunması.
• Aynı hesabın/altyapının etkilenmesi halinde snapshot’ın da etkilenmeyecek olduğunun doğrulanması (ör. erişim/şifreleme felaketinde durum).

“Uygulama tutarlılığı” kritik bir eşik

Özellikle MySQL/PostgreSQL gibi veritabanlarında, snapshot almak sadece dosyaları kopyalamak değildir. Veritabanı içinde transaction akışı varken snapshot alınırsa recovery süreci uzayabilir ya da kurtarma sonrası veri bütünlüğü sorgulanabilir.

Net hedef şudur: - Snapshot alımı öncesinde veritabanı için uygulama düzeyinde tutarlı an (quiesce) sağlamak - Sağlayıcı snapshot’ı “uygulama tutarlılığı” ile sunmuyorsa, kendi tarafında dump (dışa aktarım) ve/veya backup agent kurgusu yapmak

Snapshot ne zaman gerçek backup değildir?

Snapshot’ın “yedek” sayıldığı ama backup ile aynı güveni vermediği senaryoları netçe ayıralım.

1) Ransomware / veri şifreleme

Ransomware, dosya sistemini ve veritabanını şifreleyebilir. Snapshot almış olmanız, şifreleme sonrası snapshot’u aynı diskten yönetiyorsanız geri dönüşü hızlandırır; fakat pratikte şu riskler vardır: - Saldırıdan sonra snapshot alınmaya devam ederse “temiz” nokta kaybolur. - Saldırı hesabın kontrolünü ele geçirirse snapshot’lar da silinebilir veya bozulabilir.

Net sonuç: Ransomware senaryosunda snapshot tek başına “güvenli kurtarma” garantisi vermez. Versiyonlu, şifreli, erişimi kısıtlı ve ayrı lokasyonda saklanan backup gereklidir.

2) Hesap/erişim kaybı

Snapshot aynı yönetim alanında durur. Hesap askıya alma, yetki kaybı, sağlayıcı değişikliği gibi durumlarda snapshot erişimi kesilebilir.

Net sonuç: Bağımsız saklama (farklı hesap/lokasyon) olmadan snapshot, felaket kurtarma planını tamamlamaz.

3) Yanlış silme / hatalı konfig

Bir kullanıcı yanlışlıkla veri klasörünü silerse veya yanlış konfig ile uygulama bozulursa snapshot geri getirir. Ancak problem, hatanın keşfi gecikirse olur: - Snapshot retensiyonu kısa ise temiz nokta kalmayabilir. - Aynı hatayı takiben yeni snapshot’lar alınırsa “geri dönüş” karmaşıklaşır.

Net sonuç: Snapshot faydalıdır; fakat versiyonlama süresi backup stratejisinin bir parçasıdır.

4) Uygulama düzeyi geri getirme ihtiyacı

Snapshot, genellikle “tüm disk” geri getirir. Oysa çoğu ekip şu ihtiyacı yaşar: - Belirli bir dosyayı geri alma - Belirli bir tarihteki veritabanı içinden tek tabloyu düzeltme - Uygulama kapatmadan belirli bir zaman noktasından geri dönüş

Net sonuç: Dosya/DB seviyesinde erişim sağlayan backup yöntemleri (dışa aktarım, dosya arşivi, uyumlu yedek ajantları) olmadan snapshot pratikte sınırlı kalır.

Snapshot + gerçek backup nasıl birlikte planlanır?

En sağlıklı yaklaşım çoğu kurulum için “katmanlı kurtarma”dır: Snapshot hızlı geri dönüş sağlar, gerçek backup ise uzun süreli ve bağımsız kurtarma sağlar.

Karar matrisi: Snapshot mı, gerçek backup mı?

Aşağıdaki tabloyu birebir kullanın.

Net uygulama planı (adım adım)

Aşağıdaki plan, “snapshot alıyoruz” diyen ekipleri backup olgunluğuna taşır.

1) Hedef RPO/RTO değerlerini yazın

RPO (Recovery Point Objective): Veri kaybının kabul edilebilir maksimum süresi. RTO (Recovery Time Objective): Hizmetin geri gelmesi gereken maksimum süre.

Net örnek: - E-ticaret: RPO 1-4 saat, RTO 1-2 saat - İç proje: RPO 24 saat, RTO 24 saat

Bu değerler hangi tür backup’ın gerektiğini belirler.

2) Snapshot’ı “hız katmanı” yapın

• Snapshot’ı değişiklik öncesi alın: güncelleme, paket ekleme, konfig değişikliği.
• Retention süresini kritik ihtiyaçla uyumlu tutun (örn. 7-14 gün).
• Snapshot alımı sonrası uygulamayı doğrulayın: web erişimi, servis durumu, loglarda hata.

3) Gerçek backup’ı “bağımsız katman” yapın

En az şu üç özelliği kurun: - Şifreli saklama (encryption): Yedekler disk üzerinde şifreli, mümkünse anahtar yönetimi kontrollü. - Versiyonlama: Aynı dosyanın/kayıtların zaman içi versiyonları. - Farklı lokasyon/hedef: En azından aynı sunucunun/aynı hesabın etkilenmesine karşı korumalı.

Net kontrol: - Yedek dışa aktarımı otomatik mi? - Retention (tutma süresi) net mi? - Şifre çözme için yetkiler kısıtlı mı?

4) Restore (geri yükleme) testini takvime bağlayın

Snapshot “aldım” demek yetmez; “geri getirebiliyorum” kanıtlanmalı.

Net test planı önerisi: - Aylık: Son yedeklerden birini restore et ve uygulamayı doğrula. - Değişiklik sonrası: Büyük sürüm güncellemelerinde hem snapshot geri dönüşünü hem de bir backup restore yolunu test et.

Test çıktısı olarak şunları kaydedin: - Geri yükleme süresi - Hizmete dönüş zamanı - Veri tutarlılığı kontrolü (DB kontrol sorguları) - Loglarda kritik hata var mı?

5) Yetkilendirme ve erişim kontrolü

Snapshot veya backup’ta en sık kaçırılan konu erişimdir. - Yedek işlemlerini yapan hesapların yetkisini daraltın. - Yedek dosyalarına genel admin erişimi vermeyin. - Şifre/anahtarların (encryption key) erişimini ayrı yönetim sürecine bağlayın.

Snapshot stratejisinde dikkat edilmesi gereken somut noktalar

Snapshot kararını verirken şu teknik sorulara net cevap alın:

Sağlayıcı snapshot’ları nasıl yönetiyor?

• Snapshot’lar retention ile otomatik siliniyor mu?
• Snapshot alımı performansı etkiliyor mu (yüksek I/O dönemlerinde)?
• Snapshot geri dönüşte tam disk mi dönüyor, yoksa dosya/DB seçerek mi?

Uygulama tutarlılığı nasıl sağlanıyor?

• Veritabanı için “tutarlı an” mekanizması var mı?
• Sağlayıcının önerdiği yöntem dokümante edilmiş mi?

Yedekler şifreli mi ve kim erişiyor?

• Yedekler sağlayıcı tarafında mı şifreleniyor, yoksa müşteri tarafında mı?
• Şifre çözme anahtarı nerede tutuluyor?

Sonuç: Snapshot tek başına backup değildir; planı katmanlı kurun

Snapshot, hızlı kurtarma için güçlü bir araçtır; ancak veri bütünlüğü, erişim kaybı ve felaket kurtarma gibi senaryolarda “gerçek backup” gerekliliğini ortadan kaldırmaz. Net aksiyon planı: Değişiklik öncesi snapshot kullanın, süre/şifreleme/bağımsızlık içeren versiyonlu backup kurun ve restore testini aylık takvime bağlayın. Bunu yaptığınızda hem dakikalar içinde toparlanırsınız hem de günler/haftalar sonra bile doğrulanabilir geri dönüş elde edersiniz.