Yedek Saklama Süresi: KVKK, GDPR ve Maliyet Planı

Yedek almayı otomatikleştirmek, yedeğin ne kadar süreyle saklanacağını belirlemez. Güvenlik, hukuk ve finans ekipleri aynı plan üzerinde çalışmalıdır: Veri kaybından dönmek için yeterli geçmişi korumak, kişisel verileri gerekçesiz tutmamak ve depolama bütçesini hesaplamak. Yedek saklama süresi politikası bu kararları kayıt altına alır.

Bu rehberde yedekleri sınıflandırmayı, KVKK ve GDPR ilkelerini veri türüne göre uygulamayı, sıcak/soğuk/arşiv depolamayı ve maliyeti birlikte ele alacağız. Hosting, VPS, dedicated ve colocation ortamları için karar adımları sunacağız. Uygulama, seçilen hizmetin ve yedekleme araçlarının sunduğu kontrollere bağlıdır; bir takvim tek başına hukuki uygunluk sağlamaz.

Yedek Saklama Süresi Neden Stratejik Bir Karar?

Yedek almak tek başına bir güvenlik veya süreklilik garantisi değil; asıl kritik konu, bu yedeklerin hangi sıklıkla alındığı ve ne kadar süreyle tutulduğu. Bu iki parametre, iş sürekliliği tarafında RPO/RTO hedeflerinizle, hukuki tarafta KVKK/GDPR ilkeleriyle ve teknik tarafta depolama maliyetlerinizle doğrudan bağlantılı.

RPO, kabul edilebilir veri kaybının zaman aralığıdır; yedekleme sıklığı bununla ilişkilidir. Saklama süresi ne kadar eski bir noktaya dönebileceğinizi belirler. RTO ise kabul edilebilir kurtarma süresidir ve depolama erişimi, bağımlılıklar ve ölçülen geri yükleme süresiyle doğrulanır.

Örneğin;

• Varsayımsal bir e-ticaret iş yükü, 30 dakikalık veri kaybını bile kabul etmeyebilir.
• Üç yıllık sepet geçmişinin kişisel veri içeren kısmını tutmak için amaç ve hukuki dayanak ayrıca incelenmelidir; üç yıl genel bir yasal sınır değildir.
• Tüm kopyaları on yıl hızlı NVMe disklerde tutmak, arşiv için daha uygun seçeneklere göre gereksiz maliyet yaratabilir; gerçek fark tarifeye ve erişim ihtiyacına bağlıdır.

Önceki yazımızda RPO/RTO hedeflerine göre yedekleme stratejisi planlamayı detaylı anlatmıştık. Bu yazıda ise odak noktamız, o stratejiyi tamamlayan saklama süresi politikası olacak. Çünkü yanlış seçilmiş saklama süreleri, hem denetimlerde başınızı ağrıtabilir hem de gerçek bir veri kaybında sizi hazırlıksız yakalayabilir.

KVKK ve GDPR Perspektifinden Yedek Saklama Süresi

KVKK ve GDPR, tüm yedeklere uygulanacak tek bir gün veya yıl sayısı belirlemez. KVKK m.4 ve GDPR m.5 kapsamındaki şu ayrımları koruyun; ayrıca kendi faaliyetinize uygulanabilir hükümleri belirleyin:

GDPR’ın uygulanması m.3’teki kuruluş, faaliyet ve ilgili kişilere yönelme/izleme şartlarıyla değerlendirilir; yalnızca sunucunun ülkesiyle belirlenmez. KVKK ve GDPR değerlendirmelerini ayrı yapıp gerekiyorsa birlikte uygulayın.

• Amaç: İşleme amacını belirli, açık ve meşru olarak tanımlayın. GDPR’daki amaçla sınırlılık, amaçla bağdaşmayan sonraki işlemenin önlenmesini de kapsar.
• Veri miktarı ve kapsamı: KVKK’da amaçla bağlantılı, sınırlı ve ölçülü işleme; GDPR’da yeterli, ilgili ve gerekli olanla sınırlı veri minimizasyonu esastır. Hangi alanların ve kopyaların gerekli olduğunu değerlendirin.
• Süre: KVKK’da ilgili mevzuatta öngörülen veya amaç için gerekli süre; GDPR’da kişiyi belirlenebilir kılan biçimde amaç için gerekli süreden uzun tutmama ilkesi uygulanır. Sadece yedeğe “arşiv” demek, GDPR’ın kamu yararına arşiv/araştırma gibi koşullu istisnalarından yararlanmanızı sağlamaz.

