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

Snapshot yedekleme, birçok VDS/VPS ortamında pratik bir kurtarma yolu sunar. Ancak "snapshot" kelimesi her zaman "gerçek backup" ile aynı anlama gelmez. Asıl fark; verinin ne zaman kopyalandığı, kopyanın nerede saklandığı, ne kadar süre tutulduğu ve en önemlisi geri dönüş (restore) testinin gerçekten yapılmış olup olmadığıdır. Bu rehberde snapshot ile backup arasındaki teknik farkları net ölçütlerle ele alacak; hangi senaryoda snapshot yeterli, hangi durumda yetersiz kalır sorusunu somutlaştıracağız.

Snapshot nedir, backup nedir? Aynı şey mi?

Snapshot (anlık görüntü) genel olarak bir depolama biriminin belli bir zaman noktasındaki durumunu kopyalar. Bu sayede VM açılışından sonra oluşan değişiklikleri geri almak veya belirli bir anı yakalamak kolaylaşır.

Gerçek backup ise yalnızca anlık kopya değil; belirli bir saklama (retention) süresi boyunca, farklı bir ortamda ve tekrar tekrar test edilebilir şekilde tutulan kurtarma verisidir. Ayrıca backup yaklaşımı genellikle; otomatik alma sıklığı, şifreleme, bütünlük kontrolü, sürümleme (versioning) ve gerektiğinde tüm sistemin veya verinin hızlı geri yüklenmesini kapsar.

Snapshot tek başına "backup" gibi algılansa da, çoğu altyapıda şu noktalar kritik farktır: - Saklama süresi: Snapshot’lar çoğu zaman kısa süre tutulur veya depolama maliyeti nedeniyle otomatik silinir. - Kurtarma kapsamı: Bazı snapshot’lar sadece disk içeriğini kapsar; uygulama/konfigürasyon/DB tutarlılığı garanti etmeyebilir. - Bağımlılık: Snapshot aynı fiziksel altyapı/hesaplama kümesi içinde duruyorsa, belirli bir arıza veya yanlış silme (self-delete) senaryosunda tek başına yetmeyebilir. - Restore testleri: Snapshot kullanmak, geri yüklemeyi gerçekten test etmek anlamına gelmez.

Snapshot hangi durumda “hızlı geri alma” işlevi görür?

Aşağıdaki durumlarda snapshot pratik bir emniyet sağlar: - Güncelleme/konfigürasyon değişikliği öncesi deneme yapmak - Kontrol panelinde (ör. cPanel/DirectAdmin) veya uygulamada test yapmak - Küçük veri kaybı toleransı olan değişiklikleri geri almak

Burada amaç genellikle aynı gün içi veya kısa aralıkta geri dönüş gereksinimidir.

Gerçek backup hangi durumda “kurtarma planı” olur?

Gerçek backup şu şartları karşılar: - Belirli bir süre boyunca saklanır (ör. 30/60/90 gün) - Farklı arıza senaryolarına karşı bağımsızlık sağlar (ör. hesap/VM silinmesi, veri merkezi arızası) - Restore edilebilirlik düzenli test edilir - Uygulama seviyesinde tutarlılık hedeflenir (özellikle veritabanında)

Snapshot vs gerçek backup: Net karşılaştırma ölçütleri

Aşağıdaki tablo, karar vermeyi kolaylaştırmak için kritik boyutları yan yana koyar.

RPO ve RTO: “Snapshot yeter mi?” sorusunun matematiği

Snapshot’ın backup yerine geçip geçmediğini anlamanın en pratik yolu, iki metriği netleştirmektir:

• RPO (Recovery Point Objective): Kurtarma sırasında kabul edilebilir maksimum veri kaybı.
• RTO (Recovery Time Objective): Hizmetin geri dönmesi için kabul edilebilir maksimum süre.

