Bulut Yedekleme Nedir, Kurumsal Yedekleme Nasıl Kurgulanır?

“Yedekleme yapılıyor” sanılır, ama BT ekiplerinin çoğu zaman yaptığı şey senkronizasyondur. Senkronize edilen bir dosya silinir ya da fidye yazılımıyla şifrelenirse, kopyası da aynı anda silinir ve şifrelenir. Bu yazı, bulut yedekleme kurgusunu üç somut soruya indiriyor: ne kadar veri kaybını göze alabilirsiniz, sistem kapalıyken ne kadar süre tolere edebilirsiniz ve yedeğiniz saldırganın erişebildiği ağda mı duruyor. Cevaplar RPO, RTO ve “ağ dışılık” kavramlarında saklı; üçü de aşağıda tek tek ölçülebilir hâle geliyor. Bu üç kavramı yazılı hâle getirmeden alınan hiçbir yedekleme teklifi karşılaştırılabilir değildir, çünkü fiyat farkının nereden geldiğini anlamak da bu sayılara bakmadan mümkün olmuyor.

Bulut Yedekleme Nedir?

Bulut yedekleme, sunucu ve son kullanıcı cihazlarındaki verilerin belirli aralıklarla kopyalanarak kurum ağının dışındaki bir veri merkezinde, geri yüklenebilir sürümler hâlinde saklanmasıdır. Amacı dosyaya her yerden erişmek değil, veri kaybedildiğinde ölçülebilir bir süre içinde geçmiş bir ana dönebilmektir. (İngilizcesi backup; bulutta yapılan sürümüne ise cloud backup denir.)

Yedekleme nedir sorusuna verilen cevap çoğu zaman arşivlemeyle karışıyor; oysa ikisinin amacı farklıdır. Yedek, bir olaydan sonra geri dönmek içindir; arşiv ise erişim sıklığı düşük veriyi uzun süre saklamak içindir. Dolayısıyla “arşivimiz var, yedeğimiz de sayılır” varsayımı çoğu kurumda yanlış çıkar: arşiv geri yükleme hızı ve sürüm derinliği için tasarlanmamıştır. Pratikte bu fark şöyle ortaya çıkar: bir arşivden tek bir e-postayı dakikalar içinde bulup geri getirmek genellikle mümkün değildir, çünkü arşivleme sistemleri hacim ve maliyet için optimize edilmiştir, hız için değil.

Bulut Yedekleme ile Bulut Depolama ve Senkronizasyon Aynı Şey Değildir

Bulut depolama dosyanın güncel hâlini tutar, bulut yedekleme ise dosyanın geçmiş sürümlerini tutar. Senkronizasyon bir değişikliği tüm kopyalara yayar; bu yüzden silinen veya şifrelenen bir dosya, senkronize edilmiş kopyalarda da silinir ve şifrelenir.

Aradaki fark üç teknik unsurda somutlaşır: sürüm geçmişi (dosyanın kaç eski hâline dönülebildiği), saklama penceresi (retention, bu sürümlerin ne kadar süre tutulduğu) ve geri yükleme granülerliği (tek bir dosyanın mı yoksa tüm sunucunun mu geri yüklenebildiği). Tüketici sınıfı senkronizasyon servisleri genellikle bu üçünde de sınırlıdır; “klasörümü buluta atıyorum, yedeğim var” yanılgısı tam olarak burada kırılıyor. Bir dosya sistemi genelinde şifrelenirse, senkronizasyon o şifreli hâli de üretim ağının dışına taşımadan, aynı hesap altında çoğaltır. Bu yüzden bir senkronizasyon servisinin ‘sürüm geçmişi’ özelliği olması da tek başına yeterli değildir; sürümlerin ne kadar geriye gittiği ve o sürümlere kimin, hangi yetkiyle erişebildiği ayrıca kontrol edilmelidir.

Bu ayrım önemlidir çünkü fidye yazılımı ve saldırı senaryolarında asıl soru “kopyam var mı” değil, “kopyam saldırganın erişemeyeceği bir yerde mi” sorusudur.

