SaaS İçin Müşteri Verisi Yedekleme ve Saklama Politikası

SaaS ürününüz büyürken yedek ve veri saklama stratejiniz de büyüyor

SaaS uygulamalarında CPU/RAM, ölçeklenebilirlik ve çok kiracılı mimari kadar müşteri verisi yedekleme ve veri saklama politikaları da planlanmalıdır. “Sunucu tarafında günlük yedek var” demek tek başına bir kurtarma planı değildir. Ne yazık ki bu cümle, gerçek bir veri kaybı yaşandığında işinizi, markanızı ve hukuki sorumluluğunuzu korumak için yeterli değil.

Özellikle abonelikli, çok kiracılı (multi-tenant) SaaS ürünlerde, müşterinizin üretim verisi sadece bir veritabanı tablosu değil; faturalama kayıtları, loglar, dosya ekleri, kullanıcı davranışları, entegrasyon verileri ve yasal yükümlülüklerinizin hepsi aynı resmin parçaları. Bu makalede, SaaS uygulamaları için müşteri verisi yedekleme ve veri saklama politikalarını teknik ve pratik açıdan masaya yatıracağız. RPO/RTO hedeflerini nasıl tanımlamalı, 3‑2‑1 yedekleme stratejisini SaaS mimarisine nasıl uyarlamalı, KVKK/GDPR gibi düzenlemelerle hosting tarafında nasıl uyumlu kalmalı ve bunları seçtiğiniz hosting altyapısında uygulamak için hangi gereksinimleri değerlendirmelisiniz, adım adım konuşacağız.

Yedekleme ve veri saklama politikasını kâğıda dökmeden önce

Sağlam bir yedekleme ve veri saklama politikası, teknik seçimlerden önce zihinde başlar. Önce bazı kavramları netleştirmek gerekiyor:

• RPO (Recovery Point Objective): Bir sorun yaşandığında maksimum ne kadar veri kaybını kabul edebilirsiniz? (örneğin 15 dakika, 1 saat, 24 saat)
• RTO (Recovery Time Objective): Sisteminizi ne kadar süre içinde tekrar ayağa kaldırmanız gerekiyor? (örneğin 15 dakika, 2 saat, 24 saat)
• Veri sınıflandırması: Operasyonel veriler, arşiv veriler, loglar, analitik veriler, yasal zorunluluk verileri (fatura vb.)
• Uyumluluk gereksinimleri: KVKK, GDPR, sektöre özel standartlar (ör. finans, sağlık, eğitim)
• Müşteri beklentisi: SLA sözleşmelerinizde müşteriye ne vaat ediyorsunuz? Silinmiş veriyi geri getirme, hesap kapatıldığında veri imhası vb.

Örneğin bir proje planlama toplantısında, ürün ekibiniz “Raporlama verisini 3 yıl saklasak yeter” diyebilir; ama finans ekibi yasal saklama süreleri nedeniyle faturalama verisinin 10 yıl saklanmasını isteyebilir. Bu farklı gereksinimler, hosting tarafında farklı yedekleme ve saklama politikaları tanımlamanız gerektiği anlamına gelir.

Uyumluluk boyutunu daha detaylı ele almak istiyorsanız, KVKK ve GDPR odağında hazırladığımız KVKK ve GDPR uyumlu hosting rehberini mutlaka gözden geçirmenizi öneririz.

SaaS için veri saklama politikası nasıl tasarlanmalı?

SaaS uygulamalarında veri saklama politikası, basitçe “Tüm yedekleri 30 gün tutalım” demekten çok daha detaylıdır. Farklı veri türleri için farklı süreler, anonimleştirme stratejileri ve müşteri bazlı kurallar tanımlamak gerekir.

1. Veri türlerini ayırmadan politika yazmayın

Önce hangi veri setlerine sahip olduğunuzu kabaca haritalayın:

• Birincil üretim verisi: Kullanıcı hesapları, uygulama içi kayıtlar, ilişkisel veritabanı tabloları (MySQL/PostgreSQL vb.)
• Dosya ekleri / objeler: Yüklenen belgeler, görseller, ihracat/rapor dosyaları (genellikle object storage veya dosya sistemi)
• Loglar: Uygulama logları, erişim logları, güvenlik logları
• Analitik/veri ambarı: Olay verileri, tıklama akışları, iş zekâsı raporlarına giden ham veri
• Faturalama ve sözleşme verileri: Ödeme kayıtları, e‑fatura bilgileri, Sözleşme metinleri (çoğu zaman yasal minimum saklama süreleri ile bağlı)

Her veri türü için ayrı saklama süresi belirlemek hem maliyet hem de yasal uyum açısından kritik. Örneğin:

• Uygulama logları: 90 gün (güvenlik ve hata analizi için yeterli olabilir)
• Güvenlik logları: 1–2 yıl (uygulanan mevzuata göre değişir)
• Analitik olay verisi: 12–24 ay (trend analizi ve ürün kararları için)
• Faturalama verisi: İlgili ülke mevzuatında belge türü ve tabi olunan yükümlülüklere göre belirlenen süre

2. Silme, anonimleştirme ve arşiv süreçlerini ayırın

Veri saklama politikası sadece “ne kadar süreyle tutacağız” değil, sürenin sonunda ne yapacağımızı da tanımlar:

• Aktif veri → Arşiv veri: Sık erişilmeyen fakat hukuki veya operasyonel nedenle saklanması gereken veriyi daha ucuz depolamaya taşıma.
• Anonymization (anonimleştirme): Verinin başka verilerle eşleştirilerek de bir kişiyle ilişkilendirilemeyecek hale getirilmesi. Yalnızca PII (kişisel tanımlayıcı) alanlarını maskelemek anonimleştirme anlamına gelmez.
• Hard delete (kalıcı silme): Saklama yükümlülükleri ve silme koşulları değerlendirilerek verinin kalıcı olarak kaldırılması. Üretimden silme, arşiv ve yedek kopyalarının da aynı anda imha edildiği anlamına gelmez; bu kopyalar için ayrı imha süreleri ve yöntemleri tanımlanmalıdır.

Buradaki en kritik nokta, yedeklerinizin de bu politikanın parçası olması. Üretim verisini sildiğiniz halde, 1 yıl boyunca sakladığınız tam yedeklerde kişisel veriler bulunmaya devam edebilir. Bu nedenle “yasal silme talebi geldiğinde yedeklerdeki verinin akıbeti” yazılı politikada tanımlanmalı; erişim kısıtları, imha takvimi ve geri yükleme sonrasında silme işlemlerinin yeniden uygulanması ele alınmalıdır.

3. Müşteri seviyesinde özelleştirilebilir saklama

B2B SaaS ürünlerde bazı büyük kurumsal müşteriler, sözleşmelerine kendi veri saklama politikalarını yazdırmak isteyebilir. Örneğin:

• “Logların minimum 1 yıl saklanması”
• “Silinmiş kayıtların 180 gün boyunca kurtarılabilir olması”
• “Hesap kapatma sonrası tüm verinin 30 gün içinde silinmesi”

Bu talepleri sözleşmeye almadan önce birbirleriyle ve yasal saklama yükümlülükleriyle uyumlarını değerlendirin; örneğin 180 günlük kurtarılabilirlik ile hesap kapatıldıktan sonra 30 günde tüm kopyaların silinmesi için öncelik ve kapsam belirlenmelidir. Mimarinizi de kiracı (tenant) bazlı saklama politikalarını uygulayacak şekilde tasarlayın. Bu her zaman fiziksel olarak ayrı veritabanları anlamına gelmez; mantıksal işaretler ve ayrı saklama iş akışları kullanılabilir. Ancak birden çok kiracıyı içeren ortak yedeklerde etiketleme tek başına kiracıya özel silme veya saklama süresi sağlamaz; yedek düzeni bu işlemleri gerçekten desteklemelidir.

SaaS için yedekleme stratejisinin temel taşları

Veri saklama politikasını netleştirdikten sonra, işin hosting ve altyapı tarafına yani “Bu politikayı yedekleme stratejisine nasıl çeviririm?” sorusuna geçebiliriz.

1. 3‑2‑1 kuralını SaaS dünyasına uyarlamak

Yedeklemede altın kural olarak bilinen 3‑2‑1 stratejisi kısaca şöyle der:

• 3 kopya: Verinizin en az 3 kopyası olmalı (1 üretim, 2 yedek).
• 2 farklı ortam: Bu kopyalar en az 2 farklı depolama türünde tutulmalı (örneğin NVMe blok depolama + object storage; yalnızca erişim türünün farklı olması, alttaki depolamanın bağımsız olduğunu göstermez).
• 1 offsite: En az 1 kopya farklı bir fiziksel lokasyonda bulunmalı.

Varsayımsal bir SaaS mimarisinde, kopyaların depolama ve lokasyon bağımsızlığı doğrulanarak şu kombinasyon değerlendirilebilir:

• Üretim veritabanı: Gereken disk türü (örneğin NVMe) ve kapasiteye göre seçilecek VPS veya dedicated sunucu
• Aynı veri merkezinde, üretim depolamasının kaybından bağımsız olarak geri yüklenebilecek günlük snapshot yedekler
• Farklı bölgede (veya farklı veri merkezinde) şifreli object storage üzerinden uzak yedekler

Bu stratejinin pratik kurulumu için rehber arıyorsanız, 3‑2‑1 yedekleme stratejisi ve otomatik yedek kurulum rehberine göz atabilirsiniz; oradaki prensipleri SaaS ortamınıza kolayca uyarlayabilirsiniz.

2. Uygulama-tutarlı yedekler: Sadece dosyaları değil, durumu yakalamak

SaaS veriniz çoğunlukla bir ilişkisel veritabanında (MySQL, MariaDB, PostgreSQL) ve yanında dosya/object storage alanında yaşıyorsa, yedeğinizin gerçekten işe yarar olması için uygulama-tutarlı olması gerekir. Yani yedek alındığı anda:

• Veritabanı yazma işlemleri tutarlı bir noktaya getirilmeli (örneğin kısa süreli freeze veya transaction snapshot)
• Dosya sistemi veya object storage yedeği ile veritabanı yedeği aynı mantıksal uygulama durumunu temsil etmeli; yalnızca yakın saatlerde alınmaları yeterli değildir

Linux tarafında LVM snapshot ve fsfreeze gibi araçlarla nasıl uygulama-tutarlı yedek alabileceğinizi adım adım anlattığımız uygulama-tutarlı yedekler rehberi, SaaS veritabanlarınız için değerlendirebileceğiniz bir başlangıç noktasıdır; yöntemi veritabanınızın tutarlılık gereksinimlerine ve dosya/object storage iş akışlarına göre uyarlamalısınız.

Point‑in‑Time Recovery (PITR), PostgreSQL ve MySQL’de farklı günlük akışlarına dayanır. PostgreSQL’de bir temel yedek (base backup) ve en az bu yedeğin başlangıcından hedef ana kadar kesintisiz arşivlenmiş WAL zinciri gerekir; WAL arşivlemesi ilk temel yedekten önce kurulup doğrulanmalıdır. pgBackRest, yedekleri ve WAL arşivlemesini yönetebilir. MySQL’de ise kullanılan sürümle uyumlu bir fiziksel/temel yedek geri yüklendikten sonra, yedeğe karşılık gelen konumdan hedef ana kadar ayrı saklanan binary log kayıtları uygulanır; binary logging etkinliği ve günlüklerin saklanması doğrulanmalıdır. XtraBackup temel yedeği sağlayabilir; yedeği hazırlarken kullandığı redo kayıtları, PITR için gereken binary log akışının yerine geçmez. Bunlar “sürekli inkremental dosya yedeği” ile aynı şey değildir. Her iki tasarımda da yedek ve günlük saklama süreleri kurtarma penceresini kapsamalı; günlük zincirinin kesintisizliği, arşivleme başarısı ve gecikmesi izlenmelidir. Dakikalar düzeyinde RPO, araç seçiminden otomatik olarak doğmaz: arşivleme gecikmesine ve gerçekten kurtarılabilir günlüklere bağlıdır. Geri yükleme testlerinde erişilebilen son veri noktası ve kurtarma süresi ölçülerek RPO/RTO hedefleriyle karşılaştırılmalıdır.

3. Yedek tipleri: Full, incremental, differential dengesini kurmak