KVKK m.3’te depolama ve muhafaza da kişisel veri işleme kapsamındadır. Verinin yedekte olması bu niteliği kaldırmaz. İmha Yönetmeliği m.8–10 ise farklı sonuçlar tanımlar: silme, ilgili kullanıcılar için erişilemez ve tekrar kullanılamaz kılmadır; yok etme, hiç kimse için erişilemez, geri getirilemez ve tekrar kullanılamaz kılmadır. Anonimleştirme, başka verilerle eşleştirilse bile kişiyle ilişkilendirmeyi önlemelidir. Yönetmelikteki “ilgili kullanıcı”, teknik depolama, koruma ve yedeklemeden sorumlu kişi/birimi dışarıda bırakır. Yalnızca kaydı arayüzden gizlemek veya kimliği hashlemek bu sonuçları kendiliğinden sağlamaz.

Aktif Sistemden Silinen Verinin Yedekte Kalması Sorunu

Önemli bir gri alan şurada oluşuyor: Bir kullanıcı hesabını sildiğinizde veya bir müşteriden “unutulma hakkı” talebi geldiğinde, üretim veritabanından kaydı silebiliyorsunuz. Peki otomatik yedekler? Yedek biçimine bağlı olarak geçmiş yedekleri tek tek açıp ilgili kaydı silmek maliyetli olabilir ve yedeğin bütünlüğünü bozma riski taşıyabilir.

Hesap kapatma ile kişisel verilerin silinmesi talebi aynı işlem değildir. Hangi verinin, hangi şartla silineceği; kalan yasal saklama yükümlülükleri ve talebin kapsamıyla belirlenir. Teknik zorluk tek başına yıllarca ek saklama hakkı yaratmaz.

Yedek yaşam döngüsünü planlamak için şu adımlar kullanılabilir; bunlar tek başına bir silme talebinin hukuken karşılandığını göstermez:

• Yedekler için mantıklı ve sınırlı bir saklama süresi tanımlamak (yalnızca varsayımsal bir plan olarak; günlük yedekler 30 gün, haftalık yedekler 6 ay, aylık yedekler 1–3 yıl; her süre veri türüne ve saklama gerekçesine göre ayrıca değerlendirilmelidir),
• Bu sürenin sonunda yedekleri otomatik ve geri döndürülemeyecek şekilde silmek,
• Saklama ve silme süreçlerini dokümante etmek ve gerektiğinde denetimlerde sunabilmek,
• Silinmesi gereken kayıtların yedekten geri yüklemeyle yeniden kullanıma girmesini önlemek için silme işlemlerini hizmeti açmadan önce yeniden uygulayacak bir süreç tanımlamak.

Silme/düzeltme işlemlerinin asgari kayıtlarını kontrollü ve ayrı bir yerde tutun. Üretim sistemi de kaybedildiğinde bu kayıtlar erişilebilir olmalı; geri yüklenen veriler hizmet yeniden açılmadan önce kontrol edilmelidir. Kayıtların kendisi de kişisel veri içerebilir ve kendi yetki/saklama kurallarına ihtiyaç duyar.

Amaç, gerekçesiz biçimde sınırsız yedek biriktirmek yerine gerekçelendirilebilir ve uygulanabilir bir saklama politikası oluşturmak olmalıdır.

KVKK’ya Göre Saklama İlkesini Pratikleştirmek

KVKK tarafında pratik bir yöntem, her veri türü için şu üç soruyu netleştirmek:

• Bu veriyi neden tutuyorum? (sözleşme, meşru menfaat, hukuki yükümlülük vb.)
• Bu amaç ne kadar süre geçerli?
• Yedekte ek saklama gerçekten gerekli mi; gerekliyse bu yedek saklama süresinin gerekçesi ve sınırı nedir?

