Veritabanı yedekleme: Sıklık ve saklama süreleri nasıl belirlenir?

Veritabanı yedekleme; dosya yedeklemekten çok daha stratejik bir konudur. Çünkü kayıp sadece veri miktarı değil, geri dönüş (restore) süresi ve uygulamanın devreye alma hızını da belirler. Bu yazıda, RPO/RTO hedeflerinizi temel alarak MySQL/MariaDB ve genel senaryolarda yedekleme sıklığını ve saklama sürelerini net bir çerçeveyle nasıl belirleyeceğinizi öğreneceksiniz. Ayrıca “yedek var ama işe yaramıyor” problemini azaltmak için test ve doğrulama adımlarını da ekleyeceğim.

1) Önce hedefleri yazın: RPO ve RTO

Yedek sıklığını artırmak genellikle daha güvenli hissi verir; ancak maliyet (I/O, ağ, depolama) ve restore süresi gerçek kısıtları oluşturur. Bu yüzden önce iki değeri belirleyin:

RPO (Recovery Point Objective): En fazla kaç veri kaybını kabul edersiniz? Örn: "maksimum 15 dakika".
RTO (Recovery Time Objective): Kurtarma işleminden sonra sistemi en geç ne kadar sürede ayağa kaldırmalısınız? Örn: "2 saat".

Sık kullanımlı hedef eşleştirmesi (pratik)

Aşağıdaki tablo, tipik uygulama türlerinde sık görülen hedefleri özetler. Bunlar “tek doğru” değil; ama karar vermeyi hızlandıran başlangıç değerleridir.

Uygulama tipi	Varsayılan risk	Hedef RPO	Hedef RTO	Yedekleme yaklaşımı
Kurumsal site (düşük yazma)	Veri değişimi nadir	24 saat	6-12 saat	Günlük tam + uzun saklama
E-ticaret (yüksek yazma)	Sipariş/stock kritik	15-60 dk	1-4 saat	Saatlik fark/inkremental + kısa saklama
İç panel / raporlama	Yanlış rapor etkili	1-4 saat	2-8 saat	Sık mantıksal yedek + doğrulama
Oyun/konum/benzeri gerçek zaman	Çok yüksek yazma	5-15 dk	30 dk-2 saat	Sürekli replikasyon + noktasal geri yükleme

Net kural

RPO ne kadar küçükse, yedek sıklığı o kadar sık olmalıdır.
RTO ne kadar küçükse, restore süresini kısaltmak için yedek boyutu ve formatı (tam vs inkremental) dikkatle tasarlanmalıdır.

2) “Tam yedek mi, inkremental mi?” seçimi: maliyet ve restore dengesi

MySQL/MariaDB evreninde çoğu ekip iki ana yoldan ilerler:

Tam yedek (full backup): Belirli aralıklarla tüm veritabanı dışa aktarılır.
Artımlı/inkremental (incremental) veya fark (differential): Sadece değişen kısım alınır; restore için daha fazla adım gerekebilir.

Pratik karar matrisi

Aşağıdaki liste, hangi yaklaşımın daha mantıklı olacağını hızlıca belirler:

Restore süresi çok kritikse (RTO düşük):
Tam yedek + sık “daha küçük” yedek kombinasyonları tercih edilir.
Depolama maliyeti kritikse:
İnkremantal/diferansiyel yaklaşım avantaj sağlar.
Veri bütünlüğü ve doğrulama şartsa:
Yedeklerin mantıksal (logical) veya fiziksel (physical) olarak test edilmesi gerekir (aşağıda detay var).

3) Yedek sıklığını belirleme: RPO’ya göre net plan şablonları

Aşağıdaki planlar; MySQL/MariaDB kullanan VDS/VPS veya kendi altyapınız için uygulanabilir düşünülmüştür. Uygulamada en kritik nokta: yedeklerin “ne sıklıkla alındığı” kadar “ne kadar sık test edildiği”dir.

Plan A: Düşük-orta risk (RPO 24 saat, RTO 6-12 saat)

Tam yedek: günde 1 kez (ör. 02:00)
Saklama:
30 gün tam yedek sakla
Sonra haftalık özet/derleme (opsiyonel): 90 güne kadar

Bu plan; içerik güncellemesi seyrek, veri kaybı maliyeti düşük ekipler için uygundur.

Plan B: Standart iş yükü (RPO 1 saat, RTO 1-4 saat)

Tam yedek: haftada 1
Ek/inkremental veya fark: saatte 1
Saklama:
Saatlik yedek: son 48-72 saat
Haftalık tam yedek: 8-12 hafta

Bu kombinasyon, “son saatlerdeki kaybı sınırlama” ve “restore süresini makul tutma” dengesini iyi kurar.

Plan C: Yüksek risk (RPO 15 dakika, RTO 30-120 dk)

Tam yedek: her gün (veya 12-24 saatte bir)
İnkremental/fark: 15 dakikada 1
Saklama:
15 dk setleri: 24-72 saat
Daha eski inkrementaller: ihtiyaca göre 7-30 gün

Bu seviyede sadece yedek almak yetmez; aynı zamanda hızlı restore için test ve otomasyon gerekir.

Plan D: Sürekli veri (RPO 5-15 dk)

Uygulama genellikle replikasyon + yedek kombinasyonu ile ele alınır.
Saklama: “noktasal geri yükleme (point-in-time recovery)” yapabileceğiniz şekilde binlog/wal aralığı tanımlanır.