Yedekleme Modelleri ve Hangisinin Neye Yaradığı

Yedekleme modelleri kopyanın nerede durduğuna göre ayrışır: aynı binada duran bir kopya hızlı geri yükler ama bina veya ağ etkilendiğinde birlikte kaybolur; ağın dışında duran bir kopya daha yavaş geri yükler ama lokasyon riskini ortadan kaldırır. Aşağıdaki tablo, model seçimini bu iki eksende özetliyor.

Tabloyu okurken en sağdaki sütuna değil, “Fidye yazılımına direnci” sütununa bakın; birçok kurum yalnızca geri yükleme hızına odaklanıp bu sütunu atlıyor, oysa bir saldırı anında asıl belirleyici olan budur.

Bu katmanlardan hangisinin seçileceği “farklı lokasyondaki veri merkezinde” duran bir kopyanın nasıl kurulacağına bağlıdır; bu konuyu ayrıca sunucu barındırma yazımızda işledik.

RTO ve RPO: Yedekleme Kararının Tek Ölçülebilir Tarafı

RPO (Recovery Point Objective), bir kesintiden sonra verinin hangi ana kadar geri getirilmesi gerektiğini; RTO (Recovery Time Objective) ise sistemin kurtarma aşamasında en fazla ne kadar kalabileceğini gösterir. İkisi de dakika cinsinden yazılmadıkça yedekleme politikası ölçülebilir değildir.

NIST SP 800-34 Rev. 1’e göre “RPO nedir?” sorusunun cevabı, bir kesintiden sonra verinin geri getirilmesi gereken zaman noktasını gösterir; “RTO nedir?” sorusunun cevabı ise bir bilgi sisteminin, kurumun misyonunu veya iş süreçlerini olumsuz etkilemeden kurtarma aşamasında kalabileceği toplam süredir (NIST SP 800-34 Rev. 1). Üçüncü bir kavram olan MTD (Azami Tolere Edilebilir Kesinti), RTO’yu bir üst çerçeveye oturtur: NIST’e göre RTO ile geri yüklemeden sonraki yeniden işleme/mutabakat süresinin toplamı MTD’nin içinde kalmalıdır. Yani RTO’yu tek başına belirlemek yetmez; verinin sisteme yeniden girilmesi veya mutabakat yapılması için geçen süre de bu toplamın parçasıdır.

Örneğin sistemin kendisi iki saatte ayağa kalkıyor olsa bile, muhasebe ekibinin geri yüklenen kayıtları elle kontrol edip mutabakat yapması bir gün daha sürüyorsa, gerçek kesinti süresi iki saat değil bir gün iki saattir.

Hedef RPO / RTO’yu Nasıl Hesaplarsınız?

Piyasa ortalaması ya da başka bir müşterinin sayısıyla bu tabloyu doldurmayın; aşağıdaki tablo kendi verinizle doldurulmak üzere tasarlandı. Boş hücreler bilinçli olarak boş bırakıldı: bu tabloyu doldurmadan hiçbir sağlayıcıdan teklif istemeyin.

KVKK Bulut Yedeklemeden Tam Olarak Ne İstiyor?

KVKK’nın Kişisel Veri Güvenliği Rehberi, yedeklenen kişisel verilere yalnızca sistem yöneticisinin erişebilmesini ve veri seti yedeklerinin mutlaka ağ dışında tutulmasını şart koşar. Yani sürekli senkronize, üretim ağından erişilebilir bir kopya tek başına bu şartı karşılamaz.

KVKK’nın ağ dışılık şartı, kurumun kullandığı diğer bulut hizmetleri için de geçerlidir; her çözüm için ayrı anahtar yönetimi bu şartın bir parçasıdır. Denetim sırasında sorulan soru genellikle ‘yedek alıyor musunuz’ değil, ‘bu yedeğe kimin, hangi koşulda eriştiğini gösterebilir misiniz’ sorusudur; bu da erişim kayıtlarının da yedekleme kurgusunun bir parçası olarak tutulmasını gerektirir.

