Yedekleme, Geri Yükleme ve Felaket Kurtarma

Knowentra'nın yedeği yalnız veritabanı dump'ı değildir. Kullanıcı ve yetki kayıtları, yüklenen dosyalar, vektör indeksleri, connector credential'ları, workflow execution durumları, güvenlik politikaları ve bunları açabilen şifreleme anahtarları birlikte bir sistem oluşturur.

Bu rehber üç ayrı yeteneği planlar:

• Yedekleme: Gerekli veri ve konfigürasyonu güvenli kopyalamak
• Geri yükleme: Bir kaybı tutarlı ve doğrulanabilir biçimde geri getirmek
• Felaket kurtarma: Birincil ortam kullanılamazken hizmeti hedef sürede başka yerde açmak

RPO, RTO ve MTD

Hedefleri “platform geneli” tek değerle değil veri ve iş akışı sınıfına göre belirleyin:

RPO sıfır demek yedekleme değil, senkron replikasyon ve uygulama seviyesinde tutarlılık gerektirebilir. Replika, yanlış silme veya fidye yazılımını da kopyalayabileceği için yedeğin yerine geçmez.

Korunacak varlık envanteri

1. İlişkisel veritabanları

• Kullanıcılar, organizasyon, departman ve Space üyelikleri
• Agent, model, prompt ve erişim tanımları
• Workflow metadata'sı, sürümleri ve run kayıtları
• Connector tanımı, checkpoint ve provenance
• Audit ve uygulama yapılandırması
• Workflow motorunun workspace, execution ve duraklatılmış snapshot kayıtları

Knowentra uygulaması ile workflow motoru ayrı veritabanları kullanıyorsa ikisi aynı kurtarma setinde ve tutarlılık zaman çizgisinde ele alınmalıdır.

2. Dosya ve obje depolama

• Kullanıcı yüklemeleri
• Connector ile alınan kaynak kopyaları
• Ayrıştırılmış/türetilmiş dosyalar
• Avatar ve görsel artefact'lar
• Export ve geçici iş dosyalarından yalnız kalıcı olması gerekenler

Bucket, volume veya mount listesini manifest'ten çıkarın. Container filesystem'ine yazılan kalıcı veri varsa önce desteklenen persistent storage'a taşıyın.

3. Vektör deposu

• Koleksiyon/index tanımı
• Chunk ve embedding kayıtları
• Kaynak, revision ve ACL metadata'sı
• Aktif index revision/alias bilgisi

Vektör deposu doğrudan yedeklenebilir veya kaynak dosya ve metadata'dan yeniden üretilebilir. Seçim, indeks hacmi ve RTO'ya bağlıdır.

4. Secret ve şifreleme anahtarları

• Uygulama/session imzalama secret'ları
• Credential encryption key
• OAuth client/session token encryption key'leri
• Dahili servis JWT/API secret'ları
• TLS private key veya KMS referansları
• Backup encryption key

Şifreli veritabanını geri getirip doğru ENCRYPTION_KEY veya eşdeğer anahtarı getirmemek, connector credential'larını kullanılmaz hâle getirir.

5. Konfigürasyon ve artefact'lar

• Deployment manifest'i ve values dosyaları
• Secret değerleri değil, secret referansları
• Image digest ve release manifest'i
• Migration revision
• Model ve embedding artefact checksum'ları
• LLM Secure Gateway ve guardrail politika revision'ları
• Network, DNS, ingress ve certificate konfigürasyonu

Git repository çalışma tanımlarını koruyabilir; canlı verinin, secret'ın veya yalnız yönetim ekranından değişen persistent konfigürasyonun otomatik yedeği değildir.

6. Operasyon kayıtları

• Audit kayıtları
• Incident ve değişiklik kayıtları
• Restore test raporları
• Connector reconciliation raporu
• Runbook ve iletişim/eskalasyon listesi

Monitoring backend'i kaybolsa bile kurtarma sırasında minimum health ve audit kanıtı üretebilecek bağımsız yol bulunmalıdır.

Bağımlılık haritası

Şifreleme anahtarları ─────────────┐
                                   ↓
