Yedek Saklama Süresi Nasıl Belirlenir? KVKK, GDPR ve Maliyet Dengesi

Birçok işletme yedek alma işini otomatikleştiriyor, ancak yedek ne kadar süreyle saklanacağını çoğu zaman net tanımlamıyor. Bir noktada güvenlik ekibi, hukuk birimi ve finans aynı masaya oturuyor: “Hem KVKK/GDPR uyumlu olalım, hem olası bir veri kaybında geriye dönük yeterince yedeğimiz kalsın, hem de depolama maliyeti patlamasın”. İşte bu üçgenin tam ortasında yedek saklama süresi politikası duruyor.

Bu yazıda DCHost ekibi olarak pratikte işe yarayan bir bakış açısı paylaşacağız: Yedeklerinizi nasıl sınıflandırmalı, KVKK ve GDPR ilkelerini saklama sürelerine nasıl tercüme etmeli, depolama katmanlarınızı (sıcak/soğuk/arşiv) nasıl planlamalı ve tüm bunları yönetilebilir bir maliyetle nasıl dengelemeniz gerektiğini adım adım konuşacağız. Teorik hukuk cümlelerinden çok, gerçek dünyada hosting, VPS, dedicated ve colocation altyapılarında uygulanabilir bir yedek saklama rehberi arıyorsanız doğru yerdesiniz.

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ı.

Örneğin;

• Bir e-ticaret sitesinde son 30 dakikayı kaybetmek kabul edilemez olabilir (sık yedek, kısa RPO),
• Ancak 3 yıl önceki bir sepet verisini saklamak, KVKK açısından ciddi bir sorgu konusu olabilir,
• Ve tüm verileri 10 yıl boyunca hızlı NVMe disklerde tutmak, bütçeyi mantıksız düzeyde zorlayabilir.

Ö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

İki mevzuat da (KVKK ve GDPR) size doğrudan “yedekler şu kadar yıl saklanmalıdır” demez. Bunun yerine şu ilkeleri koyar:

• Amaçla sınırlılık: Veriler, toplandıkları amaç için gerekli olduğu süre boyunca saklanabilir.
• Veri minimizasyonu: Gerekli olandan daha fazla veri ve daha uzun saklama süresi kullanılamaz.
• Saklama süresi ile sınırlı depolama: Süre dolduğunda veriler silinmeli, anonimleştirilmeli veya en azından erişilemez hale getirilmelidir.

Bu ilkeler, yedekler için de geçerli. Yani, “yedekte duruyor, zaten kimse bakmıyor” argümanı hukuken kabul edilmiyor. KVKK Kurulu kararlarında da yedekler açıkça kişisel veri işleme faaliyeti kapsamında değerlendiriliyor.

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? Çoğu mimaride geçmiş yedekleri tek tek açıp ilgili kaydı silmek teknik olarak gerçekçi değil. Hem maliyetli hem de yedeğin bütünlüğünü bozuyor.

Burada kabul gören pratik yaklaşım genelde şöyle:

• Yedekler için mantıklı ve sınırlı bir saklama süresi tanımlamak (örneğin; günlük yedekler 30 gün, haftalık yedekler 6 ay, aylık yedekler 1–3 yıl gibi),
• 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.

Yani amacı, “sınırsız yedek” değil; makul, gerekçelendirilebilir ve tekrarlanabilir bir saklama politikası oluşturmak olmalı.

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?
• Bu sürenin üstüne koyduğum yedek saklama marjı ne kadar olmalı?

Örneğin bir e-ticaret sitesinde faturalama verisi için vergi mevzuatı sebebiyle çoğu zaman 5–10 yıl arası saklama zorunluluğu varken, pazarlama izinleri için bu kadar uzun bir süreyi savunmak çok zor. Bu fark, yedek saklama süresi planınıza da yansımak zorunda.

GDPR’da Unutulma Hakkı ve Yedekler

GDPR altında “right to be forgotten” (unutulma hakkı) en çok tartışılan konulardan biri. Düzenleyici otoriteler, pratikte şu çizgiyi kabul ediyor:

• Üretim sistemlerinden veri makul sürede silinmeli,
• Yedekler ise tanımlı saklama süreleri dolduğunda rutin döngü içinde silinmeli,
• Bu süreç açık, kayıtlı ve denetlenebilir olmalı.