Felaket Kurtarma (FKM) Yedeklemenin Aynısı Değildir

Yedekleme veriyi geri getirir, felaket kurtarma ise hizmeti geri getirir. Felaket kurtarma merkezi (FKM, disaster recovery), birincil sistem kullanılamaz hâle geldiğinde iş yükünün devralınabileceği ikincil bir ortamdır; yalnızca veri kopyası değil, çalışır bir kopya barındırır.

Fkm nedir sorusunu bu ayrım üzerinden yanıtlamak daha doğrudur: yedek bir dosyayı geri döndürür, felaket kurtarma ise bir uygulamayı ayakta tutar. İş sürekliliği yönetim sistemleri için ISO 22301:2019 standardı, bu ikisini birbirinden ayıran ve bir kurumun kurtarma kapasitesini planlı bir çerçeveye oturtan referans noktalardan biridir.

Buradaki ikinci, karşı-sezgisel nokta şu: kesintilerin baş nedeni hâlâ enerji altyapısıdır: UPS, transfer şalteri ve jeneratör arızaları baskındır (Uptime Institute, 2026). Yani felaket planını yalnızca siber saldırı senaryosuna kurmak eksik bir plandır; aynı senaryo bir elektrik arızasında da devreye girebilmelidir.

Doğru FKM kurgusu, öncelikle doğru veri merkezi seçimi ile başlar; ikincil ortamın birincil sistemle aynı risk zincirini paylaşmaması gerekir. Aynı elektrik şebekesine, aynı fiber güzergâhına veya aynı bölgesel risk profiline bağlı iki veri merkezi, kâğıt üzerinde ‘ikinci lokasyon’ görünse de pratikte tek bir arıza noktasını paylaşıyor demektir.

Bulut Yedekleme Sağlayıcısı Seçerken Sorulacak 7 Soru

Bulut yedekleme sağlayıcısı seçimi ürün karşılaştırmasıyla değil, yedi sorunun yazılı cevabıyla yapılır: taahhüt edilen RPO ve RTO, yedeğin ağ dışında tutulup tutulmadığı, silmenin nasıl engellendiği, geri yükleme testi sıklığı, anahtar yönetimi, verinin bulunduğu ülke ve çıkış planı.

1. Taahhüt edilen RPO ve RTO dakika cinsinden yazılı mı? 

“Günlük yedek alıyoruz” bir RPO taahhüdü değildir. Sözleşmede kurtarma noktası sıklığının ve hedef geri yükleme süresinin rakamla yazılmasını isteyin.

2. Yedek kopya üretim ağının dışında mı tutuluyor? 

KVKK rehberi bunu açıkça şart koşuyor. Sağlayıcıdan, yedek deposunun üretim kimlik bilgileriyle erişilemediğini mimari olarak anlatmasını isteyin.

3. Depolama “yalnızca ekleme” (append-only) mi, gerçekten değiştirilemez (immutable) mi? 

İkisi aynı şey değildir: yalnızca ekleme yapılan bir depo mevcut kopyaların üzerine yazılmasını engeller ama silinmesini engellemeyebilir. Silmenin nasıl engellendiğini ve silme talebinin kaç kişinin onayına bağlı olduğunu sorun.

4. Geri yükleme testi ne sıklıkla ve kim tarafından yapılıyor? 

CISA, ekibin veriyi hem tam hem kısmi geri yükleyebildiğini ve en az yedi gün geriye dönük geri alabildiğini test etmeyi öneriyor. Test raporunun size de verilmesini sözleşmeye yazdırın.

5. Şifreleme anahtarları kimde ve her çözüm için ayrı mı? 

KVKK rehberi her bulut çözümü için ayrı anahtar istiyor. Anahtarların sizde mi sağlayıcıda mı olduğunu ve hizmet bittiğinde tüm kopyalarının nasıl imha edildiğini yazılı olarak isteyin.