İlişkisel DB ─→ üyelik / tanım / credential / checkpoint
      │                            │
      ├→ dosya/obje referansları ──┼→ Obje deposu
      ├→ source/chunk metadata ─────┼→ Vektör deposu
      └→ workflow binding ──────────┼→ Workflow DB / paused state
                                   ↓
                         Uygulama ve worker'lar

Restore sırası bu bağımlılıkların tersine göre planlanır; uygulamayı stateful katmanlardan önce kullanıcı trafiğine açmayın.

Yedek stratejisini seçin

Tam + artımlı/PITR

İlişkisel veritabanında periyodik tam/base backup ile transaction log/WAL arşivini birlikte kullanın. Böylece belirli bir zamana dönüş yapılabilir.

Snapshot

Disk veya volume snapshot hızlıdır; uygulama tutarlılığı garanti etmez. Veritabanının snapshot uyumlu mekanizmasını kullanın veya yazmaları kısa süreli dondurun.

Mantıksal export

Taşınabilir ve nesne bazında incelemeye uygundur; büyük ortamda yavaş olabilir ve tüm extension, role veya fiziksel ayarı taşımayabilir.

Replikasyon

Erişilebilirlik ve düşük RPO sağlar; silme, bozulma ve kötü niyetli değişiklik de replike edilebilir. Immutable, zaman serili yedek ayrıca gereklidir.

3-2-1-1-0 yaklaşımı

• Üretim verisiyle birlikte en az 3 kopya
• En az 2 farklı ortam/medya
• En az 1 kopya farklı hata bölgesinde
• En az 1 immutable veya offline kopya
• Restore doğrulamasında 0 hata

Air-gapped ortamda dış bölge yerine ayrı güvenlik bölgesi ve kontrollü offline medya kullanılabilir. Transfer zinciri, checksum ve çift kontrolle izlenmelidir.

Tutarlı backup set'i oluşturun

Bir backup set'i şu ortak noktayı taşır:

backup_set_id
started_at / consistency_point
knowentra_db_backup
workflow_db_backup
object_storage_manifest
vector_backup_or_rebuild_manifest
configuration_revision
key_version_references
application_release
checksums

Uygulama yazmaya devam ederken

Tutarlı snapshot özelliği, transaction koordinasyonu veya kısa bakım penceresi kullanın. Özellikle şu yarışlara dikkat edin:

• DB'de dosya kaydı var, obje henüz yazılmamış
• Obje var, DB transaction'ı tamamlanmamış
• Kaynak metadata güncel, vektör indeksi eski
• Workflow dış sisteme yazdı, run durumu henüz commit olmadı
• Paused execution snapshot'ı var, Knowentra onay kaydı yok

Backup manifest'i her bileşenin zamanını ve tutarlılık durumunu kaydetmelidir.

Veritabanı yedekleme

• Yedek görevini uygulama hesabından ayrı kimlikle çalıştırın.
• Backup trafiği ve hedefini TLS/şifreleme ile koruyun.
• PITR log zincirinde boşluk alarmı kurun.
• Backup süresi, boyutu ve son başarılı zamanı izleyin.
• Şema/migration revision'ını manifest'e ekleyin.
• Extension ve gerekli veritabanı ayarlarını kaydedin.
• Yedeği üretim sunucusunun aynı diskinde tek kopya tutmayın.
• Restore için uyumlu veritabanı major sürümünü belgeleyin.

Veritabanı backup'ı alınırken workflow execution'ları devam ediyorsa dış sistem etkilerinin business key ve idempotency bilgileri korunmalıdır.

Obje ve dosya yedekleme

• Object versioning ve retention/object lock değerlendirin.
• Silme marker'larını ve eski sürümleri policy'ye göre koruyun.
• Metadata, content type, checksum ve encryption key version'ını saklayın.
• Cross-region/zone kopyanın veri yerleşimiyle uyumunu doğrulayın.
• Multipart/orphan objeleri backup kapsamından ayırın.
• Rastgele dosya örneklerinde checksum doğrulaması yapın.
• DB referansı olmayan obje ve objesi olmayan DB kaydı için reconciliation çalıştırın.

Dosyaları yalnız path'e göre değil immutable obje kimliği ve content hash ile doğrulayın.

Vektör deposu: yedek mi, yeniden üretim mi?

Rebuild seçerseniz şu girdiler korunmalıdır:

• Orijinal/normalize kaynak içerik
• Chunk stratejisi ve parser revision
• Embedding model kimliği ve checksum
• Source/ACL metadata
• Koleksiyon ayarı ve distance metric
• Aktif alias/revision

RTO hesabına embedding kuyruğu, model kapasitesi ve reconciliation süresini ekleyin.

Secret ve anahtar kurtarma

Anahtar yedeği için:

• KMS/HSM veya onaylı offline escrow kullanın.
• Veri yedeğinden ayrı erişim ve fiziksel/hesap sınırı uygulayın.
• Key ID ve version'ı backup manifest'ine yazın; anahtar değerini yazmayın.
• En az çift kontrol veya görev ayrılığı kullanın.
• Anahtarı restore ortamına aktarma prosedürünü test edin.
• Eski key version'ların saklama süresini şifreli veri yaşam döngüsüyle eşleştirin.
• Kurtarma sonrası kullanılan geçici erişimi iptal edin.

Workflow durumu

Workflow kurtarmasında yalnız tanım/graf yeterli değildir:

• Yayınlanmış workflow sürümü
• Trigger ve schedule
• Aktif/running execution
• Retry ve queue durumu
• Duraklatılmış human-in-the-loop snapshot'ları
• Bekleyen onay kayıtları
• Idempotency/business key
• Dış sistem request ve record ID'leri
• Credential referansları

Felaket anında running execution'ın dış yazmayı yapıp sonucu kaydetmeden durmuş olması mümkündür. Kurtarma sonrasında körlemesine retry etmeyin:

1. Execution'ı unknown outcome olarak sınıflandırın.
2. Dış sistemi business key/request ID ile sorgulayın.
3. Etki varsa run kaydını uzlaştırın.
4. Etki yoksa idempotent biçimde devam edin.
5. Belirsizse süreç sahibine manuel inceleme açın.

Paused execution ile onay kaydı ayrı veritabanlarındaysa ikisini reconciliation ile eşleştirin. Süresi geçmiş veya yetkisi değişmiş onayı otomatik resume etmeyin.

Model artefact'ları

Yerel model dosyaları çok büyük olabilir. Yeniden indirilebilir modeli her backup set'ine kopyalamak yerine:

• Model adı, revision, checksum ve lisansı kaydedin.
• Onaylı immutable iç registry/model deposu tutun.
• İnternetsiz ortamda offline kopyayı yedek kapsamına alın.
• Quantization ve runtime ayarını kaydedin.
• Restore sonrası bilinen test prompt'uyla model bütünlüğünü doğrulayın.

Model alias'ının restore sırasında yeni bir revision'a çözülmesine izin vermeyin; bu, davranış değişikliği yaratır.

Yedek güvenliği

• At-rest ve in-transit encryption
• Backup hesabında MFA/iş yükü kimliği ve en az ayrıcalık
• Üretim yöneticisinden ayrı silme yetkisi
• Immutable retention ve silme koruması
• Backup erişim ve export audit'i
• Zararlı yazılım/ransomware izolasyonu
• Veri sınıfına uygun bölge ve saklama
• Süre dolumunda doğrulanmış güvenli silme

Yedekler üretimden daha zayıf korunmamalıdır; çoğu zaman tüm tenant verisini tek yerde topladığı için daha yüksek etkili varlıktır.

Restore ortamını hazırlayın

Restore testi:

• Üretimden ağ olarak izole olmalı.
• Gerçek dış connector ve webhook'ları çağırmamalı.
• E-posta/bildirimleri sandbox veya sink'e yönlendirmeli.
• Schedule ve trigger'ları varsayılan kapalı başlatmalı.
• Test kullanıcıları ve kontrollü IdP yapılandırması kullanmalı.
• Restore verisine üretimle aynı sınıflandırma uygulanmalı.
• Test sonunda veri güvenli biçimde silinmeli.

Üretim yedeğini geliştirici laptop'una veya kontrolsüz test ortamına açmayın.

Geri yükleme sırası

1. Olayı sınırlandırın

• Yazmaları ve trigger'ları durdurun.
• Etkilenen credential'ları gerekiyorsa iptal edin.
• Kanıtı ve son bilinen iyi zamanı koruyun.
• Geri dönüş zamanını iş ve güvenlik sahibiyle onaylayın.