Yani yedekleriniz için, “süresiz” veya “ihtiyaç duyulana kadar” gibi yoruma açık tanımlar yerine, somut süreler (örneğin 90 gün, 1 yıl, 5 yıl) yazmanız gerekiyor.

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 faydasız hale gelir.
• 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.

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?

Pratikte sık duyduğumuz cümle: “Yedek önemli, silmeyelim, dursun.” Kâğıt üzerinde güvenli görünen bu yaklaşım, birkaç yıl içinde depolama tarafında kontrolden çıkmış maliyetler ve yönetilemeyen karmaşa üretir.

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 (incremental yedek ve deduplikasyonla 30–50 GB/yedek’e düşebilir)
• Saklama süresi: 365 gün

Sadece kaba bir hesapla bile 300 GB x 365 ≈ 110 TB gibi bir teorik üst sınır görürsünüz. Elbette pratikte incremental, sıkıştırma ve deduplikasyonla bu rakam düşer, ama temel mesaj değişmez: saklama süresi uzadıkça toplam maliyet, lineer değil çoğu zaman katlanarak artar.

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 en sağlıklı yolu, yedekleri erişim ihtiyacı ve hıza göre katmanlara bölmek:

• Sıcak yedekler: Son 7–30 gün; hızlı NVMe/SATA disklerde, anında geri dönüş için.
• 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.

DCHost altyapısında tipik senaryo; üretim verisini yüksek hızlı NVMe VPS veya dedicated sunucularda tutarken, uzun süreli yedekleri daha uygun maliyetli uzak depolama veya nesne depolama katmanlarına taşımak şeklinde oluyor. Böylece hem performanstan ödün verilmiyor, hem de “her şeyi pahalı disklerde saklama” tuzağına düşülmüyor.

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

Son yıllarda yedek saklama süresi tartışmasını en çok etkileyen konu fidye yazılımlar. Birçok vakada, saldırganlar sisteme sızdıktan sonra haftalarca sessiz kalıp yedeklerinizi de bozmaya çalışıyor. Siz saldırıyı fark ettiğinizde, son 7–14 günlük yedekleriniz de şifrelenmiş veya silinmiş olabiliyor.

Bu yüzden bugün tartışmamız gereken tek soru “kaç gün saklayalım” değil; aynı zamanda “bu yedekler saldırgandan gerçekten korunuyor mu?”. Burada nesne depolamada Object Lock gibi değiştirilemez (immutabe) yedek teknolojileri ciddi fark yaratıyor.

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

Genellikle kişisel veri işleme yoğunluğunun en az olduğu senaryo.

• 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.

Burada kritik nokta, “ne olur ne olmaz” diyerek 5–10 yıllık yedekler biriktirmek yerine, iyi tanımlanmış bir 1 yıllık yedek politikasına sahip olmak. Daha uzun süreli saklama ihtiyacınız varsa, bunu hukuki gereklilikle destekleyebilmelisiniz.

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 verileri: Vergi ve ticaret mevzuatı gereği 5–10 yıl saklama zorunluluğu olabilir.
• Sepet, davranışsal veriler ve pazarlama tercihleri: Amaçla sınırlı, çoğu zaman 2–3 yılı aşan süreler tartışmalı hale gelir.
• Ödeme kartı verileri: PCI DSS gereklilikleri nedeniyle mümkün olduğunca saklamama veya tokenizasyon kullanma yönünde tasarlanmalı.

Bu tür projelerde yedek saklama politikasını, sadece KVKK/GDPR değil aynı zamanda PCI DSS uyumluluğu ile birlikte düşünmek gerekiyor. Örneğin; tam yedekleri uzun süre saklarken, gereksiz detayları anonimleştirme veya maskeleme stratejileri geliştirebilirsiniz.

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:

• Genel sistem yedekleri + müşteri bazlı ek yedek politikaları tanımlamak,
• Müşteri sözleşmelerine saklama sürelerini açıkça yazmak,
• Terketme (offboarding) senaryosunda, verinin hangi sürede silineceğini netleştirmek,
• KVKK/GDPR’e göre veri sorumluluğu ve veri işleyen rollerini netleştirmek gerekiyor.

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

Şimdi teoriyi somut bir karar sürecine dönüştürelim. Aşağıdaki adımları DCHost tarafında birçok müşterimizle birlikte uyguluyoruz; siz de kendi projenize birebir uyarlayabilirsiniz.

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?