Yönetmelik m.11–12 takvimi ayrıca düzenler. Politika hazırlamış veri sorumlusu, imha yükümlülüğü doğduktan sonraki ilk periyodik imhada işlem yapar; dönem en fazla altı ay olabilir. Politika hazırlama yükümlülüğü olmayanlar için yükümlülüğün doğumunu izleyen üç ay kuralı vardır; Kurul belirli şartlarda süreyi kısaltabilir. Bunlar ilgili kişinin başvurusunu bekletme izni değildir: İşleme şartlarının tamamı kalkmışsa talep en geç otuz günde sonuçlandırılır ve bilgi verilir. Şartlar devam ediyorsa gerekçeli ret yine otuz gün içinde bildirilir; aktarılmış veriler için üçüncü kişilerde gerekli işlemler de sağlanır.

Fatura, ticari defter ve pazarlama kaydını aynı süreye bağlamayın. Türkiye için iki farklı belge yükümlülüğü örneği:

Pazarlama izninin geri alınması, aktif pazarlama için kullanımı sürdürme gerekçesi değildir. Buna karşılık izin/ret kanıtını veya yeniden iletişimi engelleyen asgari kaydı koruma gereği ayrıca incelenebilir. Bu kayıtlara fatura süresi otomatik uygulanmaz; kapsam, dayanak ve süre ayrı yazılır. Gerekli belgeleri seçerek arşivlemek, tüm uygulama yedeğini yıllarca saklamaktan farklıdır.

GDPR’da Unutulma Hakkı ve Yedekler

GDPR m.17 silme hakkını belirli şartlara bağlar. Verinin artık gerekli olmaması, başka dayanak yokken rızanın geri çekilmesi veya hukuka aykırı işleme gibi nedenler incelenir. Hakkın uygulanacağı durumda silme gereksiz gecikme olmadan yapılır. M.17/3-b’de AB veya üye devlet hukukundan doğan gerekli işleme yükümlülüğü, m.17/3-e’de hukuki taleplerin tesisi/kullanılması/savunulması ve diğer istisnalar belge ve amaç bazında değerlendirilir; her yedek için genel istisna yoktur.

• Talep takvimi: GDPR m.12/3 uyarınca yapılan işlem hakkında gereksiz gecikme olmadan ve en geç bir ayda bilgi verin. Karmaşıklık ve talep sayısı gerektiriyorsa iki ay daha uzatma mümkündür; gerekçesi ilk ay içinde bildirilir. Bu, her talebi veya her yedeği otomatik üç ay bekletme hakkı değildir.
• Yedek kapsamı: Seçici silme imkânını, yedek bütünlüğünü, gerekli erişim kısıtlarını ve son imha tarihini birlikte değerlendirin. EDPB’nin 2026 tarihli raporunun 4.2.6 bölümü, yedeklerin teknik bütünlüğü nedeniyle değiştirilemediği durumlarda talepleri izleyen ve geri yüklenen sistemde uygulayan prosedürlere işaret eder; sırf rutin döngüye güvenilmesindeki sorunları da belirtir. Rapordaki öneriler bağlayıcı değildir ve GDPR yükümlülüklerini ortadan kaldırmaz.
• Geri yükleme: CNIL’in geliştirici rehberi, yedeklerden silmeyi veya silinen verinin geri getirilmesini önleyen çözümü planlamayı önerir. Silme ve düzeltmeleri hizmet yeniden açılmadan önce uygulayın; gerekli alıcı bildirimlerini GDPR m.19’a göre değerlendirin.

Yani yedekleriniz için, “süresiz” veya “ihtiyaç duyulana kadar” gibi yoruma açık tanımlar yerine, somut ve gerekçelendirilmiş süreler yazmanız gerekiyor; yalnızca bir süre belirtmek hukuki uygunluğu kanıtlamaz.

Teknik Tarafta Yedek Saklama Süresini Etkileyen Faktörler

Hukuki çerçeve önemli, ama tek başına yetmez. Teknik açıdan da şu faktörler direkt olarak yedek saklama süresi kararınızı etkiler:

• Veri boyutu ve günlük değişim oranı: Büyük ve hızlı değişen veriler, uzun saklama sürelerinde hızla TB’lara çıkabilir.
• İş kritikliği: Hatayı ne kadar geç fark ederseniz, o kadar eski yedeğe ihtiyaç duyarsınız.
• Ransomware riski: Fidye yazılımlarını geç fark ettiğiniz senaryolarda, kısa saklama süreleri temiz bir geri dönüş noktasını kapsamaya yetmeyebilir.
• Depolama teknolojisi: NVMe, SATA, object storage, tape gibi katmanlar arasında büyük maliyet farkları vardır.