SaaS ölçeğiniz büyüdükçe, her gece tam yedek almak depolama maliyetini ve yedekleme süresini artırabilir. Tam yedek seçilen veri setinin tamamını, incremental yedek son yedekten sonraki değişiklikleri, differential yedek ise son tam yedekten sonraki değişiklikleri kapsar. Geleneksel zincir modelinde incremental geri yükleme için tam yedek ve sonraki incremental zinciri; differential geri yükleme için tam yedek ve seçilen differential yedek gerekir. Seçtiğiniz aracın bağımlılıklarını doğrulayın ve saklama politikasıyla gerekli zinciri koruyun. Değişen veri miktarı ve geri dönüş hedeflerine göre değerlendirilebilecek bir model:

• Haftada 1 tam yedek (full backup)
• Günlük incremental (son yedekten bu yana değişen bloklar/kayıtlar)
• Önemli şema değişiklikleri öncesi ekstra tam yedek

Dosya tabanlı çözümlerle (restic, borg vb.) uzak yedekleme tasarlarken, seçilen araç ve sürümün hedef depolamayı, sıkıştırmayı ve deduplication’ı nasıl desteklediğini değerlendirin. Object storage’a aktarım yolunu da aracın desteklediği depolama arayüzüne göre belirleyin. Bu yaklaşımı restic ve borg ile S3 uyumlu uzak yedekleme rehberimizde daha teknik detaylarıyla anlattık.

4. Object storage, block storage ve dosya sistemi: Hangisini nerede kullanmalı?

SaaS mimarinizde genellikle üç farklı depolama türüyle karşılaşırsınız:

• Block storage: Veritabanı diskleri (NVMe/SATA SSD), düşük gecikme, yüksek IOPS için ideal.
• Object storage: Dosya ekleri, rapor çıktıları, uzun süreli yedekler; sürümleme ve yaşam döngüsü (lifecycle) politikalarıyla birlikte.
• File storage: Paylaşılan dosya sistemleri, container ortamlarında paylaşımlı volume’ler.

Yedekleme tarafında veritabanı ve dosya/object yedekleri için object storage değerlendirilebilir. Uzun süreli saklama ve coğrafi replikasyon için depolama seçimini maliyet, geri yükleme süresi, erişim modeli ve desteklenen koruma özelliklerine göre yapın. Bu mimariyi teoriden pratiğe taşımak için, object vs block vs file storage rehberimiz size iyi bir çerçeve sunar.

Coğrafi yedeklilik, felaket kurtarma ve RTO/RPO hedefleri

Tek veri merkezine bağımlılık, merkez genelindeki bir arızada hizmeti ve aynı yerdeki yedekleri birlikte etkileyebilir. Felaket kurtarma (DR) senaryolarını ve coğrafi yedeklemeyi SaaS tasarımınızın erken safhasına koymazsanız, sonradan eklemek hem zor hem pahalı oluyor.

1. Coğrafi replikasyon ve cross-region yedekler

Günlük yedeğinizi aynı bölgesel olaydan etkilenmeyecek bir veri merkezine kopyalamak, yangın, sel, elektrik veya fiber kesintisi gibi olaylarda kurtarma imkânı sağlayabilir. S3 uyumluluğu tek başına bu özelliği garanti etmez; seçtiğiniz depolama sistemi çapraz bölge replikasyonu (cross-region replication) destekliyorsa kopyalamayı otomatikleştirmek için kullanabilirsiniz.

Bu yapıyı MinIO gibi S3 uyumlu sistemlerle kendi VPS’iniz üzerinde kurmak istiyorsanız, adım adım anlattığımız S3/MinIO’da çapraz bölge replikasyon rehberi hem teknik adımları hem de DR runbook planlamasını detaylı şekilde ele alıyor.

2. Felaket kurtarma planı ve runbook’lar

Yedeğinizin olması başka, o yedekten gerçekten ve hızlıca dönebiliyor olmanız bambaşka bir şey. Bu yüzden yazılı bir felaket kurtarma planı ve adım adım runbook dokümanları kritik:

• Hangi senaryo için (disk çökmesi, veri merkezinin tamamen gitmesi, yanlışlıkla toplu silme vb.) hangi adımlar izlenecek?
• Önce hangi servisler ayağa kalkacak? (Kimlik doğrulama, veritabanı, API, web arayüzü, arka plan işler…)
• Hangi ekip üyesi ne yapacak, hangi erişimlere ihtiyaç var?

Bu süreci sıfırdan yazarken zorlanıyorsanız, felaket kurtarma planı nasıl yazılır rehberimiz hem RTO/RPO hedeflerini netleştirmede hem de pratik test senaryoları kurgulamada size yol gösterecektir.

3. Geri dönüş (restore) testleri: Politikaya yazıp gerçekten uygulamak

Kağıt üzerinde mükemmel bir yedekleme ve veri saklama politikanız olabilir; fakat yılda en az birkaç kez tam geri dönüş testi yapmıyorsanız, aslında ne kadar hazır olduğunuzu bilmiyorsunuz demektir. SaaS ortamları için önerdiğimiz minimum test seti:

• Aylık: Tek kiracının (tenant) verisini farklı bir ortama geri yükleme testi
• Üç aylık: Tüm veritabanını ve dosya eklerini izole bir ortamda ayağa kaldırma ve uygulamanın çalıştığından emin olma
• Yıllık: Farklı veri merkezine tam DR senaryosu simülasyonu
• Tüm testlerde: Kurtarma ortamına erişimi sınırlandırın; geri yüklenen uygulamayı başlatmadan önce dış e-posta, ödeme, webhook ve üretim kuyruklarına erişimi devre dışı bırakın. Arka plan işlerini yalnızca test hedefleriyle çalıştırın.

Bu testlerde ölçülen hizmeti geri getirme süresini RTO hedefinizle, geri yüklenebilen son veri noktası ile kesinti anı arasındaki veri kaybı aralığını da RPO hedefinizle karşılaştırın. Yedek alma süresini ayrıca izleyin; bu süre tek başına RTO veya RPO’yu göstermez.

KVKK, GDPR ve müşteri hakları

SaaS uygulamanızın kişisel veri işlemesi KVKK veya GDPR kapsamına giriyorsa, işleme ve saklama yükümlülüklerini üretim verisinin yanı sıra kişisel veri içeren yedekler ve loglar için de değerlendirmelisiniz.

1. Veri yerelleştirme ve veri merkezi seçimi

Bazı sektörlerde veya kurumsal müşterilerde, verinin ülke sınırları içinde saklanması açık bir gereksinim. Bu ihtiyaçlar için seçilecek hosting planında üretim verisinin, yedeklerin ve replikaların konumunu sözleşme ve teknik mimari üzerinden doğrulayın. Veri saklama politikanızda şu sorulara net yanıt vermelisiniz:

• Üretim verisi hangi ülkede/hangi veri merkezinde tutuluyor?
• Offsite yedekler hangi ülkede/hangi sağlayıcıda?
• Coğrafi replikasyon varsa, verinin gittiği her lokasyonda KVKK/GDPR uyumu nasıl sağlanıyor?

2. Silme talepleri ve yedekler

Kullanıcı “verilerimi silin” dediğinde veya bir müşteri hesabını kapattığında, genellikle şu sorular ortaya çıkar:

• Üretim verisini ne kadar sürede siliyorsunuz?
• Yedeklerdeki veriler ne oluyor, ne zaman tamamen yok oluyor?
• Loglarda yer alan IP, user‑agent gibi bilgiler ne kadar süreyle tutuluyor?

Silme prosedürünü tasarlarken şu noktaları belirleyin:

• Üretim verisinin silinme zamanını, talebin kapsamı ve uygulanabilir yasal saklama yükümlülükleriyle birlikte belirleyin; hesap kapatma için sunulan bir geri alma penceresini silme taleplerine otomatik olarak uygulamayın.
• Yedeklerdeki kişisel veriler için silme yöntemi ve takvimini belirleyin; yalnızca saklama süresini sözleşmede açıklamanın yeterli olduğunu varsaymayın. Silinene kadar erişimi sınırlandırın ve geri yükleme sonrasında önceki silme taleplerinin yeniden uygulanmasını sağlayın.
• Loglar için de saklama ve silme takvimi belirleyin. IP adresinin bir bölümünü maskelemek gibi işlemleri tek başına anonimleştirme saymayın; kalan alanların kişiyi yeniden belirlemeye elverişli olup olmadığını değerlendirin.