Örnekle netleştirelim: - Snapshot’lar günde 1 kez alınıyorsa: RPO fiilen yaklaşık 24 saattir. Bu da saatler içinde oluşabilecek veri kaybını tolere ettiğiniz anlamına gelir. - Snapshot’lar saatlik alınıyorsa: RPO daha düşer.

Ancak tek başına “snapshot saatliği var” demek yetmez. Snapshot restore sonrası uygulamanın tutarlılığı ve DB seviyesinde veri bütünlüğü sağlanıyor mu, değerlendirilmelidir.

DB (veritabanı) için snapshot’ın kritik riski: tutarlılık

Dosya sistemi snapshot’ı, veritabanı için her zaman tutarlı bir anı garanti etmeyebilir. Özellikle şu durumlar risk doğurur: - Veritabanı yazma işlemi devam ederken snapshot alınır - Uygulama cache katmanı veya arka plan job’ları snapshot sonrası yeniden senkronize olmaz

Bu nedenle DB için şu kontroller önemlidir: - Sağlayıcının snapshot öncesi/sonrası uygulama veya DB quiesce (bekletme) özelliği var mı? - Uygulama seviyesinde tutarlılık için farklı yöntem (ör. DB dump + ayrı backup) kullanılıyor mu?

Snapshot tek başına neden yetmeyebilir? (Somut senaryolar)

Aşağıdaki senaryolarda snapshot’ın “tek çözüm” olmasının riskini açıkça görürsünüz.

1) Yanlışlıkla silme veya şifreleme (ransomware)

Ransomware senaryosunda kritik olan şey, saldırı başlar başlamaz alınmış bir snapshot’ın bulunmasıdır. - Snapshot’lar daha seyrek alınıyorsa saldırı sonrası snapshot yoksa, geri dönüşte şifrelenmiş/bozulmuş veriler geri gelebilir. - Snapshot’lar sadece aynı VM diskini geri getiriyorsa, uygulama dosyaları ve DB aynı anda bozulduysa çözüm zorlaşır.

Burada “snapshot var” demek tek başına yeterli değildir. Saldırıya karşı ayrı lokasyonda, ayrı sürümlerde saklanan backup şarttır.

2) Hatalı konfigürasyon değişikliği uzun sürer

Bir konfigürasyon değişikliğini fark etmek zaman alabilir. - Snapshot’lar kısa aralıklarla alınmıyorsa, hatayı fark ettiğiniz andan önceki iyi durumla geri dönüş mümkün olmayabilir.

3) Ölçek büyümesi ve değişen veri kritikliği

İş büyüdükçe veri kaybı toleransı düşer. - Örneğin başlangıçta “günde 1 snapshot” kabul edilebilirken, sonra sipariş/puan/oturum gibi kritik veriler gelmeye başlar. - Snapshot yaklaşımı zamanla yetmez hale gelir; planlı backup retentions ve DB tutarlılığı güncellenmelidir.

Ne zaman snapshot “backup yerine geçer”? Net kriterler

Snapshot’ın tek başına yeterli kabul edilebilmesi için şu koşullar birlikte aranmalıdır: - Saklama süresi en az ihtiyacınız kadar uzun olmalıdır (kısa dönem test ortamları dışında 7 günden kısa saklama çoğu üretim senaryosunda risklidir). - Snapshot frekansı RPO hedefinizi karşılamalıdır (ör. kritik veri için saatlik; çok daha kritik işlerde daha sık). - Restore süreci düzenli test edilmelidir (en az aylık kontrollü restore/ doğrulama). - DB veya uygulama tutarlılığı için sağlayıcının sunduğu yöntemler veya sizdeki süreçler yeterli olmalıdır. - Snapshot’ın bozulması veya yanlışlıkla silinmesi riskine karşı ikinci bir katman bulunmalıdır (en azından ayrı lokasyonda dump/backup).

Üretim (production) için pratik kural

