Veritabanı yedeklemesi almak, birçok ekip için "checkbox" görevidir: cron job çalışıyor, dosya S3'e gidiyor, herkes rahat. Felaket anında ortaya çıkan gerçek sorular çok daha acımasızdır: Son yedek ne zaman alındı? Point-in-time recovery mümkün mü? Restore ne kadar sürer? Şifreleme anahtarı nerede? Backup planı yalnızca yedek almak değil; restore planı ile birlikte düzenli test edilen, belgelenmiş ve ölçülebilir bir süreçtir.
RPO ve RTO hedefleri
İş sürekliliği planının temel metrikleri:
- RPO (Recovery Point Objective): Kabul edilebilir veri kaybı süresi — son 15 dakikalık transaction'lar kaybolabilir mi?
- RTO (Recovery Time Objective): Sistemin tekrar ayakta olması için hedeflenen süre — 4 saat mi, 30 dakika mı?
RPO=0 (sıfır veri kaybı) senkron replikasyon veya sürekli log shipping gerektirir; maliyet yüksektir. RPO=24 saat günlük full backup ile mümkündür ancak felaket gününün tüm işlemleri kaybolur. Hedefler iş birimi ile birlikte belirlenmeli ve teknik tasarım buna göre yapılmalıdır.
Yedekleme türleri
Full backup
Tüm veritabanının anlık görüntüsü. PostgreSQL'te pg_basebackup, SQL Server'da BACKUP DATABASE. Temel restore noktası; tek başına büyük veritabanlarında günlük full yedek RPO'yu 24 saate indirger.
Incremental / differential
Son full yedekten bu yana değişen sayfalar. Yedek boyutu küçülür, restore karmaşıklaşır (full + son differential zinciri). SQL Server differential backup bu kategoridedir.
Transaction log / WAL backup
Sürekli log yedekleme point-in-time recovery (PITR) sağlar. PostgreSQL WAL arşivleme, SQL Server transaction log backup. RPO dakika seviyesine iner.
-- SQL Server: log backup
BACKUP LOG MyDb TO DISK = '\\backup\MyDb_log.trn' WITH COMPRESSION;PostgreSQL yedekleme stratejileri
İki ana yaklaım:
- Mantıksal yedek (pg_dump): SQL veya custom format; taşınabilir, versiyon upgrade kolay; büyük DB'de yavaş restore.
- Fiziksel yedek (pg_basebackup + WAL): Hızlı restore, PITR; aynı major versiyon gerekir.
Üretimde genellikle fiziksel yedek + WAL arşivleme birincil, pg_dump mantıksal doğrulama ve küçük ortam klonlama için ikincil kullanılır.
# postgresql.conf
archive_mode = on
archive_command = 'aws s3 cp %p s3://mybucket/wal/%f'Restore testi: en kritik adım
Test edilmemiş yedek, yedek değildir. Aylık restore tatbikatı şunları doğrular:
- Yedek dosyası bozuk değil
- Restore süresi RTO içinde
- Uygulama bağlantı string'i ve migration uyumu
- Şifreleme anahtarı erişilebilir
- Ekip runbook'u takip edebiliyor
Tatbikat izole ortamda (ayrı VPC, test sunucusu) yapılmalı; üretim veritabanının üzerine restore denenmemelidir. Restore sonrası smoke test: kritik sorgular, kayıt sayısı checksum, uygulama health check.
Otomasyon örneği
# Aylık restore test pipeline (pseudo)
1. Son full backup'ı test sunucusuna indir
2. WAL zincirini uygula (hedef PITR timestamp)
3. SELECT COUNT(*) FROM critical_tables
4. Uygulama integration test suite
5. Sonucu Slack + ticket sistemine yazYedek güvenliği
Yedekler saldırganın birincil hedefidir — ransomware tüm sistemi şifrelerken yedekleri de hedef alır. Önlemler:
- Yedekleri üretimden ayrı hesap/region'da saklamak (immutable storage, S3 Object Lock)
- Yedek şifreleme (AES-256, KMS ile anahtar yönetimi)
- Erişim: yedek yazma yetkisi restore yetkisinden ayrı
- Air-gapped veya offline kopya (aylık tape veya cross-account)
Cross-region ve felaket kurtarma
Tek bölge (region) felaketi tüm primary ve local yedekleri etkileyebilir. Cross-region replication veya yedek kopyalama zorunludur. RTO için warm standby (replica hazır, DNS failover) veya cold standby (yedekten restore gerekir) seçilir. Warm standby maliyeti yüksek, RTO düşük; cold standby tersidir.
Retention politikası
Saklama süreleri katmanlı olmalıdır:
- Günlük yedek: 7-14 gün
- Haftalık yedek: 4-8 hafta
- Aylık yedek: 12 ay (yasal gereksinim varsa daha uzun)
- WAL/log: RPO hedefine göre (genellikle 7-30 gün)
GDPR ve sektörel regülasyonlar belirli verilerin saklama üst sınırı da koyabilir; yedek retention ile çelişmemeli, purge süreci tanımlanmalıdır.
Managed service vs self-hosted
AWS RDS, Azure Database, Google Cloud SQL otomatik yedek ve PITR sunar. Sorumluluk paylaşım modelinde provider altyapıyı, müşteri retention ve restore testini yönetir. Self-hosted PostgreSQL/SQL Server'da tüm pipeline ekip sorumluluğundadır. Managed service seçilse bile restore tatbikatı müşteri tarafında yapılmalıdır.
Runbook ve iletişim
Felaket anında panik yerine runbook devreye girer. Runbook içeriği: iletişim zinciri, yetkili kişiler, restore adımları (komut satırı), doğrulama checklist, geri dönüş (failback) prosedürü. Post-incident review her tatbikat veya gerçek olay sonrası güncellenir.
Özet
Backup ve restore planı, RPO/RTO hedefleriyle başlar; full, differential ve log yedekleme katmanlarıyla desteklenir. Yedek güvenliği, cross-region kopya ve düzenli restore testi olmadan plan eksiktir. Managed veya self-hosted fark etmeksizin, restore süresini ölçmek ve belgelemek operasyonel olgunluğun temel göstergesidir.
Operasyonel perspektif
Backup ve restore plani konusunda üretim ortamında karşılaşılan senaryolar, geliştirme ortamından farklıdır. Trafik hacmi, eşzamanlı bağlantı sayısı, disk I/O ve replikasyon gecikmesi gibi faktörler tasarım kararlarını doğrudan etkiler. Metrik toplama ve düzenli kapasite gözden geçirmesi, sorunları kullanıcı şikâyetine dönüşmeden yakalamayı sağlar.
Kapasite planlama
Veritabanı katmanında CPU, bellek, disk throughput ve connection pool kullanımı birlikte izlenmelidir. Ani trafik artışlarında autoscaling uygulama katmanında mümkün olsa da veritabanı ölçeklendirmesi genellikle planlı yapılır. Read replica eklemek, connection pool boyutunu artırmak veya sorgu optimizasyonu yapmak gibi seçenekler yük testi sonuçlarına göre sıralanmalıdır.
Güvenlik ve erişim kontrolü
Veritabanı kullanıcıları en az ayrıcalık ilkesine göre tanımlanmalıdır. Uygulama hesabı yalnızca gerekli DML yetkilerine sahip olmalı; DDL ve yönetim işlemleri ayrı role ayrılmalıdır. Bağlantı string'leri secret manager'da tutulmalı, rotation politikası uygulanmalıdır. Audit log erişimi yalnızca denetim ve operasyon rollerine açık olmalıdır.
Ekip disiplini ve dokümantasyon
Mimari kararlar Architecture Decision Record (ADR) ile belgelenmelidir. Onboarding dokümanında bu konuya özel bölüm yer almalı; yeni geliştiriciler global filter, routing kuralı veya yedekleme penceresi gibi kritik detayları atlamamalıdır. Code review checklist'ine ilgili maddeler eklenmesi regresyon riskini azaltır.
Kalite kapıları
- Pull request'te ilgili entegrasyon testlerinin çalışması
- Staging ortamında gerçekçi veri hacmi ile smoke test
- Performans regression eşiği (p95 latency, sorgu sayısı)
- Migration rollback planının PR açıklamasında belirtilmesi
Bu disiplinler tek başına mucize yaratmaz; ancak veritabanı katmanındaki hataların maliyeti yüksek olduğundan, erken yakalama yatırımı uzun vadede ödenir. Post-incident review'larda kök neden analizi veritabanı tasarımına geri beslenmelidir.
Operasyonel perspektif
Backup ve restore plani konusunda üretim ortamında karşılaşılan senaryolar, geliştirme ortamından farklıdır. Trafik hacmi, eşzamanlı bağlantı sayısı, disk I/O ve replikasyon gecikmesi gibi faktörler tasarım kararlarını doğrudan etkiler. Metrik toplama ve düzenli kapasite gözden geçirmesi, sorunları kullanıcı şikâyetine dönüşmeden yakalamayı sağlar.
Kapasite planlama
Veritabanı katmanında CPU, bellek, disk throughput ve connection pool kullanımı birlikte izlenmelidir. Ani trafik artışlarında autoscaling uygulama katmanında mümkün olsa da veritabanı ölçeklendirmesi genellikle planlı yapılır. Read replica eklemek, connection pool boyutunu artırmak veya sorgu optimizasyonu yapmak gibi seçenekler yük testi sonuçlarına göre sıralanmalıdır.
Güvenlik ve erişim kontrolü
Veritabanı kullanıcıları en az ayrıcalık ilkesine göre tanımlanmalıdır. Uygulama hesabı yalnızca gerekli DML yetkilerine sahip olmalı; DDL ve yönetim işlemleri ayrı role ayrılmalıdır. Bağlantı string'leri secret manager'da tutulmalı, rotation politikası uygulanmalıdır. Audit log erişimi yalnızca denetim ve operasyon rollerine açık olmalıdır.
Ekip disiplini ve dokümantasyon
Mimari kararlar Architecture Decision Record (ADR) ile belgelenmelidir. Onboarding dokümanında bu konuya özel bölüm yer almalı; yeni geliştiriciler global filter, routing kuralı veya yedekleme penceresi gibi kritik detayları atlamamalıdır. Code review checklist'ine ilgili maddeler eklenmesi regresyon riskini azaltır.
Kalite kapıları
- Pull request'te ilgili entegrasyon testlerinin çalışması
- Staging ortamında gerçekçi veri hacmi ile smoke test
- Performans regression eşiği (p95 latency, sorgu sayısı)
- Migration rollback planının PR açıklamasında belirtilmesi
Bu disiplinler tek başına mucize yaratmaz; ancak veritabanı katmanındaki hataların maliyeti yüksek olduğundan, erken yakalama yatırımı uzun vadede ödenir. Post-incident review'larda kök neden analizi veritabanı tasarımına geri beslenmelidir.
