Tatbikatın amacı kahramanlık değil ölçümdür
Geri yükleme tatbikatı, ekibi sınava sokmak için değil, sistemin söz verdiği şeyi gerçekten yapıp yapmadığını görmek için yapılır. Kimse baskı altında değilken yapılan küçük bir prova, gerçek felaket gününde çok büyük bir sakinlik sağlar.
RPO “ne kadar veri kaybederiz?”, RTO “ne kadar sürede ayağa kalkarız?” sorusudur. Tatbikat bu iki soruya tahminle değil, zaman damgalı kanıtla cevap verir.
- Tatbikat üretim clusterını bozmayacak ayrı hedef üzerinde yapılmalıdır.
- Başlangıç ve bitiş zamanları net kaydedilmelidir.
- Sadece geri yükleme komutu değil, uygulama bağlanabilirliği de ölçülmelidir.
- Kritik tablolar/collectionlar için doğrulama sorguları önceden hazırlanmalıdır.
Önce senaryoyu küçük tutun
İlk tatbikatta tüm şirketi ayağa kaldırmaya gerek yok. Tek bir kritik veritabanı, tek bir geri yükleme noktası, tek bir uygulama temel doğrulama testi yeterlidir. Ama bu küçük senaryo uçtan uca olmalıdır.
Senaryo örneği basit olabilir: “14:05 noktasına geri dönmemiz gerekseydi, app-pg veritabanını ayrı geri yükleme hedefi olarak açıp ödeme akışını okuyabilir miydik?” Bu soru, hem teknik hem iş tarafını aynı masaya getirir.
Tatbikat hedefini yazıya dökme
Hedef cluster: app-pg Geri yükleme noktası: 2026-06-14T11:30:00Z Beklenen RPO: <= 15 dakika Beklenen RTO: <= 45 dakika Kritik kontroller: - orders satır sayısı beklenen aralıkta - payments son 20 kayıt okunuyor - uygulama salt okunur temel doğrulama testi çalışıyor - geri yükleme hedefinde app_readonly kullanıcısı bağlanabiliyor
Geri yükleme işlemini kanıt üretecek şekilde çalıştırın
Komutu çalıştırıp “başarılı” demek yerine, süreleri kaydedin. Geri yükleme isteği ne zaman başladı, hedef ne zaman hazır oldu, uygulama ne zaman bağlandı, doğrulama ne zaman bitti? RTO bu toplam hikâyedir.
TürkDB PITR ve geri yükleme akışı
date -u +"drill_start=%Y-%m-%dT%H:%M:%SZ" turkdb cluster pitr window app-pg turkdb cluster pitr restore app-pg \ --to "2026-06-14T11:30:00Z" \ --name app-pg-drill-20260614 turkdb cluster get app-pg-drill-20260614 turkdb connect app-pg-drill-20260614 --no-tunnel date -u +"drill_restore_ready=%Y-%m-%dT%H:%M:%SZ"
Veri doğrulama sorgularını önceden hazırlayın
Geri yükleme sonrası doğrulama, olay anında uydurulacak bir iş değildir. Hangi tablolar kritik, satır sayısı hangi aralıkta olmalı, son kayıtlar beklenen zamana kadar geliyor mu, uygulama kullanıcısı yetkili mi? Bunlar tatbikat öncesinde yazılmalıdır.
PostgreSQL örnek doğrulama sorguları
SELECT count(*) FROM orders; SELECT count(*) FROM customers; SELECT id, status, updated_at FROM orders ORDER BY updated_at DESC LIMIT 20; SELECT current_user, now();
Tatbikat sonucunu okunur bir karara bağlayın
Tatbikat sonunda “başarılı” veya “başarısız” demek yetmez. RPO hedefi tuttu mu, RTO hedefi tuttu mu, hangi adım elle yapıldı, hangi bilgi eksikti, bir sonraki tatbikatta ne otomatikleşecek? Bu not, asıl iyileştirme alanıdır.
TürkDB tarafında teknik operasyon sadeleşse bile, iş hedefini siz belirlersiniz. Bazı sistemler için 45 dakika yeterlidir; bazıları için 5 dakika bile fazla olabilir. Tatbikat bu farkı görünür yapar.
Tatbikat kapanış notu
Sonuç: Kısmi başarılı RPO hedefi: <= 15 dk, gerçekleşen: 8 dk RTO hedefi: <= 45 dk, gerçekleşen: 52 dk Gecikme nedeni: Uygulama salt okunur DSN manuel hazırlandı İyileştirme: Geri yükleme hedef için hazır smoke-test env şablonu eklenecek Sonraki tatbikat: 2026-07-14