Kaynak:
docs/DR-RUNBOOK.md— bu sayfa her build'de otomatik senkronize edilir.
DR Runbook — Felaket Kurtarma ve Yüksek Erişilebilirlik
Genel Bakış
| Bileşen | Durum | Kurtarma yöntemi |
|---|---|---|
| Hub (ingest/API) | Stateless, N replika | Yeni pod/binary başlat; veri kaybı yok |
| PostgreSQL/TimescaleDB | Stateful | pg-backup.sh yedeğinden pg-restore.sh |
| NATS JetStream | Kuyruk (MaxAge 24s) | Yeniden başlatma yeterli; kuyruktaki kayıplar agent offline kuyruğundan telafi olur |
| Agent'lar | Uçta stateful (state.json + disk kuyruğu) | Otomatik: çoklu-hub failover + offline kuyruk |
| vault.key | Cihaz SNMP secret'lar ının şifre anahtarı | Yedekten geri koy — kaybedilirse secret'lar yeniden girilir |
1) Agent çoklu-hub failover
Agent, hub adreslerini sırayla dener ve sağlıklıya yapışır:
# bazntms-agent.yml
hub:
urls:
- https://hub-a.kurum.local
- https://hub-b.kurum.local
veya -hub-url "https://hub-a,https://hub-b". Bir hub düşerse agent diğerine
devam eder; bağlantı yokken topladığı batch'ler offline disk kuyruğunda
(state.json.queue.jsonl, 100 batch'a kadar) bekler.
2) PostgreSQL yedekleme
# günlük yedek (cron): custom format + schema dump, 14 gün saklama
deploy/scripts/pg-backup.sh "postgres://bazntms:***@db:5432/bazntms?sslmode=disable" /var/backups/bazntms
# geri yükleme (ezici işlem — önce durdurun):
systemctl stop bazntms-hub # veya kubectl scale deploy bazntms --replicas=0
deploy/scripts/pg-restore.sh /var/backups/bazntms/bazntms-YYYYMMDD-HHMMSS.dump "postgres://..."
# hub yeniden başlat → /readyz "ready" dönmeli
TimescaleDB notları:
- Açılışta hypertable/cagg/retention politikaları
if_not_existsile yeniden kurulur; restore sonrası özel işlem gerekmez. - Continuous aggregate'lar
WITH NO DATAile restore olabilir; ilk policy penceresi (5 dk) dolduğunda otomatik dolar.
3) vault.key (kimlik kasası)
vault.key, cihaz SNMP community/v3 secret'larını AES-GCM ile şifreler.
Bu dosyanın yedeği olmadan geri yükleme, secret'ların yeniden girilmesini
gerektirir. Yedekleme:
cp vault.key /secure/offline/location/ # ve şifreli ikinci kopya (ör. passmanager)
chmod 600 vault.key
4) Hub failover senaryosu
- Bir ingest replikası ölür → LB sağlıksız pod'u çıkarır (k8s: readiness
probe
/readyzotomatik yönetir). - Aktif uyarı/poller rolü tek replikada tutulur (
-alerts/-pollerbayrakları). Yönetim replikası ölürse: rodları boş bir replikaya taşı. - Tüm replikalar ölürse: agent'lar offline kuyruğa yazar; hub geri geldiğinde kuyruklar boşalır (≤100 batch × batch aralığı kayıp toleransı).
5) Denetim zinciri bütünlüğü (DR sonrası kontrol)
curl -H "Authorization: Bearer $TOKEN" https://hub/api/v1/audit/verify
# {"ok":true,"broken_at":0,"checked":N} → zincir sağlam
ok:false + broken_at:X → X ID'li kayıttan itibaren veri tabanı
değiştirilmiş demektir; en son sağlam yedeği araştırın.
6) Kaos testi ile doğrulanmış davranış (Faz 21 S21.14)
scripts/chaos.sh ölçek yığınına 4 arıza enjekte eder; her koşuda hafif bir
agent yükü altında veri kaybı = 0 ve aşağıdaki kurtarma ölçütleri geçer:
| Senaryo | Beklenen davranış | Ölçülen (Docker Desktop ölçek yığını) |
|---|---|---|
Poll/uyarı lideri replikası kill | Hayatta kalan replika rolü advisory-lock tick'inde (≤10 sn) devralır | ~7 sn |
TimescaleDB restart | pgxpool reconnect; ingest yazımları NATS'te birikip DB dönünce boşalır; /readyz 200'e döner | < 60 sn |
NATS stop 60 sn | Ingest 503 döndürür; agent'lar offline disk kuyruğuna yazar; NATS dönünce replay eder; panel (/healthz) etkilenmez | tam replay, kayıp yok |
| Ingest replika 2→3→2 | nginx dinamik upstream yeni replikayı alır/çıkarır; kesinti yok | — |
Kesinti > agent offline kuyruk kapasitesi (100 batch × batch aralığı, vars.
~50 dk) ise en eski batch'ler kalıcı kaybolur ve agent logunda görünür
(offline kuyruk dolu — en eski batch'ler atildi).