Üretim ortamında snapshot genellikle tek katman olmamalıdır. En azından: - Snapshot: değişiklik öncesi hızlı rollback - Gerçek backup: uzun saklama + restore testi + DB tutarlılığı

Bu ikili yapı, hem operasyon hızını hem de felaket senaryosu dayanıklılığını birlikte yönetir.

İyi bir plan nasıl kurulur? Snapshot + backup mimarisi

Aşağıdaki plan, VDS/VPS üzerinde çalışan çoğu web sitesi ve uygulama için uygulanabilir bir başlangıç çerçevesidir.

1) RPO/RTO hedeflerini yazın

Örnek hedefler: - RPO: 1 saat (en fazla 60 dk veri kaybı) - RTO: 2 saat (hizmet geri dönüşü)

Bu hedefler, snapshot sıklığını ve backup türlerini belirler.

2) Snapshot sıklığını ihtiyaca göre ayarlayın

Örnek yaklaşım: - Konfigürasyon ve uygulama değişikliği öncesi: anlık snapshot - Günlük üretim akışı: saatlik (veya daha sık) snapshot

3) DB için ayrı tutarlılık katmanı kurun

• Veritabanı (MySQL/MariaDB/PostgreSQL) için düzenli dump (örn. logical backup) veya sağlayıcı destekliyse tutarlı snapshot + doğrulama tercih edin.
• Dump’ların restore edilebilirliğini test edin.

4) Backup saklama (retention) politikasını netleştirin

Örnek retention: - 7 gün: günlük - 30 gün: haftalık - 90 gün: aylık

Buradaki değerler iş ihtiyacınıza göre değişir; önemli olan “neden bu kadar” diye açıklanabilir bir politika olmasıdır.

5) Restore testini “prosedür” haline getirin

Restore testi yapmadan “backup var” demek eksiktir. Basit bir prosedür: - Aylık bir günde örnek bir snapshot/backup seç - Farklı bir ortamda veya test VM’inde restore et - Uygulama doğrulaması yap (ör. DB’de kritik tablolar, uygulama giriş akışı)

Bu test, gerçek anlamda felaket anında zaman kaybını azaltır.

NetKıyas’ta değerlendirirken kontrol listesi

Snapshot yedekleme ile gerçek backup karşılaştırması yaparken şu soruları her sağlayıcı için net yanıtlayın:

• Snapshot’lar ne sıklıkla alınır ve maksimum saklama süresi nedir?
• Snapshot restore işlemi hangi seviyede yapılır: tüm VM mi, sadece disk mi?
• DB tutarlılığı için uygulama durdurma/quiesce gibi bir mekanizma var mı?
• Backup için retention (30/60/90 gün) sunuluyor mu?
• Backup’lar ayrı lokasyonda/ayrı depolama katmanında mı saklanır?
• Restore hızı ve geçmiş restore kayıtları mevcut mu?
• Şifreleme ve bütünlük doğrulaması (checksum vb.) var mı?

Bu maddeler, “snapshot yeter mi?” sorusunu duyguya değil ölçüme bağlar.

Sonuç: Snapshot, tek başına gerçek backup değildir

Snapshot, özellikle konfigürasyon değişikliği öncesi hızlı rollback için güçlü bir araçtır; ancak felaket kurtarma için tek başına “gerçek backup” yerine geçmez. Karar vermenizi belirleyen şey; snapshot sıklığı ve saklama süresi (RPO), restore süreniz (RTO), DB tutarlılığı ve en önemlisi restore testinizdir.

Aksiyon önerisi: Üretim sisteminiz için en az iki katman kurgulayın: snapshot (hızlı geri alma) + uzun saklamalı, bağımsız ve restore testi yapılmış gerçek backup. Hedeflediğiniz RPO/RTO değerlerini yazın, ardından sağlayıcıdan saklama ve restore doğrulamasını bu ölçütlere göre teyit edin. Böylece snapshot varlığından değil, gerçekten geri dönebildiğiniz veri katmanından emin olursunuz.