Örneğin, 200 GB’lık bir veritabanınız ve günlük %5 değişim oranınız varsa; sık sık incremental (artımlı) yedek alarak saklama süresini uzatmanız, her gün tam yedek almaktan çok daha ekonomik olabilir.

Artımlı yöntem kullanıyorsanız, saklanan her geri dönüş noktası için gereken tam yedek ve ara parçaları birlikte koruyun. Depolama kazancı, değişen bloklara, sıkıştırılabilirliğe, araç biçimine ve yeniden kullanılan verilere bağlıdır.

S3 uyumlu nesne depolama gibi çözümlerle çalışıyorsanız, S3 depolama mimarisinin temel mantığını anlamak saklama süresi ve katmanlı depolama tasarımı yaparken ciddi avantaj sağlar.

Depolama Maliyeti Hesabı: “Sonsuza Kadar Saklayalım” Neden Çalışmaz?

“Yedek önemli, silmeyelim, dursun” yaklaşımı güvenli görünebilir. Ancak silme sınırı olmayan bir politika, zamanla artan depolama maliyetlerine ve yönetim karmaşasına yol açabilir.

Basit Bir Maliyet Hesabı

Örnek bir senaryo düşünelim:

• Uygulama + veritabanı boyutu: 300 GB
• Günlük tam yedek: 300 GB
• Günlük değişim oranı: %10 (günde yaklaşık 30 GB değişen veri; gerçek artımlı yedek boyutu kullanılan yönteme ve ek veriye bağlıdır)
• Saklama süresi: 365 gün

Veri boyutu sabit kalır ve her gün ayrı bir tam yedek tutulursa, sıkıştırma ve deduplikasyon öncesinde 300 GB x 365 = 109,5 TB depolama gerekir (1 TB = 1000 GB). Bu genel bir üst sınır değildir; veri büyümesi ve ek kopyalar ihtiyacı artırabilir. Artımlı yedekleme, sıkıştırma ve deduplikasyon ihtiyacı azaltabilir. Sabit günlük yedek boyutu ve birim fiyat varsayımıyla, tutulan yedeklerin kapasitesi ve buna bağlı depolama bedeli saklama süresiyle doğrusal artar.

Toplam bütçeye kopya sayısı, büyüme, istek/aktarım ve geri alma ücretleri, asgari depolama süresi, test ortamı ve yönetim işi de dahildir. 109,5 TB hesabı yalnızca belirtilen tek-kopya kapasite varsayımıdır.

Bu yüzden doğru soru, “Ne kadar uzun saklayabilirim?” değil; “Hangi veriyi, hangi hızda, hangi katmanda, ne kadar süre saklamalıyım?” olmalı.

Sıcak, Soğuk ve Arşiv Yedek Katmanları

Maliyetleri kontrol etmenin bir yolu, yedekleri erişim ihtiyacı ve hıza göre katmanlara bölmektir. Aşağıdaki süreler örnektir; gerçek süreler veri türüne, saklama gerekçesine ve geri yükleme hedeflerine göre belirlenmelidir:

• Sıcak yedekler: Son 7–30 gün; hızlı NVMe/SATA disklerde, kısa geri yükleme süresini hedefleyen kopyalar. Disk hızı tek başına anında geri dönüş sağlamaz.
• Soğuk yedekler: 1–12 ay arası; daha yavaş ve ucuz depolama, erişim nadir.
• Arşiv yedekler: 1–7 yıl; çoğunlukla sadece hukuki veya düzenleyici gereksinimler için, erişim neredeyse hiç yok.

Örnek bir tasarımda üretim verisi VPS veya dedicated sunucularda tutulurken, uzun süreli yedekler ayrı uzak depolama veya nesne depolama katmanlarına taşınabilir. Böylece üretim depolaması performans için, yedek depolaması ise saklama maliyeti ve geri yükleme hedefleri için ayrı ayrı seçilebilir. Maliyet karşılaştırmasına veri aktarımı ve geri alma ücretleri de dahil edilmelidir.

Ransomware, S3 Object Lock ve Uzun Süreli Güvenli Yedekler

Fidye yazılımı riski, yedek saklama süresi planında dikkate alınmalıdır. Örneğin bir saldırgan haftalarca fark edilmeden sistemde kalır ve yedeklere de erişebilirse onları bozabilir, şifreleyebilir veya silebilir. Böyle bir senaryoda saldırı fark edildiğinde son 7–14 günlük yedekler de kullanılamaz durumda olabilir.

