Veritabanı Yedekleme Sıklığı ve Saklama Süreleri Rehberi

Veritabanı yedeklemesi; hatalı işlem, veri bozulması, siber olay veya donanım arızası gibi senaryolarda sistemin ayağa kalkmasını belirler. Ancak “yedek alıyorum” demek tek başına yeterli değildir: sıklık ve saklama süresi doğru kurgulanmadığında ya geri dönüş süresi uzar ya da aynı hatayı tekrar tekrar geri alırsınız. Bu rehberde RPO/RTO hedefleriyle birlikte, farklı veritabanı tipleri için (MySQL/MariaDB, PostgreSQL) net yedekleme planı ve saklama takvimi oluşturacaksınız.

Yedek planını belirleyen 2 hedef: RPO ve RTO

Yedekleme stratejisini konuşurken ilk iş kavramları netleştirmektir.

• RPO (Recovery Point Objective): Son geri kazanılabilir veri kaybı. Örneğin 15 dakikalık RPO, maksimum 15 dakika veri kaybını kabul ettiğiniz anlamına gelir.
• RTO (Recovery Time Objective): Hizmetin ne kadar sürede geri dönmesi gerektiği. Örneğin RTO 2 saat ise geri yükleme + doğrulama + uygulama ayağa kalkması yaklaşık 2 saat içinde bitmelidir.

Bu iki hedef, yedekleme sıklığını doğrudan etkiler. Aşağıdaki ilişkiyi pratikte şöyle okuyun:

• RPO küçükse → yedek sıklığı artırılır (veya değişiklik logları daha sık saklanır).
• RTO küçükse → yedek geri yükleme süresi kısaltılır (yedek boyutu, sıkıştırma, paralel restore planı, doğrulama adımları).

Veritabanı türü ve değişim hızı

Sadece uygulamanın büyüklüğünü değil, “verinin değişim hızını” da düşünün. - E-ticaret: sipariş/stock değişimi sık → daha agresif log yedekleme gerekir. - Blog/İçerik sistemi: gün içi yazma seyrek → tam yedek aralığı daha uzun seçilebilir. - Analitik/raporlama: ağır sorgular var ama veri güncellemesi sınırlı olabilir → yedek stratejisi farklılaşır.

“Tam yedek + log/inkremental” mantığı

Tek tip yedek çoğu zaman pratik değildir. En sağlıklı yaklaşım genellikle şu üç katmanı birleştirir:

1. Tam yedek (full backup): Veri dosyalarının komple kopyası.
2. Diferansiyel veya inkremental (incremental/differential): Tam yedekten sonraki farklar.
3. Log yedekleri: İşlemleri sırayla tekrar oynatabilmeniz için yapılan değişiklik kayıtları.

PostgreSQL: W-A-L odaklı plan

PostgreSQL’de mantık genellikle WAL (Write-Ahead Log) etrafında şekillenir.

• Tam baz (ör. günlük): Büyük ama daha az sıklıkla.
• WAL archiving veya streaming (sık): En son noktaya yakın geri dönüş sağlar.

MySQL/MariaDB: binlog odaklı plan

MySQL/MariaDB tarafında genellikle binlog kullanılır.

• Tam baz (günlük/haftalık): Büyük kopya.
• binlog (çok sık): Belirli bir zaman noktasına (point-in-time) geri dönmeye imkan verir.

Sıklık nasıl belirlenir? Net örnek takvimler

Aşağıdaki tablolar “tek doğru” değildir; ama RPO hedefinizi gerçekçi şekilde kurmanıza yardım eder.

Not: Aşağıdaki örnekler, veri boyutu ve restore testleri hesaba katılmadan rastgele yazılmamıştır; RPO/RTO eşleşmesi üzerinden kurgulanmıştır.

Pratik kural seti

RPO hedefinizi netlediğiniz anda şu kuralları uygulayın:

• RPO 15 dk ise: Log/binary yedekleri 15 dk’dan sık olmalıdır. Full yedek günlük olsa bile kritik olan log sürekliliğidir.
• RPO 1 saat ise: Full + inkremental mantığı çalışır; ancak log kesintisi (replication stop, archive başarısızlığı) RPO’yu bozar.
• RTO 1-2 saati geçemiyorsa: Yedek geri yükleme (restore) işleminizin gerçek süresini hesaplayın. Yedek boyutu büyükse tam yedek aralığını uzatmak RTO’yu artırabilir.

Saklama süreleri: 3 katman yaklaşımı

Saklama süresinde temel hata şudur: “Disk yetiyor, hepsini tutayım.” Bu yaklaşım gereksiz maliyet ve risk üretir. Bunun yerine üç katman mantığı net bir çerçeve sunar:

1. Kısa vadeli (operasyon): En son geri dönüş için.
2. Orta vadeli (problem çözme): Hatayı tespit ettikten sonra geri almak için.
3. Uzun vadeli (uyum/kanıt): Denetim ve hukuki gerekçeler için.

Saklama öneri örnekleri

Aşağıdaki planlar tipiktir; uyum gereksinimleriniz varsa kurum/ mevzuat tarafına göre kesinleştirin.

Saklama süresini belirlerken dikkat edilmesi gereken 5 faktör