2. Temiz altyapıyı kurun

• Onaylı release/image digest'lerini kullanın.
• Ağ, DNS, TLS ve secret yönetimini hazırlayın.
• Bozulmuş üretim host'unu “temiz” varsaymayın.

3. Anahtarları hazır edin

• Doğru key version'ları güvenli kanaldan alın.
• Erişimi çift kontrolle kaydedin.
• Uygulama açılmadan secret referanslarını doğrulayın.

4. Veritabanlarını geri yükleyin

• Uyumlu engine/extension sürümünü kurun.
• Knowentra ve workflow DB'lerini ortak consistency point'e getirin.
• Migration'ı körlemesine çalıştırmadan schema revision'ı kontrol edin.
• Row count ve kritik constraint doğrulaması yapın.

5. Dosya/obje deposunu geri yükleyin

• Bucket policy ve encryption metadata'sını uygulayın.
• Manifest ve checksum'ları doğrulayın.
• DB ile obje reconciliation çalıştırın.

6. Vektör indeksini geri yükleyin veya üretin

• Doğru embedding/parser revision'ını kullanın.
• Tenant/Space ACL metadata'sını doğrulayın.
• Index alias'ını doğrulama tamamlandıktan sonra aktifleştirin.

7. Workflow durumunu uzlaştırın

• Running, retry, paused ve approval kayıtlarını eşleştirin.
• Dış sistem etkilerini business key ile kontrol edin.
• Trigger/schedule'ları kapalı tutun.

8. Uygulamayı kapalı doğrulayın

• Kimlik ve tenant izolasyonu
• Credential decrypt
• Belge indirme ve RAG citation
• Agent ve workflow sürümleri
• Audit yazımı
• Model/gateway bağlantısı
• Backup sonrası oluşturulan kritik kayıtlar

9. Kontrollü trafiğe açın

• Önce yönetici/smoke kullanıcıları
• Ardından salt-okunur işlevler
• Daha sonra connector ve workflow worker'ları
• En son yazma etkili trigger ve schedule'lar

10. Kurtarma sonrası

• Geçici credential ve erişimleri iptal edin.
• Veri kaybı penceresini ve manuel telafi listesini yayınlayın.
• RPO/RTO sonucunu kaydedin.
• Kök neden ve iyileştirmeleri takip edin.

Restore doğrulama matrisi

Toplam row count eşitliği gerekli olabilir; tek başına yeterli değildir. İlişkisel ve iş semantiği test edilmelidir.

Felaket senaryoları

Yanlışlıkla silme

• Yazmayı durdurun ve audit'ten kapsamı belirleyin.
• Point-in-time restore'u izole ortamda yapın.
• Mümkünse yalnız etkilenen nesneleri güvenli import edin.
• İlişkili chunk, ACL ve audit bağlarını doğrulayın.

Veritabanı bozulması

• Replikayı otomatik “iyi” kabul etmeyin.
• Son bütünlük kontrolü ve backup zincirini bulun.
• Temiz instance'a restore edin.
• Uygulama yazmalarını tutarlılık doğrulanana kadar açmayın.

Fidye yazılımı / credential ele geçirilmesi

• Olay müdahalesi ile DR'ı birlikte yürütün.
• Etkilenen kimlik, key ve token'ları döndürün.
• Immutable/offline yedekten temiz altyapıya dönün.
• Bozulmuş konfigürasyon ve artefact'ı taşımayın.
• Restore öncesi persistence mekanizmalarını araştırın.

Veri merkezi/bölge kaybı

• DR ağ/DNS ve compute katmanını açın.
• Son replication/backup consistency point'ini seçin.
• Anahtar ve artefact'ları ayrı bölgeden getirin.
• Split-brain'i önlemek için birincil yazmayı fence edin.
• Kontrollü DNS/traffic switch uygulayın.

Model veya embedding kaybı

• Onaylı checksum'lı artefact'ı geri yükleyin.
• Aynı revision yoksa davranış değişikliği olarak yönetin.
• Embedding değişirse yeni indeks oluşturun.
• Agent değerlendirme smoke testlerini tekrarlayın.

Kimlik sağlayıcı kesintisi

