SCNET · Kurumsal BT · Ankara, Türkiye

Sanal Çekirdek

Yedeğiniz var mı değil — geri dönebiliyor musunuz?

Veri koruma, kopya almakla değil geri dönebilmekle ölçülür. Sanal Çekirdek yedekleme mimarisini kurtarma hedeflerinden geriye doğru tasarlar: hangi veri ne kadar sürede, hangi noktaya geri dönecek.

Denenmemiş yedek, yedek değildir. Kopyanın varlığı raporlanabilir; geri yükleme yeteneği ancak denemeyle bilinir.

Kurtarma hedefleriyle başlamak

Tasarım, RPO (kabul edilebilir veri kaybı) ve RTO (kabul edilebilir kesinti) değerleriyle başlar. Bu iki sayı iş birimiyle birlikte belirlenir; teknoloji sonra seçilir. Tek bir hedef tüm sistemlere uygulanmaz — kritiklik sınıfı başına ayrı hedef tanımlanır.

  • Hedefler iş birimi imzasıyla sabitlenir
  • Kritiklik sınıfı başına ayrı RPO ve RTO
  • Hedefe ulaşılamayan sistemler açıkça listelenir
  • Maliyet, hedef sıkılaştıkça üstel artar — bu baştan konuşulur

Katmanlı saklama ve değiştirilemez kopya

Kopyalar tek yerde tutulmaz. Üretim yakınında hızlı geri dönüş için bir katman, farklı konumda bir katman ve fidye yazılımına karşı değiştirilemez (immutable) bir katman birlikte kurgulanır. Ayrıştırılmış kopya, üretim kimlik altyapısından bağımsız erişilir.

  • Değiştirilemez kopya silme ve şifreleme girişimine kapalıdır
  • Ayrıştırılmış kopyaya erişim ayrı kimlikle yapılır
  • Saklama süresi yasal ve iş gereksinimiyle eşleştirilir
  • Kopya sayısı ve konumu tek tabloda görünür

Geri yükleme denemesi ve kanıt

Geri yükleme yeteneği takvimli denemelerle ölçülür. Deneme yalnız dosya değil, uygulama seviyesinde yapılır: sistem ayağa kalkıyor mu, bağımlılıkları buluyor mu, veri tutarlı mı. Sonuç kanıtla birlikte kayda geçer.

  • Uygulama seviyesinde geri yükleme denemesi
  • Ölçülen süre hedefle karşılaştırılıp raporlanır
  • Başarısız deneme, düzeltme maddesi üretir
  • Kanıt denetim ve sigorta süreçlerinde kullanılabilir

Arşiv ve yaşam döngüsü

Yedek ile arşiv aynı şey değildir. Yedek geri dönüş içindir, arşiv saklama yükümlülüğü içindir. İkisi ayrı politikayla yönetilir; aksi hâlde saklama süresi dolan veri yedekte yaşamaya devam eder ve gereksiz hem maliyet hem risk üretir.

  • Yedek ve arşiv ayrı politika, ayrı süre
  • Süresi dolan veri planlı biçimde imha edilir
  • Arşiv erişimi yavaş ama tam olacak şekilde tasarlanır
  • İmha kaydı saklanır

Nasıl çalışırız

  1. Kritiklik sınıflarını ve kurtarma hedeflerini belirleyin
  2. Mevcut kapsamı ve boşlukları ölçün
  3. Katmanlı saklama mimarisini kurun
  4. Geri yükleme denemesini takvime bağlayın
  5. Sonuçları raporlayın, hedefleri gözden geçirin

Başarı nasıl ölçülür

  • Her kritik sistemin yazılı RPO ve RTO değeri var
  • Geri yükleme denemesi takvimde ve kanıtlı
  • Ölçülen kurtarma süresi hedefin içinde
  • Değiştirilemez kopya kapsamı büyüyor, boşluk küçülüyor

Sık sorulan sorular

Bulut yedeklemesi tek başına yeterli mi?

Konum çeşitliliği sağlar ama tek başına yeterli değildir. Belirleyici olan kopyanın değiştirilemez olması, erişimin üretim kimliğinden ayrılması ve geri yükleme süresinin hedefi karşılamasıdır.

Ne sıklıkta geri yükleme denemesi yapılmalı?

Kritiklik sınıfına göre değişir; en kritik sistemler için düzenli ve takvimli, diğerleri için daha seyrek. Önemli olan sıklık kadar denemenin uygulama seviyesinde yapılması ve sonucun kayda geçmesidir.

Fidye yazılımına karşı yedek yeterli mi?

Yedek gerekli ama tek başına yetmez. Saldırgan çoğu zaman önce yedeği hedefler; bu yüzden değiştirilemez kopya, ayrıştırılmış erişim ve temiz kurtarma ortamı birlikte gerekir.

Yedeğinizin geri döndüğünü son ne zaman denediniz? Kurtarma hedeflerinizi paylaşın, mevcut kapsamı birlikte ölçelim.

Kurtarma hedeflerinizi ölçelim