Bu yüzden “kaç gün saklayalım” yanında, “hangi hesap bu yedeği değiştirebilir veya silebilir?” sorusunu yanıtlayın. Değiştirilemez (immutable) kopyalar, ayrı yetkiler ve doğrulanmış geri yükleme noktaları birlikte değerlendirilmelidir. Yedek kilidi, zaten bozulmuş verinin yedeklenmesini veya bütün erişim risklerini önlemez.

Amazon S3 Object Lock belirli nesne sürümlerini korur. Governance modunda özel yetkili kullanıcı korumayı aşabilir; compliance modunda korunan sürümün süresi kısaltılamaz ve süre boyunca root dahil kullanıcılar sürümü silemez. Legal hold ayrı bir kilittir ve yetkili kaldırana kadar sürer. Bu teknik modlar kendi başlarına hukuki saklama gerekçesi oluşturmaz. Kilit süresini kişisel veri silme yükümlülükleriyle birlikte tasarlayın; S3 uyumlu başka hizmetlerin aynı davranışı sunduğunu ayrıca doğrulayın.

Bu konuyu detaylı anlattığımız S3 Object Lock ile fidye yazılıma karşı kale gibi yedek oluşturma rehberine mutlaka göz atmanızı öneririz. Orada, hem saklama süresi (retention) hem de yedeklerin değiştirilemezliği (WORM – Write Once Read Many) birlikte ele alınıyor.

KVKK/GDPR ile Maliyeti Dengeleyen Örnek Saklama Politikaları

Teori bir yere kadar; şimdi işin pratik tarafına gelelim. Farklı türde projeler için örnek yedek saklama politikaları üzerinden ilerleyelim. Bunlar elbette birebir uygulanması gereken kurallar değil; kendi sektörünüz, sözleşmeleriniz ve ülke mevzuatınızla birlikte değerlendirilmesi gerekiyor. Ama karar verirken iyi bir başlangıç noktası sunuyor.

1) Blog ve Kurumsal Web Sitesi

Blog veya kurumsal site de iletişim formları, yorumlar, analiz araçları ve erişim logları üzerinden kişisel veri işleyebilir. Saklama planını site türüne bakarak düşük riskli saymayın.

• Uygulama + veritabanı yedeği: Günlük yedek, 30–90 gün saklama.
• Ayda bir tam imaj: 6–12 ay saklama (büyük bir güncelleme öncesi özellikle önemli).
• Loglar: Güvenlik ve hata ayıklama için 3–6 ay, KVKK kapsamında IP ve user-agent gibi kişisel veri içerebileceğini unutmayın.

Bu sayılar yalnızca örnek karar seçenekleridir. Bir yıllık yedeğin tamamı da içindeki veri türlerine göre gerekçelendirilmelidir. Daha uzun saklama gerekiyorsa geçerli amaç/dayanak ile kapsamı belirleyin; gerekli belge arşivini gereksiz kişisel verilerle dolu tam sistem imajından ayırın.

2) E‑Ticaret ve Ödeme Alan Siteler

E-ticaret siteleri hem kişisel veri hem de finansal bilgi açısından daha karmaşık. Genellikle:

• Sipariş ve fatura: VUK/TTK veya ilgili başka hükmün kapsadığı belgeyi ve süre başlangıcını belirleyin; tüm sipariş davranışını aynı süreye bağlamayın.
• Sepet, davranış ve pazarlama: Amaç, hukuki dayanak, rıza/itiraz durumu ve ispat için gereken asgari kayıt ayrı değerlendirilir; iki veya üç yıl genel uygunluk eşiği değildir.
• Ödeme kartı verileri: Kart verisini mümkün olduğunca ödeme sağlayıcısında tutan bir tasarım değerlendirin. PCI SSC’ye göre üye işyerinde kart doğrulama kodu (CVV/CVC), yetkilendirmeden sonra kartın kayıtlı olduğu veya tekrarlı ödeme senaryolarında da saklanamaz. Şifreleme veya müşteri izni bu yasağı kaldırmaz; yedeklere de taşınmamalıdır.