Böylece kişisel verisi ağır olan yedekler için daha dikkatli, belki daha kısa saklama süreleri; sadece teknik meta veri veya anonim veriler içeren yedekler için daha uzun saklama süreleri tanımlayabilirsiniz.

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 minimum saklama sürelerini not edin. Özellikle uluslararası projelerde, bir veri birden fazla ülke mevzuatına tabi olabilir; bu durumda genelde en katı olan gereklilik esas alınır.

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

Artık elinizde yeterli veri var. Şimdi her veri tipi için şu formatta bir politika yazabilirsiniz:

• 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.

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

Saklama politikanız ancak otomasyona döktüğünüzde gerçekten işe yarar. Aksi halde bir süre sonra manuel iş yükü ve insan hatası nedeniyle politikadan sapmalar başlar.

Burada şunları planlayın:

• cPanel, DirectAdmin, Plesk veya VPS üzerinde otomatik döngüsel yedek silme (örneğin; son 30 günden fazlasını tutma),
• Nesne depolama tarafında lifecycle (ömür döngüsü) kuralları ile belirli yaşı geçen objeleri otomatik silme veya daha ucuz depoya taşıma,
• Yedekleri mutlaka şifreli tutmak ve anahtar rotasyon politikası belirlemek.

Bu noktada Restic ve Borg ile S3 uyumlu uzak yedekleme yazımız, versiyonlama, şifreleme ve saklama politikasını birlikte ele almanız için güzel bir referans olabilir.

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

KVKK/GDPR tarafında en çok unutulan detaylardan biri bu. Yedek saklama politikanızı kağıda dökmeden ve uygulamada ne yaptığınızı kayıt altına almadan, denetimlerde kendinizi savunmanız zordur.

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.

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.

DCHost Altyapısında Yedek Saklama Süresini Yönetmek

DCHost olarak paylaşımlı hosting, VPS, dedicated ve colocation ortamlarında müşterilerimizle en sık konuştuğumuz konulardan biri, yedeklerin nerede ve ne kadar süreyle tutulacağı. Burada tipik olarak şu mimarileri öneriyoruz:

• Paylaşımlı hosting: Panel içi otomatik günlük yedekler + isteğe bağlı uzak depolama yedekleri. Saklama sürelerini paket seviyesinde veya isteğe özel yapılandırmak mümkün.
• VPS ve dedicated sunucu: Makine üzerinde snapshot, dosya sistemi seviyesinde yedek ve ek olarak uzak S3 uyumlu depo kullanımı. Böylece farklı saklama sürelerine sahip çok katmanlı bir yedek yapısı kurulabiliyor.
• Colocation: Kendi donanımınızı DCHost veri merkezinde barındırırken, yedekleri DCHost nesne depolama veya yedek sunucularına alarak hem fiziksel hem mantıksal ayrım sağlayabilirsiniz.

KVKK ve GDPR uyumluluğu açısından, sadece saklama süresi değil, veri lokasyonu da kritik. Türkiye, Avrupa veya farklı bölgelerdeki veri merkezleri arasında nasıl bir strateji kurmanız gerektiğini, KVKK ve GDPR uyumlu hosting nasıl kurulur rehberimizde ayrıntılı anlattık. Yedek saklama süresi politikanız, mutlaka bu veri yerelleştirme stratejisiyle uyumlu olmalı.

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

Yedek saklama süresi, “bir kez yazıp raflara kaldıracağınız” bir doküman değil. Uygulamanız büyüdükçe, yasal mevzuat güncellendikçe ve tehdit ortamı (özellikle ransomware) değiştikçe, bu politikayı da gözden geçirmeniz gerekiyor. İyi haber şu ki, temelde doğru kurgulanmış bir politika; hem KVKK/GDPR tarafında sizi rahatlatır, hem felaket anında geri dönüşünüzü hızlandırır, hem de depolama maliyetini öngörülebilir kılar.

Ö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.

DCHost olarak ister basit bir blog, ister yoğun trafikli bir e-ticaret, ister çok kiracılı bir SaaS altyapısı çalıştırın; yedekleme ve saklama stratejinizi birlikte gözden geçirebilir, ihtiyaçlarınıza uygun bir politika ve mimari tasarlayabiliriz. Mevcut yedeklerinizi, saklama sürelerinizi ve veri lokasyonunuzu masaya yatırmak isterseniz, teknik ekibimizden detaylı bir değerlendirme talep ederek işe başlayabilirsiniz.