Sıklık kadar saklama süresi de “doğru” olmalıdır. Aşağıdaki 5 madde doğrudan karar etkiler.

1. Geri dönüş senaryosu - Hatalı kayıt, yanlış güncelleme, migration bug’ı: Genellikle “ilk tespit” gecikir. Bu gecikmeyi göz önüne alın.

2. Log sürekliliği - Log arşivi kesilirse, saklama süreniz dolu görünse bile point-in-time geri dönüş yapılamaz.

3. Restore testleri - Yedek var ama geri yüklenemiyorsa saklama süresinin anlamı azalır. Her planın bir “geri yükleme testi” bileşeni olmalıdır.

4. Depolama maliyeti ve bant genişliği - Uzun süre log saklamak, özellikle küçük uygulamalarda “ucuz gibi görünen” maliyeti büyütebilir.

5. Ransomware / veri bozulması etkisi - Aynı yanlış komutla veya şifreleme ile bozulma birkaç gün içinde yayılabilir. Bu durumda “en son yedekler” kirlenebilir. Katman-3’te ayrışmış saklama (farklı erişim modeli, ayrı hesap/anahtar) risk azaltır.

Saklama tasarımında sık yapılan hatalar

1) Snapshot’ı tek strateji yapmak

“Server snapshot aldım, tamam” yaklaşımı çoğu zaman yetersizdir. Snapshot: - Uygulama seviyesinde tutarlılık (consistency) sağlamayabilir. - Log tabanlı geri dönüş yerine “o an” geri dönüşe zorlayabilir.

Snapshot yedekleme, yedek (backup) stratejisinin tamamı yerine tamamlayıcı bir parça olarak ele alınmalıdır.

2) Aynı yerde saklayıp aynı anahtarla erişmek

Hem yedek hem üretim aynı sunucuda, aynı kullanıcı/anahtar ileyse saldırı sonrası aynı anda etkilenir. Saklama katmanlarını erişim ve izolasyon düzeyiyle ayırın.

3) Yedek bitti ama doğrulama yok

“Dosya oluştu” = “restore edilebilir” değildir. Doğrulama şunları kapsamalıdır: - Yedek dosyası bütünlüğü (checksum/verification) - Geri yükleme (restore) sırasında hata olup olmadığı - Uygulamanın bağlanıp temel kontrolleri geçip geçmediği

Net bir kurulum akışı (kontrol listesi)

Aşağıdaki adımlar, yedek sıklığı ve saklama süresini “kağıt üzerinde” değil sahada doğru hale getirir.

1) Hedefleri yazın

• RPO: ___ dakika/___ saat
• RTO: ___ dakika/saat
• Uygulama türü: CMS / e-ticaret / ERP / analitik

2) Yedek tiplerini eşleştirin

• Tam yedek: boyut ve restore süresiyle uyumlu aralık
• Log/binlog/WAL: RPO ile uyumlu sıklık
• İnkremantal: maliyet + restore dengesi

3) Saklama takvimini katmanlayın

• 7-14 gün: operasyon
• 30-90 gün: arıza sonrası analiz
• 180 gün-3 yıl: uyum/kanıt (gereksinime göre)

4) Restore testini otomatikleştirin

En azından ayda bir “restore test” yapın. Tam restore değil, uygulama doğrulamasını hızlandırmak için kontrollü bir ortam kullanabilirsiniz.

5) Alarm/izleme kurun

Yedek dosyası üretimi kadar önemli olan şey şudur: - Log archiving/binlog stream durdu mu? - Tam yedek job’u başarısız oldu mu? - Saklama temizliği (retention) beklenenden fazla mı silmiş?

Hosting ve sunucu tarafı kararlar: yedekleme kurgusu nasıl etkilenir?

Veritabanı yedekleme stratejisi, kullandığınız altyapıdan etkilenir.

• VPS/VDS üzerinde: Yedekleme job’larını (cron veya systemd timer) kendiniz yönetirsiniz. Disk IO performansı restore süresini etkiler.
• Paylaşımlı hosting: Kontrol paneli (control panel) üzerinden yedek seçenekleri olabilir; ancak veri tabanı seviyesinde log tabanlı plan çoğu zaman sınırlıdır. Bu durumda yedek sıklığı ile restore kabiliyeti arasında net fark oluşur.
• Dedicated sunucu: Daha yüksek kontrol ve daha iyi IO performansı genellikle restore testlerini kolaylaştırır.

Bu yüzden “yedekleme frekansı”nı planlarken sadece veritabanı ayarları değil, depolama hızı (IOPS/latency) ve network çıkışı da hesaplanmalıdır.

Sonuç: Aksiyon planı

Bugün uygulayabileceğiniz en net adım şudur: Önce RPO ve RTO hedefinizi tek satırda yazın, ardından tam yedek aralığını restore sürenize göre seçin ve asıl kritikliği log (WAL/binlog) saklama sıklığına verin. Saklama için de üç katman yaklaşımını kullanarak “7-14 gün operasyon, 30-90 gün iyileştirme, 180 gün-3 yıl uyum” çerçevesini belirleyin. Son olarak, her planın mutlaka ayda en az bir kez restore testi ile doğrulanması gerekir; aksi halde sıklık ve süreler, arıza anında değerini kaybeder.