Yedek tasarımını PCI DSS gereklilikleriyle birlikte değerlendirin. Gereksiz alanları yedek kapsamından önce çıkarmak, eski tam yedekleri sonradan temizlemekten farklı bir adımdır. Maskeleme, tokenizasyon veya takma ad kullanımı veriyi kendiliğinden anonim hale getirmez; eski kopyalarda tanımlayıcıların kalıp kalmadığını kontrol edin.

3) SaaS Uygulamaları ve Çok Kiracılı Sistemler

SaaS projelerinde durum daha da hassas; çünkü tek bir altyapıda onlarca, bazen yüzlerce müşterinin verisi tutuluyor. Yedekleme ve saklama süreleri için:

• Sistem ve müşteri bazlı saklama hedeflerini, yedek biçiminin gerçekten desteklediği ayrımla eşleştirin; ortak veritabanı yedeğinde kiracılar birlikte kalabilir.
• Müşteri sözleşmelerinde kapsam, süre, silme sorumlusu ve erişim koşullarını yazın.
• Müşterinin ayrılmasında (offboarding) verinin iade/silme adımlarını ve kalan hukuki yükümlülükleri belirleyin.
• Veri sorumlusu ve veri işleyen rollerini gerçek işleme amaçları ve görevleriyle belirleyin; sözleşme etiketi tek başına rolü değiştirmez.

Bu konuda detaylı bir yol haritasını SaaS uygulamaları için müşteri verisi yedekleme ve veri saklama politikaları yazımızda adım adım anlattık. Özellikle çok kiracılı mimari (multi-tenant) kullanıyorsanız, yedeklerin müşteri ayrımı ve geri yükleme senaryolarını mutlaka test etmelisiniz.

Adım Adım Yedek Saklama Süresi Belirleme Metodolojisi

Aşağıdaki adımları sistem envanterinize, uygulanabilir yükümlülüklere ve ölçülen geri yükleme hedeflerinize uyarlayın. Sonuç, her veri türünün gerekçesini ve sorumlusunu gösteren uygulanabilir bir politika olmalıdır.

1) Veri Envanterini Çıkarın

Önce neyi yedeklediğinizi bilmeniz gerekiyor. Basit bir tabloyla başlayın:

• Uygulama veritabanları (MySQL, PostgreSQL vb.)
• Dosya depoları (medya, doküman, log arşivleri)
• E-posta kutuları ve arşivleri
• Konfigürasyon dosyaları, altyapı kodu (IaC) ve CI/CD yapılandırmaları

Her biri için tahmini boyut, günlük büyüme oranı ve iş kritikliği derecesini not edin. Bu çalışma, ileride saklama sürelerini belirlerken elinizdeki en önemli referans olacak.

2) Veri Türlerini ve Kişisel Veri İçeriklerini Sınıflandırın

Her veri seti için şu soruları sorun:

• Bu veri kişisel veri içeriyor mu? (isim, e-posta, IP, çerez, davranış verisi vb.)
• Özel nitelikli kişisel veri var mı? (sağlık, biyometrik, dernek üyeliği vb.)
• Loglarınızda IP ve kullanıcı kimlikleri ne kadar detaylı tutuluyor?

Hassasiyet; erişim, şifreleme ve risk önlemlerini etkiler. Saklama süresi ise her veri kümesinin amacı ve uygulanabilir yükümlülükleriyle belirlenir. Teknik meta veri de kişiyi belirleyebilir; yalnızca özetleme, maskeleme veya kimlik alanını kaldırma anonimlik kanıtı değildir.

3) Hukuki Yükümlülükleri ve Sektör Özel Kuralları Haritalayın

Veri türlerine ve süreçlere göre geçerli olan:

• Vergi ve ticaret mevzuatı (fatura, muhasebe kayıtları),
• Sektörel düzenlemeler (finans, sağlık, eğitim vb.),
• Sözleşmesel yükümlülükler (müşteri sözleşmeleri, SLA’ler),
• KVKK/GDPR saklama ilkeleri

için belgeye özgü saklama yükümlülüklerini, azami süreleri, silme nedenlerini ve başlangıç olayını birlikte kaydedin. Birden fazla ülke veya kural varsa otomatik olarak en uzun ya da “en katı” süreyi tüm veriye uygulamayın. Kapsamları ve olası çatışmaları hukuk/uyum sorumlularıyla çözün.

