Veritabanı Yedekleme: Doğru Sıklık ve Saklama Süreleri

Veritabanı yedekleme planı, hosting veya VDS sunucunuzun güvenilirliğini doğrudan etkiler. Ancak pek çok ekip “yedek alıyoruz” deyip tek bir frekansa takılır; felaket senaryosunda hangi yedekten hangi noktaya dönebileceği belirsiz kalır. Bu rehberde veritabanı için sıklık ve saklama süresi yaklaşımını somut bir çerçeveyle ele alacaksınız: RPO/RTO tanımı, tam/arımlı mantığı, yedek saklama katmanları ve düzenli restore doğrulama.

Yedekleme sıklığı nasıl belirlenir? (RPO/RTO ile)

Önce ölçüleri netleştirin:

RPO (Recovery Point Objective)

RPO, arıza anında kaybetmek istemediğiniz maksimum veri miktarını ifade eder. Örnek: “Son 15 dakikadaki veriler bozulursa kabul” diyorsanız RPO 15 dk’dır.

RTO (Recovery Time Objective)

RTO, sistemi ne kadar sürede ayağa kaldırmak istediğinizi belirtir. Örnek: “Yedekten ayağa dönüş 1 saati geçmesin” diyorsanız RTO 1 saattir.

Bu iki değer, yedekleme sıklığını belirlemede ana girdidir. Yedek sıklığı RPO’yu, yedekten geri dönüş kabiliyeti ise RTO’yu doğrudan etkiler.

Pratik kural

• Daha sık yedek → RPO düşer (daha az veri kaybı), ancak depolama ve işlem maliyeti artar.
• Daha uzun saklama → tarihsel geri dönüş kolaylaşır, ancak maliyet ve yönetim yükü artar.

Tam yedek + arımsal yedek modeli (tamamlayıcı ikili)

Veritabanlarında iki yaklaşım bir arada kullanılır: - Tam yedek (full backup): tüm veri seti - Arımsal/inkremental yedek (incremental): son yedekten itibaren değişenler

Bu kombinasyon, hem hızlı geri dönüş hem de maliyet kontrolü sağlar.

MySQL/MariaDB ve PostgreSQL için tipik mantık

• MySQL/MariaDB: Genellikle tam yedek + binary log (binlog) akışı kullanılır. Bu sayede “en son doğru zaman noktası”na dönüş mümkün olur.
• PostgreSQL: Genellikle base backup + WAL (Write-Ahead Logging) ile zaman noktası geri dönüş sağlanır.

Hedefiniz “en son ana dön” ise sadece günlük tam yedek almak RPO’yu karşılamaz. Zaman noktası geri dönüşü için log/tabanlı akış gerekir.

Tek günlük tam yedek yaklaşımı ne zaman yeter?

Şunlar olduğunda tek günlük tam yedek kabul edilebilir: - Veri güncellemeleri düşük sıklıkta - Uygulamanın kaybı telafi edilebilir - RPO gereksinimi “24 saat” gibi yüksektir

Ama e-ticaret, canlı içerik, kullanıcı kayıtları ve ödeme süreçlerinde bu yaklaşım genellikle yetersiz kalır.

Hangi sıklıkla yedek almalısınız? (senaryo bazlı net plan)

Aşağıdaki planlar “ortalama” bir altyapıyı varsayar. Asıl belirleyici RPO’dur.

RPO hedefi 1 saat ise

• Tam yedek: Günlük
• Log/arımsal yedek: Sürekli veya her 5-15 dk
• Saklama: 7-14 gün (detay saklama katmanı aşağıda)

Bu senaryoda geri dönüş, son log parçalarıyla saat bazlı net noktaya indirilebilir.

RPO hedefi 15 dk ise

• Tam yedek: Haftada 1 (ya da 3 günde 1)
• Log/arımsal yedek: 1-5 dk aralıklarla (altyapınıza göre)
• Saklama: 30 gün (en az 14 gün hızlı erişim)

Bu plan, veri kaybını 15 dk bandına çeker; ancak log arşivleme kapasitesi ve performans etkisini hesaba katmanız gerekir.

RPO hedefi 5 dk ise

• Tam yedek: Haftada 1
• Log/arımsal yedek: 1-2 dk aralıklarla
• Saklama: 30-60 gün
• Ek şart: Restore doğrulaması haftada en az 1 kez yapılmalıdır

5 dk RPO, “yedek alındı” bilgisinden fazlasını gerektirir. Log zinciri kırılırsa (ör. bazı parçalara erişim yoksa) hedef noktaya dönüş zorluk çıkarır.

Saklama süreleri: 3 katmanlı (hot-warm-cold) mantık

Saklama sürelerini tek bir rakama bağlamak yerine katmanlandırmak maliyet/geri dönüş dengesini iyileştirir.