• Break-glass erişimini kontrollü kullanın.
• Yeni kullanıcı/rol değişikliklerini dondurun.
• IdP geri geldiğinde session ve üyelik reconciliation yapın.
• SSO kesintisini tenant yetkisini atlayarak çözmeyin.

Yüksek erişilebilirlik ile DR ayrımı

HA failover test edilmiş olsa bile backup restore ve bölge kaybı tatbikatı ayrıca yapılmalıdır.

DR topolojisi

Cold standby

Yalnız backup ve infrastructure-as-code hazırdır. Maliyet düşük, RTO uzundur.

Warm standby

Temel servisler düşük kapasitede çalışır; veri replike/yedekten günceldir. Orta maliyet ve RTO.

Hot standby

İkinci ortam tam kapasiteye yakın hazırdır. Düşük RTO, yüksek maliyet ve split-brain riski.

Seçimi yalnız lisans/maliyetle değil RPO, RTO, veri yerleşimi, key erişimi ve operasyon kapasitesiyle yapın.

DR tatbikatı

Tatbikat şu hedefleri içermelidir:

1. Haber vermeden değil kontrollü senaryoyla olay başlatılır.
2. Olay lideri, teknik lider, güvenlik ve iş sahibi atanır.
3. Son iyi backup/consistency point seçilir.
4. Temiz DR ortamına restore yapılır.
5. Kimlik, RAG, agent, workflow ve dış sistem test edilir.
6. Yazma trafiği fence ve onayla açılır.
7. Ölçülen RPO/RTO kaydedilir.
8. Eksik runbook, yetki ve otomasyon maddeleri aksiyona dönüştürülür.

Masa başı tatbikat prosedürü ölçer; teknik restore tatbikatının yerini tutmaz. En azından periyodik olarak gerçek veri kopyasıyla izole kurtarma yapılmalıdır.

Backup ve restore alarmları

• Son başarılı backup yaşı
• Backup süresi ve boyut anomalisi
• WAL/log arşiv zinciri boşluğu
• Immutable retention değişikliği
• Backup veya key erişim başarısızlığı
• Replication lag
• Restore testinin süresinin geçmesi
• Checksum ve manifest uyuşmazlığı
• Yetersiz backup hedef kapasitesi
• Kopya bölgesine aktarım gecikmesi

Alarm gerçek DR sahibine ve nöbet kanalına ulaşmalıdır.

Sorumluluk matrisi

Yönetilen hizmette hangi tarafın backup aldığı kadar restore testini kimin yaptığı, kanıtı kimin gördüğü ve başarısızlıkta kimin sorumlu olduğu sözleşmede yazmalıdır.

Kontrol listesi

• Varlık envanteri DB, obje, vektör, key, workflow ve audit'i kapsıyor.
• Her veri sınıfı için RPO, RTO ve sahibi belli.
• Backup set'leri ortak consistency point ve manifest taşıyor.
• Yedek hesabı üretim uygulama hesabından ayrı.
• En az bir immutable/offline kopya var.
• Anahtarlar veri yedeğinden ayrı ve çift kontrollü.
• PITR zinciri ve boşluk alarmı test edildi.
• Obje checksum ve DB reconciliation yapılıyor.
• Vektör backup/rebuild kararı ve ölçülmüş süresi var.
• Paused/running workflow ile dış etkiler uzlaştırılıyor.
• Model ve embedding revision/checksum korunuyor.
• Restore ortamı dış yazmalardan izole.
• Geri yükleme sırası ve smoke testler runbook'ta.
• Restore sonrası tenant ve credential negatif testleri geçiyor.
• DR topolojisi ve split-brain fencing yöntemi belli.
• Gerçek teknik tatbikat hedef RPO/RTO içinde tamamlandı.
• Geçici kurtarma erişimleri işlem sonrası iptal ediliyor.
• Sonuç ve iyileştirmeler audit/değişiklik kaydına bağlanıyor.

Sonraki adımlar

• Üretim kabulü için Üretim Kurulumu Kontrol Listesi
• Veri katmanları için Platform Mimarisi
• Kanıt zinciri için Audit Logları ve Gözlemlenebilirlik
• İş etkileri için Workflow Tasarım Rehberi
• Değişiklikler için Sürüm Yükseltme ve Değişiklik Yönetimi