Not: Burada yaklaşım MySQL/MariaDB’nin replikasyon ve log stratejisine göre değişir; tek bir evrensel ayar yoktur.

4) Saklama süreleri: “kaç gün” sorusunun teknik cevabı

Saklama süresi; yalnızca depolama maliyeti değil, geri dönüş senaryosunda hangi noktaya geri döneceğinizle ilgilidir.

Saklama planını belirleyen 4 kriter

RPO ile uyum: Kayıp kabul ettiğiniz zaman aralığının üzerinde yedek tutun.
İnsan hatası süresi: Yanlışlık (ör. yanlış update) bazen aynı gün fark edilmez.
Uygulama değişiklikleri: Yayın (release) sonrası bir gün içinde sorun fark ediliyorsa, “restore kolaylığı” için log/yedek aralığı gerekir.
Uyumluluk (compliance): KVKK, şirket içi politika veya müşteri sözleşmeleri belirli süreler isteyebilir.

Pratik saklama kılavuzu

Aşağıdaki öneriler, belirli RPO düzeylerinde sık kullanılan saklama yapılarını gösterir:

RPO 24 saat:
Günlük tam: 30-90 gün
En eski dönem: “sadece ay sonu” gibi indirgeme
RPO 1 saat:
Saatlik: 3 gün
Günlük/haftalık tam: 8-12 hafta
RPO 15 dakika:
15 dk: 1-3 gün
Günlük tam: 30-90 gün

Bu sayılar “genel hedef” gibi düşünülmelidir; en doğrusu sizin veri değişim hızınıza ve test sonuçlarınıza göre güncellenmesidir.

5) Yedek doğrulama (verification) ve test: yedek almayı bitirmeyin

En yaygın sorun: Yedek dosyası oluşur ama restore edilemez. Bunun nedeni sıkça şunlardır: disk doluluğu, yetki hatası, şifre değişikliği, eksik tablo uzantıları, bozuk compress formatı veya yanlış restore prosedürü.

Doğrulama için kontrol listesi

Yedek üretimi başarılı mı? (job exit code, log satırları)
Dosya boyutu mantıklı mı? (ör. son saat çok düşük veri kaydıysa bile “0 byte” olmamalı)
Checksum/doğrulama mümkün mü? (destekliyorsa hash doğrulama)
Restore denemesi var mı? (en azından staging ortamında)

Test sıklığı

Kritik sistemlerde: haftada 1 restore testi (staging’e)
Düşük risk: ayda 1
Ayrıca her büyük schema değişikliğinde (ör. büyük migrasyon) “mini restore” testi yapın.

Restore stratejisini netleştirin

Restore prosedürü için yazılı bir akış oluşturun: - Yedeği nereye geri yükleyeceğiniz (ayrı DB adı/ortam) - Uygulamayı ne zaman ayağa kaldıracağınız - Bağlantı servislerini (connection strings) nasıl yöneteceğiniz - Gerekirse tersine veri/rollback adımı

6) MySQL/MariaDB için “sıklık ve saklama”yı somutlaştıran örnek senaryolar

Aşağıdaki örnekler, tek bir komut veya tek sağlayıcıya bağlı olmayan; mantıksal bir tasarım verir.

Senaryo 1: WooCommerce benzeri e-ticaret (RPO 1 saat)

Saatlik inkremental + günlük tam
Saklama:
Saatlik: 72 saat
Günlük tam: 30 gün
Haftada 1 tam yedek de tutularak restore hızlandırılır.

Senaryo 2: Kurumsal site + içerik paneli (RPO 24 saat)

Günlük tam yedek
Saklama: 60-90 gün
Aylık ayıklama: son 90 gün + son 12 ayın “özet” yedekleri

Senaryo 3: Veri tabanı üzerinde sık manuel işlem (RPO 4 saat)

4 saatte bir fark/inkremental
Günlük tam
Saklama:
4 saatlik: 14-21 gün
Günlük tam: 90 gün

Bu senaryoda asıl amaç “yanlış işlem gerçekleştiğinde makul sürede geri dönmek”tir.

7) Uygulama seviyesinde yedek sıklığını etkileyen 6 somut faktör

Sıklık planınızı bozabilecek etkenleri önceden hesaba katın:

Yazma yoğunluğu: Saatte çok fazla INSERT/UPDATE varsa inkremental yedek hacmi artar.
Tablo boyutu: Çok büyük tablolar restore süresini belirler.
Şema değişiklikleri: DDL değişimleri restore doğruluğunu etkileyebilir.
Disk I/O sınırları: Yedekleme sırasında kaynak tüketimi performansı düşürür.
Ağ bant genişliği: Bulut depoya gönderim hızını etkiler.
Erişim ve şifre yönetimi: Yedek aracı DB yetkilerini ve bağlantı bilgilerini doğru almalı.

Sonuç: Net bir plan çıkarın, sonra test edin

Veritabanı yedekleme sıklığı ve saklama sürelerini tek bir “günlük kural” ile belirlemek doğru değildir. Bunun yerine RPO/RTO hedeflerinizden başlayın; tam + inkremental kombinasyonunu veri değişim hızınıza göre seçin; ardından yedeklerinizi restore testi ile doğrulayın. Bugün aksiyon olarak: mevcut yedeklerinizin son 30 günde kaç kez restore testi aldığını kontrol edin, sonra RPO hedefinize göre saatlik/günlük saklama yapısını netleştirip yazılı bir prosedürle sabitleyin.