4) İş İhtiyacı ve Risk Analizi Yapın

Her veri türü için şu dengeyi kurmanız gerekiyor:

• İş ihtiyacı: Geriye dönük ne kadar veriye fiilen ihtiyaç duyuyorsunuz? (raporlama, trend analizleri, müşteri geçmişi vb.)
• Risk: Bu veriyi ne kadar uzun tutarsanız, olası bir ihlalde ortaya çıkacak risk de o kadar büyür.
• Maliyet: Uzun saklama, daha fazla depolama, daha fazla yönetim yükü demek.

Bu üç başlık arasında her veri türü için bilerek bir tercih yapın. Özellikle “raporlama için lazım olabilir” bahane cümlesine dikkat edin; çoğu zaman özetlenmiş, anonimleştirilmiş veriyle de aynı içgörüleri elde etmek mümkün.

5) Saklama Sürelerini ve Katmanlı Depolama Modelini Tanımlayın

Aşağıdaki biçim, bir politika tablosu taslağıdır; sayılar varsayımsaldır. Her satıra veri kategorisini, amacı/dayanağı, sürenin başlangıcını, sorumluyu ve doğrulanan silme yöntemini ekleyin:

• Günlük uygulama yedekleri: 30 gün (sıcak)
• Haftalık tam yedek: 6 ay (soğuk)
• Aylık imaj yedeği: 3 yıl (arşiv)
• Güvenlik logları: 1 yıl
• E-posta arşivleri: X yıl (sektör ve hukuki gerekliliklere göre)

Arka planda mutlaka 3-2-1 yedekleme prensibini kullanın: En az 3 kopya, 2 farklı ortam, 1 kopya farklı lokasyonda. Bunun hosting tarafında nasıl kurulacağını, 3-2-1 yedekleme stratejisi rehberimizde detaylı anlattık.

Üretim verisi üç kopyadan biridir. Aynı sunucudaki kopyalar sunucu kaybına karşı bağımsız değildir; aynı lokasyondaki ayrı sunucular da lokasyon kaybını çözmez. Katmanların süreleri farklıysa eski geri dönüş noktalarının kaç bağımsız kopyası kaldığını kontrol edin. Uzak kopyanın sıklığı, ana lokasyon kaybında hedeflenen RPO’yu karşılamalıdır.

6) Otomasyon: Döngüsel Silme, Lifecycle Politikaları ve Şifreleme

Otomasyon, tekrarlanabilir saklama ve silme işlemlerini destekler; tek başına işlemin doğru veya tamamlanmış olduğunu göstermez. Başarısız işleri, eski sürümleri ve bağlı kopyaları denetleyin.

Burada şunları planlayın:

• Panel veya sunucu: cPanel, DirectAdmin, Plesk ya da VPS üzerinde hangi rotasyon seçeneklerine yetkiniz olduğunu doğrulayın. Panel yetkisi yoksa sağlayıcıdan yazılı saklama/silme kapsamını alın.
• Nesne depolama: Yaşa göre geçiş ve silme kurallarını, sürümleri ve Object Lock korumalarını birlikte yönetin. Amazon S3’te geçerli sürümü sona erdirmek bir delete marker oluşturabilir; eski sürümler için ayrı temizleme gerekir. Kilitli sürümler korunur ve lifecycle işlemi anında tamamlanma garantisi vermez.
• Şifreleme ve anahtarlar: Yedekleri riskine uygun koruyun; anahtara erişimi, yedek anahtarları, kurtarma testlerini ve rotasyonu planlayın. Anahtar rotasyonu silme değildir. Anahtar imhası ancak tüm ilgili anahtar/kopyalar ve kurtarma yolları dikkate alınarak, tutulması gereken diğer veriler zarar görmeden ve sonuç doğrulanarak değerlendirilmelidir.

Amazon S3 lifecycle belgeleri, sürümlü bucket ile sürümsüz bucket davranışını ayrı açıklar. Yedek yazılımının prune işlemi ile depolama sağlayıcısının fiziksel temizleme sürecini aynı olay saymayın.

Restic, Borg ve S3 uyumlu uzak yedekleme iş akışları rehberini araç ve depo seçimi için kullanabilirsiniz. Araçların desteklediği arka uçlar aynı değildir; saklama, bağımlılıkları koruma ve prune davranışını seçilen sürüm/depo için doğrulayın.

