KVKK için VMware disaster recovery tasarlamak, yalnız ikinci lokasyona birkaç sanal makine kopyalamak değildir. Savunulabilir model; kişisel veri içeren iş yüklerini önceliklendirmek, kabul edilen veri kaybını netleştirmek, site eşleşmesini doğru kurmak, kurtarma sırasını yazılı hale getirmek ve düzenli test failover ile planı doğrulamaktan oluşur. Kısa cevap şudur: KVKK açısından güçlü bir VMware disaster recovery modeli, RPO, RTO, replication, recovery plan, test ve erişim kontrolünü aynı yönetişim zinciri içinde işletir.
Bu rehber özellikle şu ekipler içindir:
- VMware ve vSphere yöneticileri
- KVKK uyumundan sorumlu BT ve bilgi güvenliği ekipleri
- iş sürekliliği ve felaket kurtarma planlama ekipleri
- denetimde savunulabilir kurtarma kanıtı oluşturmak isteyen yöneticiler
Hızlı Özet
- KVKK'nın veri güvenliği çerçevesi, yalnız erişim kontrolünü değil; yedekleme, süreklilik, denetim ve düzenli kontrol mekanizmalarını da teknik tedbir setinin parçası olarak ele alır.
- Broadcom KB
396746, VMware Live Recovery ortamında protected ve recovery site arasında eşleştirmeninsite pairingakışıyla kurulduğunu açıkça tarif eder. - Broadcom KB
317497, vSphere Replication tarafında5 minute RPOkullanımının belirli depolama tiplerinde mümkün olduğunu ve düşük RPO tasarımının ölçek sınırlarıyla düşünülmesi gerektiğini gösterir. - Broadcom KB
435061, aynı recovery plan içindeki birden fazla protection group için failover sırasının protection group seviyesinde değil, sanal makinelerinPriority Groupsve bağımlılıklarına göre çalıştığını söyler. - Broadcom KB
334941, recovery plan test edilmeden doğrudan gerçek DR çalıştırmanın başarısızlık riski taşıdığını gösterir; bu yüzden test failover operasyonel zorunluluktur. - KVKK açısından güçlü model, replication ile hızlı geri dönüşü ve yedekleme ile daha güvenilir geri yükleme katmanını birlikte ele almalıdır.
İçindekiler
- KVKK Açısından VMware Disaster Recovery Neyi Kapsar?
- RPO, RTO ve İş Yükü Önceliği Nasıl Belirlenir?
- Site Pairing ve Replication Katmanı Nasıl Kurulur?
- Recovery Priority ve Test Failover Neden Kritik?
- En Sık Yapılan Hatalar Nelerdir?
- İlgili İçerikler
- Kontrol Listesi
- LeonX ile Sonraki Adım
- Sık Sorulan Sorular
- Kaynaklar
Görsel: Wikimedia Commons - Half filled server racks.
KVKK Açısından VMware Disaster Recovery Neyi Kapsar?
KVKK bakımından disaster recovery, sadece sistemleri ayağa kaldırmak değil; kişisel veriyi doğru kapsamda, doğru bütünlükle ve yetkisiz erişim oluşturmadan geri döndürmek anlamına gelir. Bu yüzden DR tasarımı şu sorulara net cevap vermelidir:
- hangi sanal makineler kişisel veri açısından kritik
- hangi iş yükü ne kadar sürede geri dönmeli
- hangi veri kaybı seviyesi kabul edilebilir
- kurtarma sürecini kim başlatabilir
- geri dönüş sonrası veri bütünlüğü nasıl doğrulanır
KVKK veri güvenliği yaklaşımı, düzenli denetim ve uygun teknik-idari tedbir vurgusu yaptığı için VMware disaster recovery modeli de sadece ürün kurulumu değil, kontrol tasarımı olarak ele alınmalıdır.
Bu nedenle ana hizmet ekseninde Donanım & Yazılım Hizmetleri ile teknik katman; strateji katmanında ise Felaket Kurtarma Stratejisi DR Oluşturma bir arada düşünülmelidir.
RPO, RTO ve İş Yükü Önceliği Nasıl Belirlenir?
RPO neden yalnız teknik ayar değildir?
Broadcom KB 317497, vSphere Replication içinde 5 minute RPO desteğinin belirli koşullarda kullanılabildiğini ve düşük RPO tasarımının korunan VM sayısı ile birlikte değerlendirilmesi gerektiğini söyler. Bu şu anlama gelir:
- her VM için aynı RPO hedefi vermek doğru olmayabilir
- düşük RPO, daha yüksek kaynak ve operasyon disiplini gerektirir
- kritik kişisel veri içeren iş yükleri ile düşük kritik iş yükleri ayrı ele alınmalıdır
RTO nasıl düşünülmelidir?
KVKK perspektifinde yalnız veri kaybı değil, erişilebilirlik ve süreklilik de önemlidir. Bu yüzden:
- kimlik servisleri
- veritabanları
- uygulama katmanı
- vCenter ve yönetim servisleri
hangi sırayla ayağa kalkacak, yazılı hale getirilmelidir.
Önceliklendirme neden kanıt üretir?
Denetimde “neden bu VM önce ayağa kaldırılıyor?” sorusuna iş etkisi ve veri kritiklik temelli cevap verebilmek gerekir. Bu da DR planını savunulabilir hale getirir.
Site Pairing ve Replication Katmanı Nasıl Kurulur?
Site pairing temel adımdır
Broadcom KB 396746, VMware Live Recovery tarafında protected ve recovery site'ın site pairing ile bağlandığını açıkça anlatır. Eşleşme kurulmadan replication ve recovery plan katmanı sağlıklı çalışmaz.
Pratikte doğru model şu başlıkları içerir:
- protected ve recovery vCenter ayrımı
- eşleşen servislerin doğru seçimi
- kimlik ve sertifika güveninin doğrulanması
- replikasyon hedeflerinin yazılı hale getirilmesi
Replication tek başına DR değildir
Replication, veri taşıma katmanıdır; fakat planın tamamı değildir. RPO violation, uyumluluk ve hedef datastore erişimi gibi durumlar replikasyonun bozulabileceğini gösterir. Bu nedenle replication katmanının yanında mutlaka:
- yedekleme politikası
- kurtarma runbook'u
- test senaryosu
- gözden geçirme periyodu
olmalıdır.
Bu noktada Yedekleme, İzleme, Raporlama ve Geri Yükleme Yönetimi hizmeti, replication ile backup katmanını birlikte ele almak için doğrudan ilgilidir. Sanallaştırma standardı tarafında Kurumsal Sanallaştırma Platformları Satış ve Lisanslama ile platform tasarımı tamamlanabilir.
Recovery Priority ve Test Failover Neden Kritik?
Recovery priority nasıl çalışır?
Broadcom KB 435061, aynı recovery plan içindeki birden fazla protection group için failover sırasının protection group sınırlarına göre değil, recovery plan içindeki VM Priority Groups ve dependency tanımlarına göre çalıştığını söyler.
Bu çok kritik bir ayrıntıdır; çünkü ekipler çoğu zaman “grup A önce, grup B sonra” varsayımıyla plan kurar. Oysa gerçek davranış VM seviyesindeki öncelik ve bağımlılıklara dayanır.
Bu yüzden DR planında şu başlıklar yazılı olmalıdır:
- önce açılacak kritik servis grubu
- bağımlı uygulama zincirleri
- ağ ve DNS hazırlık sırası
- failback yaklaşımı
Test failover neden zorunludur?
Broadcom KB 334941, recovery plan test edilmeden gerçek DR çalıştırmanın hata riski taşıdığını açıkça gösterir. Bu, KVKK açısından da önemlidir; çünkü test edilmemiş plan, olay anında kişisel veriye erişilebilirliği ve bütünlüğü riske atabilir.
Sağlıklı model şunları içerir:
- düzenli test failover takvimi
- test sonrası düzeltici aksiyon kaydı
- gerçek ve test kurtarma sonuçlarının arşivlenmesi
- kritik VM'ler için uygulama seviyesinde doğrulama
En Sık Yapılan Hatalar Nelerdir?
Tüm VM’lere aynı RPO vermek
Kritik ve kritik olmayan iş yüklerini ayırmadan yapılan replikasyon, gereksiz yük ve zayıf önceliklendirme üretir.
Replication varsa backup gereksiz sanmak
Replication hızlı geri dönüş sağlar; fakat bozuk veya şifrelenmiş veriyi de taşıyabilir. Bu yüzden yedekleme katmanı ayrıca gereklidir.
Protection group sırasını gerçek açılış sırası sanmak
Broadcom'a göre gerçek açılış davranışı priority ve dependency tabanlıdır.
Test failover yapmamak
Kağıt üstünde çalışan plan, gerçek ortamda ağ veya servis bağımlılığı yüzünden başarısız olabilir.
DR yetkilerini belirsiz bırakmak
Kurtarma işlemini kimin başlatacağı ve kimin onay vereceği yazılı değilse hem operasyon hem denetim zayıflar.
İlgili İçerikler
- VMware Disaster Recovery Nasıl Kurulur? Adım Adım Rehber
- KVKK için Storage Disaster Recovery Rehberi
- KVKK için VMware Loglama Nasıl Yapılır?
- VMware KVKK Teknik Tedbirler Rehberi
Kontrol Listesi
- kişisel veri içeren VMware iş yükleri kritiklik seviyesine göre sınıflandırıldı
- her kritik VM grubu için
RPOveRTOhedefi yazılı hale getirildi - protected ve recovery site pairing yapısı doğrulandı
- replication, backup ve restore rolleri ayrı tanımlandı
- recovery plan içindeki priority ve dependency yapısı test edildi
- düzenli test failover takvimi ve sonuç kayıtları oluşturuldu
- DR başlatma/onay yetkileri yazılı hale getirildi
- denetimde kullanılacak kurtarma kanıt seti hazırlandı
LeonX ile Sonraki Adım
KVKK için VMware disaster recovery, yalnız replication kurmak değildir; kişisel veri içeren iş yükleri için sıralı kurtarma, düşük veri kaybı, test edilmiş failover ve denetlenebilir kanıt üretimi sağlamaktır. LeonX, Donanım & Yazılım Hizmetleri altında özellikle Yedekleme, İzleme, Raporlama ve Geri Yükleme Yönetimi ve Kurumsal Sanallaştırma Platformları Satış ve Lisanslama hizmetleriyle teknik katmanı kurar; strateji tarafında Felaket Kurtarma Stratejisi DR Oluşturma ile runbook ve öncelik modelini netleştirir. Ortamınızı değerlendirmek veya teklif almak için İletişim sayfasından ilerleyebilirsiniz.
İlgili sayfalar:
- Donanım & Yazılım Hizmetleri
- Yedekleme, İzleme, Raporlama ve Geri Yükleme Yönetimi
- Felaket Kurtarma Stratejisi DR Oluşturma
- İletişim
Sık Sorulan Sorular
KVKK için VMware disaster recovery ile normal VMware DR arasında fark var mı?
Evet. KVKK bağlamında kişisel veri bütünlüğü, erişim kontrolü ve denetim kanıtı daha görünür şekilde tasarlanmalıdır.
Replication tek başına yeterli midir?
Hayır. Replication, DR katmanının önemli parçasıdır ama backup, test ve onay akışı olmadan tek başına yeterli değildir.
Test failover gerçekten zorunlu mu?
Evet. Broadcom'un da gösterdiği gibi test edilmemiş recovery plan, gerçek olayda başarısız olabilir.
Recovery priority nasıl belirlenmelidir?
Kritik uygulama bağımlılıkları, kimlik servisleri, veri katmanı ve iş etki analizi birlikte değerlendirilmelidir.
Kaynaklar
- KVKK - Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler)
- KVKK - Veri Güvenliğine İlişkin Yükümlülükler
- Broadcom KB 396746 - How to connect the VMware Live Recovery Instances between Protected and Recovery Sites
- Broadcom KB 317497 - Operational Limits for vSphere Replication 8.x
- Broadcom KB 435061 - Configuring recovery priority for multiple protection groups within a single recovery plan
- Broadcom KB 334941 - Running SRM Planned/Test Failover fails
- Wikimedia Commons - Half filled server racks