Katman 1: Hızlı erişim (hot)

• Süre: 7-14 gün
• İçerik: Son tam + son arımsal/log parçaları
• Amaç: Güncel hatalarda hızlı kurtarma

Katman 2: Orta seviye (warm)

• Süre: 30-60 gün
• İçerik: Günlük/haftalık tam yedekler + log arşivi (tamamı mümkün değilse kısmi zaman aralığı)
• Amaç: Yanlışlıkla silme, bozuk migrasyon, bozuk indeks gibi hatalarda geriye gitmek

Katman 3: Uzun dönem (cold)

• Süre: 90-365 gün (ihtiyaca göre)
• İçerik: Haftalık/aylık tam yedekler (logların tamamı şart olmayabilir)
• Amaç: Dönemsel geri dönüş, denetim (audit) ihtiyaçları

Denetim gereksinimi varsa saklama sürenizi “teknik ihtiyaca” göre değil, resmi/kurumsal kurallara göre belirleyin.

Saklama stratejisi için net tablo

Aşağıdaki tablo, RPO/RTO uyumlu bir başlangıç seti verir. Bu değerleri kendi sisteminizin veri değişim hızına ve iş kritikliğine göre güncelleyin.

Saklama süresi belirlerken maliyeti kontrol edin

Saklama süresi uzadıkça iki maliyet kalemi büyür: 1) Depolama alanı 2) Geri dönüş sırasında okuma/süre (özellikle cold katmanda)

Pratik maliyet optimizasyonu

• Cold katmanda tam yedek aralığını artırın (ör. haftalık/aylık)
• Log yedeklerini “tamamı” yerine ihtiyaç duyulan zaman aralığında saklayın (hedef RPO’ya göre)
• Yedekleri tek bir disk yerine ayrı depolama (farklı tutucu/konum) üzerinde tutun

Yedekleme sıklığı kadar “yedek kalitesi” de ölçülür

Yedek almanın tek başına değeri yoktur; yedek bozuksa kurtarma başarısız olur.

Restore doğrulama (restore test) takvimi

• Hot katman: Her ay en az 1 restore doğrulama
• Warm/cold katman: 3 ayda 1 veya planlı denetimlerle

Bu testte şunları ölçün: - Belirli bir tarihe/saate dönüş yapabiliyor musunuz? - Uygulama ayağa kalkıyor mu? - Şema (schema) ve veri tutarlı mı?

Net hedef: “Yedekten dönüş süresi” ölçümünü RTO değerinizle aynı metriğe bağlayın.

Kullanacağınız yedek çözümü: sunucu içi mi dışarı mı?

VDS/VPS/Dedicated üzerinde genellikle iki yaklaşım görülür: - Yedeklerin aynı sunucuda tutulması - Yedeklerin farklı konumda tutulması (önerilen)

Neden ayrı konum?

Disk arızası, yanlış silme veya yetki hatasında hem veritabanı hem de yedek aynı sunucudaysa kurtarma şansı düşer.

En azından şu ayrımı yapın

• Veritabanı üretim diski ayrı
• Yedek depolama ayrı (farklı depolama birimi, farklı erişim anahtarı ve farklı lokasyon)

Özel durumlar: veri tabanı büyümesi ve şişen yedekler

Büyüyen veritabanlarında yedek süreleri uzar. Bu da log arşivleme süreçlerinin gecikmesine yol açabilir.

Gecikme belirtileri

• Yedek job’ları “takılı kalıyor”
• Log arşivleme kuyruğu büyüyor
• Restorasyon süreleri RTO’yu aşıyor

Net düzeltme adımları

• Tam yedek aralığını RPO’yu koruyarak artırın
• Arımsal/log süreçlerinin hızını kontrol edin
• İndeks/şema bakımını düzenli yapın (gereksiz büyümeyi azaltın)

Sonuç: Hemen uygulayabileceğiniz aksiyon planı

Veritabanı yedekleme sıklığı ve saklama süresi tek bir sayı değildir; RPO/RTO hedefleriniz ve veri değişim hızınızla doğrudan eşleşir. Bugün yapabileceğiniz en net aksiyonlar şunlar:

1) RPO ve RTO değerlerini yazın (ör. RPO 15 dk, RTO 1 saat). 2) Tam + arımsal/log modelini seçin ve “zaman noktası geri dönüş” hedefini netleştirin. 3) Hot/ Warm/ Cold katmanlarıyla saklama planını oluşturun (ör. 14 gün hot, 60 gün warm, 180 gün cold). 4) En az ayda 1 kez restore doğrulama yapın; hedef tarihe dönüş ve uygulama ayağa kalkma başarısını ölçün.

Bu adımları tamamladıktan sonra yedekleme planınız “alınan yedek sayısı” değil, “kurtarma başarısı” üzerinden yönetilir.