3. Müşteriye veri taşıma ve dışa aktarma imkânı sunmak

Veri dışa aktarma tasarımında, GDPR kapsamındaki “veri taşınabilirliği” hakkının hangi koşullarda ve hangi veriler için geçerli olduğunu ayrıca değerlendirin. JSON veya CSV gibi formatları dışa aktarılacak veri ve yeniden kullanım ihtiyacına göre seçin; SQL dump sunulacaksa yalnızca ilgili müşterinin yetkili olduğu verileri içerdiğini doğrulayın. Dışa aktarma, müşterinin kendi offline kopyasını tutmasına da yardımcı olabilir; ancak sağlayıcının yedekleme ve veri koruma sorumluluklarının yerine geçmez.

Pratikte önerimiz:

• Tenant bazlı veri dışa aktarma API’leri veya yönetim panelinden bir export özelliği sunmak
• Büyük müşteri hesapları için zamanlanmış, şifreli SFTP/S3 export entegrasyonlarını desteklemek

Hosting tarafında en iyi uygulamalar

Altyapı ve operasyon tarafında, yedeklerin erişim ayrımı, şifrelenmesi ve izlenmesi birlikte ele alınmalı.

1. Yedekler için ayrı depolama ve ayrı erişim katmanı

Önemli bir risk: Uygulama ile yedeklerin aynı disk, aynı kullanıcı hesabı ve aynı erişim kimlik bilgileri ile tutulması. Bir ransomware veya yetkili hesabın ele geçirilmesi senaryosunda hem üretim verisi hem yedekleriniz aynı anda şifrelenebilir veya silinebilir.

Bu riski azaltmak için:

• Yedekler için ayrı bir kullanıcı hesabı kullanın. Araç destekliyorsa yalnızca yeni veri eklemeye izin veren (append‑only) erişim tanımlayın; mevcut yedekleri değiştirme ve silme yetkilerini ayrı tutun. Genel yazma yetkisini append‑only korumasıyla eşdeğer saymayın.
• NFS gibi dosya sistemi olarak bağlanan yedek depolarını yalnızca yedekleme sırasında mount edin. Object storage erişimini kullanılan API veya bağlantı yöntemine göre sınırlandırın. Mount bağlantısını kaldırmak, sunucuda kalan kimlik bilgilerinin kullanımını tek başına engellemez.
• Mümkünse object storage tarafında immutable (değiştirilemez) yedek politikaları kullanın (S3 Object Lock benzeri mekanizmalar).

Bu konuyu S3 dünyasında daha derinlemesine anlattığımız S3 Object Lock ile fidye yazılıma karşı kale gibi yedek rehberimiz, SaaS yedeklerini tasarlarken size ciddi ilham verebilir.

2. Şifreleme: Hem hareket halinde hem de beklerken

Müşteri verisi hem ağ üzerinden taşınırken (in‑transit) hem de depolama üzerinde dururken (at‑rest) şifrelenmeli:

• Uygulama → veritabanı / object storage trafiği için TLS bağlantıları
• Yedekleme aracı seviyesinde uçtan uca şifreleme (ör. restic/borg ile client‑side encryption)
• Disk seviyesinde şifreleme (LUKS vb.) özellikle taşınabilir diskler veya colocation ortamlarında

Ayrıca şifreleme anahtar yönetimi (key management) politikanız, veri saklama politikanızın ayrılmaz bir parçası olmalı: Anahtar rotasyonu, kimde hangi yetkiler var, anahtar kaybı durumunda ne olacağı gibi sorulara yazılı yanıtlarınız olmalı. Yedekleri çözmek için gereken anahtarları yalnızca aynı şifreli yedeğin içinde veya kaybedilebilecek üretim sunucusunda tutmayın; ayrı, erişimi kontrollü bir kurtarma yolu sağlayın ve bu yolu restore testlerinde doğrulayın.

3. İzleme, alarm ve yedek başarısızlıklarının yönetimi