6. Veri hangi ülkede duruyor ve muhatap tüzel kişilik Türkiye’de mi? 

Müşterek sorumluluk gereği bir ihlalde Kurula siz bildirim yapacaksınız; bilgiyi 72 saat içinde alabileceğiniz, Türkiye’de muhatabı olan bir yapıyla çalışıp çalışmadığınızı sorgulayın.

7. Çıkış planı var mı? 

Yedeklerinizi başka bir sağlayıcıya ya da kendi ortamınıza taşımanın süresi, biçimi ve maliyeti sözleşmede tanımlı olmalı. Tanımlı değilse, kurtarma planınız sağlayıcının devamlılığına bağlıdır.

Sık Yapılan Beş Hata

Yedekleme kurgularında en sık görülen hata yedek almamak değil, hiç geri yükleme denemesi yapmamaktır. Yedeğin varlığı test edilmedikçe bir varsayımdır; kurtarma anında ilk kez denenen bir süreç, kurtarmanın kendisinden daha uzun sürebilir. Aşağıdaki beş hatanın ortak noktası, hiçbirinin yedek alma anında değil, geri yükleme anında fark edilmesidir; yani maliyeti en yüksek olan hata türüdür.

1. Geri yükleme testi hiç yapılmıyor: Yedek alınıyor ama geri döndüğü doğrulanmıyor; ilk test genellikle gerçek bir kriz anında yapılıyor.

2. Senkronizasyon yedek sayılıyor: Yukarıda anlatılan yanılgı: sürekli senkronize bir kopya, saldırıyla veya silme hatasıyla birlikte bozulur.

3. Tek kopya, tek lokasyon: 3-2-1 kuralının “saha dışı kopya” bacağı atlanıyor; bina veya ağ riskine karşı hiçbir koruma kalmıyor.

4. Saklama penceresi, fark edilme süresinden kısa tutuluyor: Bir fidye yazılımı olayının fark edilmesi haftalar sürebilir; bir haftalık saklama bu durumda yetersizdir.

5. Yedek kapsamı, envanter çıkarılmadan belirleniyor: CISA’nın önerdiği gibi, önce neyin yedeklenmesi gerektiğinin listelenmesi atlanıyor; kritik bir sistem kurgunun dışında kalabiliyor.

Yedekleme Bir Ürün Değil, Bir Politikadır

Bulut yedekleme bir ürün değil bir politikadır; politikanın iki sayısı RPO ve RTO’dur, iki şartı ağ dışılık ve test edilmişliktir. Bu dört unsur yazılı, ölçülebilir ve sözleşmeye bağlanmış değilse, elinizdeki “yedek” bir varsayımdan ibarettir.

Dorabase, Türkiye’de konumlu veri merkezi altyapısı üzerinden yedekleme ve felaket kurtarmayı yönetilen hizmet kapsamında sunar. KVKK açısından Türkiye’de muhatap tüzel kişilik bulunması ve 7/24 izleme, yukarıda sayılan yedi sorunun ikisine doğrudan yanıt verir.

Sıkça Sorulan Sorular

Kaynakça:

1. Kişisel Verileri Koruma Kurumu, Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler), Ocak 2018 kvkk.gov.tr
2. Kişisel Verileri Koruma Kurulu, Kişisel Veri İhlali Bildirim Usul ve Esaslarına İlişkin 24.01.2019 tarih ve 2019/10 sayılı Karar kvkk.gov.tr
3. NIST, SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems csrc.nist.gov
4. NIST CSRC Glossary, Recovery Time Objective csrc.nist.gov
5. NIST CSRC Glossary, Recovery Point Objective csrc.nist.gov
6. CISA, Back Up Business Data cisa.gov
7. Uptime Institute, Annual Outage Analysis Report 2026 (basın açıklaması, 13.05.2026) uptimeinstitute.com
8. ENISA, Threat Landscape (konu sayfası) enisa.europa.eu
9. ENISA, ENISA Threat Landscape 2025, 01.10.2025 enisa.europa.eu
10. ISO, ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements iso.org