Reliability / Recovery Readiness
10 dk / 10 min
2026-10-14
Backup Başarısından Kurtarma Hazırlığına: Restore Tatbikatı
#reliability#recovery-readiness#postgresql-restore-drill#rto#rpo#postmortem#runbook#olgunluk-modeli
Yazdırılabilir Ekip Dokümanı (dataopsphere.com)
Hızlı Özdeğerlendirme, RACI matrisi ve tatbikat öncesi/sırası/sonrası kontrol listelerini PDF olarak indirin.
Özet: Çoğu ekip backup'ı ölçer ("job başarılı mı?"), kurtarmayı ölçmez ("ne kadar sürede, ne kadar veri kaybıyla geri dönebiliyoruz?"). Kurtarma hazırlığı, bu ikinci soruya son 90 gün içinde ölçülmüş bir cevabınızın olmasıdır. Bu sayfa, restore tatbikatını tek seferlik bir teknik iş olmaktan çıkarıp ekibin düzenli pratiğine dönüştürmek için gereken her şeyi içerir: olgunluk değerlendirmesi, roller, kontrol listeleri, rapor şablonu ve metrikler.
1. "Backup başarılı" neden yetmez?
Yeşil bir backup job'u yalnızca bir dosyanın yazıldığını söyler. Gerçek bir olayda kurtarmayı engelleyen sorunların çoğu ise backup dosyasının dışındadır:
- Restore edilecek ortamın nasıl hazırlanacağı belgelenmemiştir.
- Backup deposuna erişim yetkisi olan tek kişi o gün izindedir.
- Roller, eklentiler veya konfigürasyon dosyaları yedeklenmemiştir.
- WAL arşivinde haftalardır fark edilmemiş bir boşluk vardır.
- Restore süresi hiç ölçülmemiştir; iş birimine verilen RTO taahhüdü bir tahmindir.
Bu sorunların hiçbiri backup dashboard'unda görünmez. Yalnızca bir tatbikat ortaya çıkarır.
2. Olgunluk değerlendirmesi: ekibiniz nerede?
Her sistem için bulunduğunuz seviyeyi işaretleyin. Bir seviyeye geçmek için o seviyedeki tüm koşulların sağlanması gerekir.
| Seviye | Ad | Koşullar |
|---|---|---|
| 0 | Backup var | Backup alınıyor. Hiç restore edilmedi |
| 1 | Bir kez kanıtlandı | En az bir başarılı restore tatbikatı yapıldı ve kayda geçti |
| 2 | Tekrarlanabilir | Yazılı bir runbook var. Runbook'u yazan kişi dışında biri tatbikatı başarıyla yürüttü |
| 3 | Ölçülüyor | Tatbikatlar takvimli yapılıyor. RTO ve RPO her tatbikatta ölçülüyor ve hedeflerle karşılaştırılıyor. Bulgular takip edilen aksiyonlara dönüşüyor |
| 4 | Sürekli doğrulanıyor | Restore doğrulaması otomatik ve düzenli çalışıyor. Başarısız doğrulama alarm üretiyor. İnsan tatbikatı senaryo bazlı (ör. bölge kaybı, yanlış silme) yapılıyor |
Mimari Topoloji & Akış Şeması
Mermaid şeması çiziliyor...
Pratik hedef: Kritik sistemler için ilk 90 günde Seviye 2'ye, ilk yılda Seviye 3'e ulaşmak gerçekçi bir hedeftir.
Hızlı öz değerlendirme
Her "evet" 1 puan:
- [ ] Son 90 gün içinde üretim backup'ından başarılı bir restore yapıldı
- [ ] Restore runbook'u yazılı ve ekipçe erişilebilir
- [ ] Runbook'u yazan kişi dışında biri tatbikatı yürüttü
- [ ] Her kritik sistem için yazılı bir RTO ve RPO hedefi var
- [ ] Son tatbikatta RTO ve RPO ölçüldü
- [ ] Ölçülen değerler hedeflerle karşılaştırıldı ve paylaşıldı
- [ ] Tatbikat bulguları sorumlu ve tarih atanmış aksiyonlara dönüştü
- [ ] Bir sonraki tatbikatın tarihi takvimde
- [ ] Global nesneler, konfigürasyon ve gizli anahtarların kurtarılması da tatbikata dahil
- [ ] Backup deposu üretim hesabından bağımsız bir yerde (farklı hesap/bölge/sağlayıcı) kopyalanıyor
0–3: Seviye 0–1. İlk tatbikatı bu ay planlayın. 4–7: Seviye 2 civarı. Takvim ve ölçüm disiplini kurun. 8–10: Seviye 3. Otomasyon ve senaryo çeşitliliğine odaklanın.
3. Roller
Tatbikatı tek kişi yürütmemelidir. Asgari ekip iki kişidir, kritik sistemlerde dört rol önerilir.
| Rol | Sorumluluk | Not |
|---|---|---|
| Tatbikat sahibi | Kapsamı ve başarı kriterlerini belirler, sonucu onaylar | Genellikle ekip lideri veya servis sahibi |
| Yürüten | Runbook'u adım adım uygular | Mümkünse runbook'u yazmamış biri |
| Gözlemci / kayıtçı | Zaman damgalarını, sapmaları ve takılmaları kaydeder | RTO ölçümünün güvenilirliği bu role bağlıdır |
| Uygulama temsilcisi | Restore edilen verinin uygulama açısından doğru olduğunu teyit eder | "Veritabanı açıldı" ile "uygulama çalışır" arasındaki farkı kapatır |
RACI
| Faaliyet | Tatbikat sahibi | Yürüten | Gözlemci | Uygulama temsilcisi |
|---|---|---|---|---|
| Kapsam ve başarı kriterleri | A | C | C | C |
| Ortam hazırlığı | I | R | I | – |
| Restore ve doğrulama | I | R | C | C |
| Uygulama doğrulaması | I | C | I | R |
| Zaman ve bulgu kaydı | I | C | R | C |
| Rapor ve aksiyonlar | A | C | R | C |
*R: yapan · A: hesap veren · C: danışılan · I: bilgilendirilen*
4. Kontrol listeleri
4.1 Tatbikat öncesi (1 hafta önce)
- [ ] Kapsam yazıldı: hangi sistem, hangi backup, hangi senaryo (ör. "dün 14:29 durumuna dön")
- [ ] RTO ve RPO hedefleri yazıldı
- [ ] Başarı kriterleri yazıldı (instance açılması yetmez; veri ve uygulama kontrolleri tanımlı)
- [ ] Roller atandı, takvimde zaman ayrıldı
- [ ] İzole tatbikat ortamı belirlendi (üretim ağı, üretim WAL arşivi ve dış sistemlere yazma kapalı)
- [ ] Tatbikat ortamının erişim kontrolü üretimle aynı seviyede (restore edilen veri gerçek kişisel veri içerir)
- [ ] Karşılaştırma için referans değerler (nesne sayıları, kritik tablo sayımları) alındı
- [ ] Runbook'un güncel sürümü paylaşıldı
- [ ] İlgili ekiplere (güvenlik, altyapı) bilgi verildi
4.2 Tatbikat sırasında
- [ ] Başlangıç zamanı kaydedildi (RTO saati burada başlar)
- [ ] Her adımın başlangıç ve bitiş zamanı kaydedildi
- [ ] Runbook'tan her sapma not edildi (eksik adım, yanlış komut, belgesiz bilgi)
- [ ] Erişim, yetki veya araç kaynaklı her bekleme süresi ayrıca not edildi
- [ ] Veri doğrulama kontrolleri referansla karşılaştırıldı
- [ ] Uygulama temsilcisi kritik senaryoyu doğruladı
- [ ] Bitiş zamanı kaydedildi (RTO saati burada durur)
- [ ] Restore edilen verideki son işlem zamanı kaydedildi (ölçülen RPO için)
Kural: Tatbikat sırasında runbook "sessizce" düzeltilmez. Her sapma kayda geçer ve tatbikattan sonra runbook'a işlenir. Aksi halde bir sonraki kişi aynı yerde takılır.
4.3 Tatbikat sonrası (48 saat içinde)
- [ ] Tatbikat ortamı ve içindeki veri silindi, silme kayda geçti
- [ ] Tatbikat raporu dolduruldu (Bölüm 5)
- [ ] Her bulgu sorumlu ve tarih atanmış bir aksiyona dönüştü
- [ ] Runbook güncellendi
- [ ] Ölçülen RTO ve RPO, servis sahibine ve iş birimine paylaşıldı
- [ ] Hedefler tutmadıysa: ya teknik aksiyon planlandı ya da hedef iş birimiyle yeniden konuşuldu
- [ ] Bir sonraki tatbikatın tarihi takvime eklendi
5. Tatbikat raporu şablonu
Aşağıdaki şablonu ekip wiki'nize veya doküman aracınıza kopyalayın.
markdown
# Restore Tatbikatı Raporu
## Özet
- Sistem:
- Tarih:
- Senaryo:
- Sonuç: Başarılı / Kısmen başarılı / Başarısız
- Tek cümlelik sonuç: (ör. "Dün 14:29 durumuna 2 sa 47 dk'da döndük; hedef 2 saatti.")
## Ekip
- Tatbikat sahibi:
- Yürüten:
- Gözlemci:
- Uygulama temsilcisi:
## Hedef ve ölçüm
| Metrik | Hedef | Ölçülen | Durum |
|---|---|---|---|
| RTO | | | |
| RPO | | | |
## Zaman çizelgesi
| Saat | Adım | Süre | Not |
|---|---|---|---|
| | Ortam hazırlığı | | |
| | Backup'a erişim | | |
| | Restore | | |
| | Veri doğrulama | | |
| | Uygulama doğrulaması | | |
## Süre dağılımı
- Teknik işlem (restore, replay):
- Bekleme (erişim, onay, bilgi arama):
## Bulgular
| # | Bulgu | Etki | Aksiyon | Sorumlu | Tarih |
|---|---|---|---|---|---|
| 1 | | | | | |
## Runbook değişiklikleri
-
## Bir sonraki tatbikat
- Tarih:
- Senaryo değişikliği:"Süre dağılımı" bölümünü atlamayın. İlk tatbikatlarda RTO'nun büyük kısmı genellikle teknik işlemden değil, beklemeden oluşur: erişim izni, doğru kişiye ulaşma, belgesiz bilgiyi arama. Bu ayrım, hangi yatırımın RTO'yu gerçekten düşüreceğini gösterir.
6. Senaryo kütüphanesi
Her tatbikatta aynı senaryoyu tekrarlamak yanlış bir güven duygusu yaratır. Senaryoları sırayla döndürün:
| Senaryo | Neyi test eder? | Önerilen sıklık |
|---|---|---|
| Son geceki backup'tan full restore | Temel restore akışı | İlk tatbikat |
Belirli bir zamana PITR (yanlış DELETE senaryosu) | WAL arşivi bütünlüğü, hedef zaman seçimi | Çeyreklik |
| Birkaç günlük bir backup'tan restore | Retention zinciri | Yarıyıllık |
| Asıl DBA olmadan restore | Runbook'un yeterliliği, bilginin tek kişide toplanması | Yarıyıllık |
| Farklı hesap/bölgedeki kopyadan restore | Bölge veya hesap kaybı senaryosu | Yıllık |
| Tek tablonun geri getirilmesi | Seçici kurtarma yeteneği | Yıllık |
7. Metrikler: ilerlemeyi nasıl takip edersiniz?
| Metrik | Tanım | İyi sinyal |
|---|---|---|
| Son başarılı restore'dan bu yana geçen gün | Sistem başına | Kritik sistemlerde 90 günün altında |
| Ölçülen RTO / hedef RTO | Son tatbikatta | 1'in altında ve düşen trend |
| Ölçülen RPO / hedef RPO | Son tatbikatta | 1'in altında |
| Tatbikat başarı oranı | Başarılı tatbikat / toplam tatbikat | Yükselen trend (ilk tatbikatların başarısız olması normaldir) |
| Açık tatbikat aksiyonları | Sayı ve yaşı | Azalan sayı, 30 günü geçmeyen yaş |
| Kapsama oranı | Son 90 günde tatbikatı yapılmış kritik sistem / tüm kritik sistemler | %100'e yaklaşan |
| Bekleme payı | RTO içinde bekleme süresinin payı | Düşen trend |
Bu metrikleri her çeyrekte bir sayfada toplayın. Aynı sayfa, denetimde "backup'larınız çalışıyor mu?" sorusunun kanıtlı cevabıdır.
8. İlk 90 gün planı
- 11–2. hafta: Kritik sistem listesini çıkarın. Her biri için RTO/RPO hedefini iş birimiyle yazın. Öz değerlendirmeyi yapın.
- 23–4. hafta: En kritik sistemde ilk tatbikatı yapın (Seviye 1). Teknik adımlar için: PostgreSQL Backup'ınızı Doğrulayın: İlk Restore Tatbikatı (dbaguide.com).
- 35–8. hafta: Bulguları kapatın. Runbook'u güncelleyin. Aynı tatbikatı başka bir ekip üyesi yürütsün (Seviye 2).
- 49–12. hafta: Tatbikat takvimini oluşturun, metrikleri ilk kez raporlayın. Kalan kritik sistemlere yayın.
Backup yaklaşımınızın hedeflerinize uygun olmadığını tatbikat gösterirse alternatifleri değerlendirmek için: PostgreSQL Backup Yaklaşımını Nasıl Seçmelisiniz? (dataxtools.com).
Kaynaklar
Topluluk Katkısı & Benchmark
Restore Tatbikatı & Kurtarma Deneyiminizi Paylaşın
Altyapınızdaki gerçek tatbikat sonuçlarını, RTO/RPO hedeflerinizi ve karşılaştığınız operasyonel engelleri anonim veya isimli olarak paylaşın. Sektör benchmark'ına katkıda bulunun.
İlgili Runbook ve Karar Matrisleri
dbaguide.com · Runbook
PostgreSQL Backup'ınızı Doğrulayın: İlk Restore Tatbikatı
Teknik eller-serbest tatbikat rehberi: izole sandbox hazırlama, pg_restore & PITR, amcheck doğrulama ve RTO/RPO ölçümü.
dataxtools.com · Karar Matrisi
PostgreSQL Backup Yaklaşımını Nasıl Seçmelisiniz?
pg_dump, pg_basebackup, pgBackRest, Barman ve WAL-G: veri boyutu, RPO/RTO ve depolama gereksinimlerine göre araç seçim kılavuzu.
Bu mimariyi üretimde test etmek ister misiniz?
DataOpsphere CI/CD şablonlarını ve Docker Compose ortamlarını kopyalayıp hemen çalıştırabilirsiniz.