“Yedekleme işi çalışıyor” varsayımı en tehlikeli varsayımlardan biridir. Her yedek işinin sonucu izlenmeli, başarısızlıklar ve anormal boyut değişimleri (beklenenden çok küçük veya çok büyük yedekler) için alarmlar kurulmalı.

SaaS uygulamanızın yedekleme süreçlerinde Prometheus + Grafana veya benzeri izleme araçlarıyla şu göstergeleri takip edebilirsiniz:

• Son başarılı yedek zamanı
• Yedek boyutu ve süre trendleri
• Hata kodları ve kısmi başarısızlıklar

Bu izleme, yedekleme sorunlarının veri kaybına yol açmadan önce fark edilmesine yardımcı olabilir; yedeklerin geri yüklenebilirliğini ise restore testleriyle doğrulamak gerekir.

4. Ortam ayrımı: Geliştirme, staging ve üretim yedeklerini karıştırmayın

Geliştirme (dev), test/staging ve üretim (prod) ortamlarınız arasında net bir ayrım yoksa, yanlış ortamdan yanlış veriyi geri yüklemek veya gerçek müşteri verisini test ortamında unutmak gibi riskler artar. Önerimiz:

• Her ortam için ayrı yedekleme job’ları, ayrı depolama bucket’ları ve ayrı isimlendirme şemaları kullanın.
• Üretim verisini staging’e taşırken mutlaka anonimleştirme veya maskeleme uygulayın.

Gerçekçi bir SaaS yedekleme ve veri saklama politikası taslağı

Anlattıklarımızı somutlaştırmak için, orta ölçekli B2B SaaS ürünü için örnek bir politika iskeleti üzerinden gidelim. Bu, kendi belgenizi oluştururken size şablon olabilir. Aşağıdaki süreler ve hedefler varsayımsaldır; mevzuatın zorunlu kıldığı süreler veya doğrulanmış hizmet taahhütleri değildir. Saklama ve imha sürelerini veri türü, işleme amacı ve uygulanabilir mevzuata göre hukuk ekibinizle belirleyin; RPO/RTO hedeflerini geri yükleme testleriyle doğrulayın.

1. Kapsam ve amaç

“Bu politika, [ürün adı] SaaS hizmeti kapsamında işlenen tüm müşteri verilerini, logları ve yedekleri kapsar. Amacı, veri kaybı ve kesinti risklerini minimize etmek, KVKK/GDPR ve ilgili mevzuatla uyumlu bir saklama ve imha çerçevesi sunmaktır.”

2. RPO ve RTO hedefleri

• Standart müşteri hesapları için RPO: 4 saat
• Kurumsal paket müşterileri için RPO: 30 dakika
• Tüm müşteriler için RTO: 4 saat (bölgesel felaket durumunda 24 saate kadar uzayabilir)

3. Yedekleme sıklığı ve türü

• Veritabanı: PostgreSQL için günlük fiziksel temel yedek ve kesintisiz WAL arşivleme; MySQL için sürümle uyumlu günlük tam yedek, kaydedilmiş binary log konumu ve sonraki binary log kayıtlarının ayrı saklanması. Bu örnekte günlüklerin uzak depoda kurtarılabilir hale gelmesi için hedeflenen azami gecikme 15 dakikadır; yalnızca 15 dakikada bir iş çalıştırmak bu hedefi doğrulamaz. PostgreSQL mantıksal dump’ları WAL geri yüklemesine temel olamaz. Saklanan kurtarma noktalarının gerektirdiği temel yedekleri ve günlük zincirlerini birlikte koruyun.
• Dosya ekleri: RPO kapsamındaki değişiklikler için en fazla 30 dakikalık incremental yedekleme aralığı, haftalık tam yedek; veritabanıyla tutarlı geri dönüş noktalarının test edilmesi
• Konfigürasyon/veri tabanı şeması: Her değişiklik öncesi snapshot

4. Saklama süreleri

• Veritabanı yedekleri: 30 gün
• Dosya yedekleri: 90 gün
• Güvenlik logları: 1 yıl
• Uygulama logları: 90 gün
• Faturalama verisi: 10 yıl (aktif veya arşiv formunda)

