Önce şu iki soruya cevap verin: ne kadar veri, ne kadar süre?
RPO ne kadar veri kaybını kabul edebileceğinizi, RTO ise servisi ne kadar sürede ayağa kaldırmanız gerektiğini ifade eder. Bunlar kuru kısaltmalar gibi görünür ama aslında işin kalbidir: “En kötü anda neyi kaybetmeyi göze alıyoruz, ne kadar bekleyebiliriz?”
PostgreSQL ve MySQL gibi OLTP sistemlerde PITR çoğu zaman kritiktir. ClickHouse gibi analitik sistemlerde snapshot ve tekrar ingest stratejisi daha uygun olabilir. Redis önbellek için ise veri kaybı toleransı işlevine göre değişir.
- OLTP: düşük RPO, PITR ve düzenli geri yükleme testi gerekir.
- Analitik: snapshot, veri yeniden işleme ve TTL stratejisi birlikte düşünülür.
- Önbellek: kalıcı veri tutulmuyorsa yedek yerine yeniden ısıtma planı önemlidir.
- Doküman verisi: replica set tek başına yedek değildir; silinen veri replikalara da gider.
Motor bazında doğru kurtarma modelini seçin
Aynı yedek politikası tüm motorlara uygulanırsa ya gereksiz maliyet doğar ya da gerçek kurtarma ihtiyacı karşılanmaz. PostgreSQL’de WAL tabanlı PITR kritik olabilirken, ClickHouse tarafında belirli snapshot ve yeniden ingest stratejisi daha gerçekçi olabilir.
MongoDB’de replica set yüksek erişilebilirlik sağlar ama kullanıcı yanlışlıkla veri sildiğinde silme işlemi replikalara da yayılır. Bu nedenle replikasyon, yedek yerine geçmez. Redis önbellek olarak kullanılıyorsa geri yükleme değil önbellek yeniden ısıtma planı önem kazanır.
- PostgreSQL: WAL arşivi, PITR penceresi, düzenli geri yükleme testi.
- MySQL: binary log temelli PITR ve migration öncesi geri dönüş planı.
- MongoDB: replica set artı yedek/geri yükleme; silme hatalarına karşı ayrı kurtarma.
- Redis: önbellek ise yeniden ısıtma; oturum/kuyruk ise iş kuralına uygun kalıcılık ve TTL.
- ClickHouse: snapshot yedek, veri yeniden üretilebilirliği ve ingest pipeline kontrolü.
TürkDB yedek ve PITR komutları
Operasyon öncesinde mevcut pencereyi görmek, manuel yedek almak ve geri yükleme hedefini ayrı cluster olarak başlatmak güvenli çalışma alışkanlığıdır. Kaynak cluster etkilenmeden geri yükleme hedefi oluşturmak test ve doğrulama süreçlerini kolaylaştırır.
PITR destekli motorlarda geri yükleme
turkdb cluster pitr window app-pg turkdb cluster pitr restore app-pg \ --to "2026-06-14T12:15:00Z" \ --name app-pg-before-release turkdb cluster pitr history app-pg
Snapshot yedek akışı
turkdb backup create product-analytics turkdb backup list product-analytics turkdb backup restore product-analytics yedek_01JZ...
Geri yükleme testi yoksa yedek stratejisi hâlâ eksiktir
Yedekleme sisteminin gerçek kanıtı geri yükleme testidir. Çünkü yedek dosyasının var olmasıyla uygulamanın geri ayağa kalkması arasında koca bir mesafe vardır.
TürkDB’nin temel vaadi burada operasyon yükünü azaltmaktır: yedek almak, saklamak, geri yüklemek ve doğrulamak ayrı ayrı unutulabilir işler olmaktan çıkar; platformun düzenli kontrol akışına dönüşür.
Release öncesi güvenli kontrol
turkdb backup create app-pg turkdb cluster pitr window app-pg turkdb cluster maintenance rollout create app-pg \ --type db_minor_update \ --preflight \ --dry-run
Geri yükleme testinde hangi kontroller olmalı?
Geri yükleme testinin amacı yalnızca komutun başarılı dönmesi değildir. Uygulama için kritik tabloların açılması, satır sayılarının beklenen aralıkta olması, indekslerin kullanılabilir kalması ve uygulamanın geri yükleme hedefine bağlanabilmesi kontrol edilmelidir.
TürkDB’nin burada anlamlı olduğu yer, geri yükleme hedefinin kaynak clusterı bozmadan ayrı bir hedef olarak başlatılabilmesidir. Böylece test, üretim veritabanına müdahale etmeden yapılır.
- Geri yükleme hedefi ayrı cluster olarak açılıyor mu?
- Kritik tablo ve koleksiyonlar beklenen sayıda mı?
- Uygulama kullanıcısı geri yükleme hedefine bağlanabiliyor mu?
- Son yedek zamanı RPO hedefini karşılıyor mu?
- Geri yükleme süresi RTO hedefiyle uyumlu mu?