7) Dokümantasyon ve Denetim İzi Oluşturun

Saklama politikasını ve uygulanan işlemleri kayda almak, kararların gerekçesini ve sorumlularını görünür kılar. Doküman ile gerçek yedekleme/silme davranışını düzenli olarak karşılaştırın.

Basit bir dokümanda bile şunlar yer almalı:

• Yedekleme sıklıkları ve saklama süreleri,
• Depolama katmanları ve lokasyonlar (ülke/bölge bazında),
• Şifreleme ve erişim kontrolü politikaları,
• Silme/anonimleştirme süreçleri,
• Periyodik yedek geri yükleme testleri.

KVKK İmha Yönetmeliği m.7/3, imha işlemlerinin kayıt altına alınmasını ve bu kayıtların diğer yükümlülükler saklı kalmak üzere en az üç yıl tutulmasını öngörür. Bu, silinen kişisel veri içeriğinin üç yıl daha tutulması demek değildir. İlgili kişinin talep sonucu, yöntem, tarih ve işlemi doğrulayan asgari kanıtı yetkili erişimle yönetin.

Böylece bir veri ihlali, müşteri sorusu veya resmi denetim geldiğinde, hem teknik hem hukuki olarak nerede durduğunuzu net biçimde gösterebilirsiniz.

Hosting Ortamında Saklama Politikasını Uygulamak

Paylaşımlı hosting, VPS, dedicated ve colocation seçiminde yedeklerin nerede tutulduğunu ve saklama/silme kontrolünün kimde olduğunu yazılı olarak doğrulayın. Aşağıdaki seçeneklerin kullanılabilirliği ürün, lokasyon, yetki ve kurulumla değişir:

• Paylaşımlı hosting: Sağlayıcının otomatik yedek sıklığı/süresini ve kullanıcının dışarı kopya alabilme imkanını öğrenin. Kullanıcı paneli ile sağlayıcının tüm yedeklerini yönetebildiğinizi varsaymayın.
• VPS/dedicated: Uygulama tutarlı veritabanı/dosya yedekleri ve varsa snapshot seçeneklerini bağımsız uzak kopyayla birleştirin. Snapshot’ın dayandığı ana depolamanın kaybına karşı tek başına koruma sağladığını varsaymayın.
• Colocation: Kendi cihaz ve yazılımınızla bağımsız yedek deposunu tasarlayın; enerji, ağ, hesap/yetki ve lokasyon bağımlılıklarını belirleyin. Aynı veri merkezindeki ayrı depo, tek başına lokasyon dışı kopya değildir.

Veri lokasyonu yanında kimlerin eriştiği, alt işleyenler ve aktarım zinciri de değerlendirilmelidir. KVKK/GDPR kapsamında hosting ve veri aktarımı rehberi bu planı tamamlar. Ülke seçimi tek başına uygunluk sağlamaz; yedek lokasyonları ve uzaktan erişimler de uygulanabilir aktarım kurallarıyla birlikte incelenmelidir.

Sonuç: Yedek Saklama Süresi Bir Seferlik Değil, Canlı Bir Politika

Uygulama, veri türleri, mevzuat, tehditler veya sağlayıcı değiştiğinde saklama politikasını yeniden değerlendirin. Politikanın işe yarayıp yaramadığını; seçilmiş eski/yeni noktalardan geri yükleme, RPO/RTO ölçümleri, silme taleplerinin yeniden uygulanması ve sona eren kopyaların temizlenmesiyle kontrol edin.

Özetle;

• Veri envanteri ve sınıflandırması yapın,
• Hukuki ve iş ihtiyaçlarını yan yana koyun,
• Katmanlı depolama ve 3-2-1 prensibini uygulayın,
• Object Lock, şifreleme ve uzak yedekle fidye yazılıma karşı hazırlıklı olun,
• Tüm bunları otomasyon ve dokümantasyonla destekleyin.

Mevcut yedekleri, süreleri, lokasyonları ve sorumluları listeleyerek başlayın. Hukuk/uyum sorumluları veri bazında gerekçeleri belirlesin; teknik ekip bunları uygulanabilir takvim, erişim ve silme kontrollerine dönüştürsün. Seçilen hosting hizmetinin bu tasarımı hangi kapsamda desteklediğini sağlayıcınızla yazılı olarak doğrulayın.