5. Coğrafi yedeklilik

• Üretim verisi: Veri yerleşimi gereksinimlerine göre seçilmiş bir veri merkezinde
• Offsite yedekler: Farklı bir veri merkezinde, şifreli object storage üzerinde
• Haftalık DR senaryosu test restore’ları

6. Silme ve anonimleştirme prosedürleri

• Kullanıcı silme talebi: Kimlik, talebin kapsamı ve zorunlu saklama gerekçeleri değerlendirildikten sonra, silinmesi gereken üretim verisi için örnek iç hedef 30 gün; uygulanabilir yasal süreler esas alınır
• Yedeklerdeki veri: Belirlenmiş saklama süresi sonunda otomatik imha; bu süre boyunca erişimin sınırlandırılması ve geri yükleme sonrasında silme kayıtlarının üretime açılmadan önce yeniden uygulanması
• Loglardaki IP bilgilerinin 90 gün sonra anonimleştirilmesi

7. Sorumluluklar

• DevOps ekibi: Yedekleme job’larının işletimi ve izlenmesi
• Güvenlik ekibi: Şifreleme ve erişim kontrol politikalarının uygulanması
• Ürün ve hukuk ekipleri: Saklama süreleri ve müşteri sözleşmeleriyle uyum

DCHost ile SaaS verinizi güvence altına alırken nelere dikkat etmelisiniz?

SaaS uygulamanız için sağlayıcıdan bağımsız olarak şu mimari bileşenleri değerlendirebilirsiniz. Bunlar DCHost paketlerine dahil hizmetlerin listesi değildir; seçtiğiniz planda hangi bileşenlerin bulunduğunu, hangilerini ayrıca kurmanız veya temin etmeniz gerektiğini belirleyin:

• NVMe diskli VPS veya dedicated sunucu üzerinde veritabanı ve uygulama katmanı
• Ayrı bir object storage katmanı üzerinde şifreli yedekler
• Çapraz veri merkezi replikasyonu ile offsite kopyalar
• Otomatik yedekleme job’ları, merkezi loglama ve alarm mekanizmaları

Eğer mimariniz çok kiracılı (multi‑tenant) ise, bu konuya özel olarak hazırladığımız SaaS için çok kiracılı mimari ve doğru hosting altyapısı rehberini de mutlaka okumanızı öneririz. Oradaki mimari öneriler, burada anlattığımız yedekleme ve veri saklama stratejileriyle doğal şekilde birleşiyor.

Sonuç: Yedek, veri saklama ve felaket kurtarma; üçü bir arada

SaaS ürününüz teknik olarak ne kadar iyi olursa olsun, bir gün yanlış bir script, beklenmedik bir hata veya insani bir dalgınlık yüzünden verileriniz zarar görebilir. O an geldiğinde işinizi korumaya yardımcı olan şey; yalnızca günlük yedek almanız değil, iyi tasarlanmış, test edilmiş ve hukuken de ayakları yere basan bir yedekleme ve veri saklama politikasını uygulamanızdır.

Bu politikanın içinde net RPO/RTO hedefleri, farklı veri türleri için farklı saklama süreleri, KVKK/GDPR ile uyumlu silme ve anonimleştirme süreçleri, coğrafi yedeklilik, uygulama-tutarlı yedekler ve düzenli restore testleri yer almalı. Bunların hepsini tek seferde kusursuz şekilde kurmak zorunda değilsiniz; önemli olan, yazılı bir yol haritasına sahip olmak ve her çeyrekte bu haritayı küçük adımlarla hayata geçirmek.

Yeni bir SaaS projesi veya mevcut bir ürün için kapasite ve risk analizi yaparken veri hacmini, değişim hızını, yedek depolama ihtiyacını ve felaket kurtarma hedeflerini birlikte değerlendirin. Mimari tasarım, yedekleme otomasyonu ve kurtarma operasyonlarında hangi görevlerin kendi ekibinizde, hangilerinin sözleşmeyle hizmet sağlayıcıda olduğunu yazılı hale getirin.

Yazılı politikayı uygulama ve restore testleriyle desteklemek, olası veri kayıplarını ve kesintilerin etkisini azaltmaya yardımcı olur.