Sürüm: 1.2.0Bu dokümantasyon Spitfire 1.2.0 içindir.

Yüksek erişilebilirlik ve felaket kurtarma

Bu sayfa Spitfire'ın bugün neyi kesintisiz sürdürdüğünü, neyi sürdürmediğini, zamanlanmış şifreli yedeği, geri yükleme tatbikatını, güncellemedeki kesintiyi ve controller kapalıyken ne olduğunu anlatır. Yedek komutlarının kendisi Kurulum → Yedekleme bölümündedir.

Ne işe yarar

Kurumunuzun süreklilik planına (RPO/RTO) Spitfire'ı doğru yazmanız için: hangi parça tek kopyadır, hangisi yenisiyle değiştirilir, yedekten dönüş ne kadar veri kaybettirir ve ne kadar sürer.

Ne zaman kullanılır

Kurulumdan önce mimari ve süreklilik onayı için.
Zamanlanmış yedeği kurarken.
Yılda en az bir kez geri yükleme tatbikatı yaparken.
Güncelleme için bakım penceresi planlarken.

Bugünkü durum

Parça	Durum
Controller (arayüz, API, zamanlayıcı, sentetik izleme, runner bağlantıları)	Tek kopya. Kubernetes'te `replicas: 1` ve `strategy: Recreate`: canlı koşu durumu controller'ın belleğindedir, iki kopya aynı anda çalışmaz. Pod ya da sunucu düşerse Kubernetes/Docker onu yeniden başlatır; bu arada arayüz ve API kapalıdır.
Runner'lar	Durumsuz ve değiştirilebilir. Sonuçlar controller'a akar, runner'da veri kalmaz. Bir runner düşerse yerine yenisini açın; aynı token'la bağlanır. Koşu sırasında kopan runner için testin Runner kaybında seçeneği geçerlidir (Test editörü).
Kurulumla gelen Postgres ve ClickHouse	Tek kopya, kurulumun kendi diskinde.
Kendi Postgres'iniz ya da ClickHouse'unuz	Yüksek erişilebilirliği (replika, failover, yedek) sizin veritabanı ekibinize aittir. Spitfire tek bir bağlantı adresi kullanır; failover sonrası adres aynı kalmalıdır.
Yedek	`install.sh --backup` tek dosyada şifreli tam yedek alır (Postgres + kurulumun anahtarları). Zamanlamayı siz kurarsınız (aşağıda); ürünün içinde bir yedek zamanlayıcısı yoktur.
APM deposu (ClickHouse: trace, log)	Yedeğe girmez. Bu veri saklama süresiyle (1–30 gün) zaten sınırlıdır; geri yüklemeden sonra yeni gelen veriyle dolar.

Aktif/pasif bir ikinci controller planlanıyor; bugün yoktur.

Controller kapalıyken ne olur

Ne	Ne olur
Çalışan koşular	Runner'lar controller'a 15 sn ulaşamazsa yükü kendileri keser ("controller unreachable for more than 15s"): hedef gözetimsiz yük almaz. Controller açılınca bu koşular Kesildi olur, sebep "controller restarted". Controller düzgün durduruluyorsa (güncelleme, `docker compose stop`) önce aktif koşuları durdurup sonuçlarını kaydeder (30 sn'ye kadar).
Boştaki runner'lar	Artan aralıklarla (en çok 15 sn) yeniden bağlanmayı dener; controller açılınca kendiliğinden bağlanır.
Zamanlanmış koşular	Başlamaz. Controller 10 dakikadan kısa kapalıysa kaçan koşu açılışta başlar; daha uzunsa o koşu kaçırıldı olarak kaydedilir, sonradan yapılmaz ve bildirimi gider.
Sentetik izleme	Duraklar; açılınca bir sonraki aralıkta sürer. Aradaki kontroller sonradan yapılmaz.
Arayüz, API, CI hatları	Kapalıdır; API'yi çağıran CI adımları hata verir.
OTLP alıcısı (APM)	Servislerinizin OpenTelemetry SDK'ları kısa bir süre tekrar dener; tamponlarını aşan veri kaybolur.

Adım adım

1. Zamanlanmış şifreli yedek (Docker)

Yedek klasörünü açın:
bash
```
mkdir -p -m 700 ~/spitfire-backups
```

Yedek parolasını (en az 12 karakter) yalnız sizin okuyabileceğiniz bir dosyaya yazın:

bash

install -m 600 /dev/null ~/.spitfire-backup-pass && printf '%s' 'BURAYA-PAROLA' > ~/.spitfire-backup-pass

Bir yedeği elle alıp çalıştığını görün:

bash

SPITFIRE_BACKUP_PASSPHRASE="$(cat ~/.spitfire-backup-pass)" ~/spitfire/install.sh docker --backup ~/spitfire-backups/spitfire-$(date +%F).sfbak

Her gece 03:00 yedeği ve 14 günden eski yedeklerin silinmesi için crontab -e açıp şu iki satırı ekleyin:

text

0 3 * * * SPITFIRE_BACKUP_PASSPHRASE="$(cat $HOME/.spitfire-backup-pass)" $HOME/spitfire/install.sh docker --backup $HOME/spitfire-backups/spitfire-$(date +\%F).sfbak >> $HOME/spitfire-backups/backup.log 2>&1
30 3 * * * find $HOME/spitfire-backups -name '*.sfbak' -mtime +14 -delete

~/spitfire-backups klasörünü kendi yedekleme sisteminizle başka bir sunucuya kopyalayın. Parolayı yedeklerden ayrı (parola kasasında) saklayın: parolasız yedek açılmaz.

Başarı kontrolü: ertesi sabah bugünün dosyası vardır ve logda hata yoktur:

bash

ls -lh ~/spitfire-backups/ && tail -n 5 ~/spitfire-backups/backup.log

RPO (kaybedebileceğiniz en fazla veri) yedek aralığınızdır: gecelik yedekte en çok son 24 saat.

2. Zamanlanmış yedek (Kubernetes ve Helm)

Kurulumla gelen Postgres'le (varsayılan) aynı komut, kubectl erişimi olan bir yönetim makinesinden çalışır. Kurulum paketinin ~/spitfire altında açık olması yeterlidir (spitfire.tr/kurulum).

Yedeği elle alın:

bash

SPITFIRE_BACKUP_PASSPHRASE="$(cat ~/.spitfire-backup-pass)" ~/spitfire/install.sh kubernetes --namespace spitfire --backup ~/spitfire-backups/spitfire-$(date +%F).sfbak

Docker'daki 4. ve 5. adımı docker yerine kubernetes --namespace spitfire ile kurun.

Kendi veritabanınızı kullanıyorsanız (externalDatabase.existingSecret) veritabanını kendi yedek sisteminiz alır; Spitfire'dan yalnız anahtarları alın:

bash

kubectl -n spitfire get secret spitfire-secrets -o yaml > ~/spitfire-backups/spitfire-secrets.yaml

Başarı kontrolü: ls -lh ~/spitfire-backups/ bugünün dosyasını gösterir.

3. Geri yükleme tatbikatı

Tatbikatı çalışan kurulumda değil, ayrı bir deneme makinesinde yapın. Geçen süre sizin RTO'nuzdur; süreklilik planınıza bunu yazın.

Başlangıç saatini not edin:
bash
```
date
```
Deneme makinesine Spitfire'ı kurun (aynı ya da daha yeni sürüm):
bash
```
curl -fsSL https://spitfire.sh | bash -s -- docker
```
En yeni .sfbak dosyasını bu makineye kopyalayın (ör. scp) ve geri yükleyin:
bash
```
SPITFIRE_BACKUP_PASSPHRASE="$(cat ~/.spitfire-backup-pass)" ~/spitfire/install.sh docker --restore ~/spitfire-backups/spitfire-2026-11-04.sfbak
```
Kubernetes'te: ~/spitfire/install.sh kubernetes --namespace spitfire --restore ….

Controller'ın hazır olduğunu görün:

bash

curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8470/readyz

Arayüze yedekteki bir kullanıcıyla girin; Koşular'da yedek gününe kadarki koşuları, Bağlantılar'da bir bağlantının Test düğmesinin çalıştığını görün (secret'lar okunuyor demektir).
Bitiş saatini not edin (date). İki saat arasındaki fark RTO'nuzdur.

Başarı kontrolü: 4. adım 204 yazar, 5. adımdaki girişte yedekteki veriler vardır.

Gerçek bir felakette deneme makinesi yerine yeni sunucuyu kullanın ve runner'ların bağlandığı adı (DNS) yeni sunucuya çevirin. Controller'ın TLS kimliği yedekteki anahtarla geri geldiği için runner'ların CA pin'i değişmez; runner'lar kendiliğinden bağlanır.

4. Güncelleme ve geri alma

Docker ve install.sh kubernetes kurulumlarında güncelleme sürüm değişince önce veritabanının dökümünü alır (~/spitfire/backups/*.dump, son 5'i kalır).

Güncelleyin:

bash

curl -fsSL https://spitfire.sh | bash -s -- docker

Sorun çıkarsa son güncellemeyi geri alın (veritabanı o dökümdeki haline, sürüm öncekine döner; sonradan yapılan değişiklikler geri gelmez):
bash
```
~/spitfire/install.sh docker --rollback
```
Kubernetes: ~/spitfire/install.sh kubernetes --rollback.

Helm kurulumunda otomatik döküm yoktur. Yükseltmeden önce 2. bölümdeki yedeği alın, sonra yükseltin:

bash

helm repo update spitfire && helm upgrade spitfire spitfire/spitfire -n spitfire --reuse-values

Geri almak için önce eski sürüme dönün, sonra yükseltmeden önce aldığınız yedeği yükleyin (yeni sürüm veritabanı şemasını değiştirmiş olabilir):

bash

helm rollback spitfire -n spitfire

bash

SPITFIRE_BACKUP_PASSPHRASE="$(cat ~/.spitfire-backup-pass)" ~/spitfire/install.sh kubernetes --namespace spitfire --restore ~/spitfire-backups/spitfire-2026-11-04.sfbak

Kesinti: güncellemede controller bir kez durur ve yeni sürümle başlar (tek kopya, Recreate). Kesinti; aktif koşuların durdurulması (30 sn'ye kadar), başlama ve şema geçişinin süresidir ve dakikalar mertebesindedir. Döküm controller çalışırken alınır, büyük bir veritabanında güncellemenin toplam süresini uzatır. Kesintiyi kendi kurulumunuzda ölçmek için güncellemeden önce ikinci bir terminalde şunu başlatın; 204 dışındaki satırlar kesintidir:

bash

while :; do printf '%s %s\n' "$(date +%T)" "$(curl -s -o /dev/null -m 2 -w '%{http_code}' http://localhost:8470/readyz)"; sleep 1; done

Başarı kontrolü: güncellemeden sonra satırlar yeniden 204 yazar ve Lisans sayfasındaki Sürüm ve güncellemeler kartı yeni sürümü gösterir.

Dikkat

Güncellemeyi koşu yokken ve zamanlanmış koşuların arasında yapın: güncelleme sırasında çalışan koşular durdurulur.

Kapasite ölçümü

Doğrulanmış en büyük test (en çok VU, sürekli istek/sn, süre, runner sayısı, runner başına CPU/bellek, sonuç kaybı ve hata oranı) ölçüm yapılınca eklenecek.

Ölçü	Değer
En çok gerçek VU	ölçüm yapılınca eklenecek
Sürekli istek/sn	ölçüm yapılınca eklenecek
Süre	ölçüm yapılınca eklenecek
Runner sayısı, runner başına CPU/bellek	ölçüm yapılınca eklenecek
Sonuç kaybı (gönderilen ve kaydedilen istekler)	ölçüm yapılınca eklenecek
Hata oranı	ölçüm yapılınca eklenecek

Ölçüm Spitfire'ın kendi ölçüm aracıyla, her istekte neredeyse hiç iş yapmayan bir hedefe karşı yapılır: hedefin saydığı istekler controller'ın kaydettikleriyle karşılaştırılır, runner'ların CPU ve belleği koşu boyunca örneklenir. Kendi donanımınızda planlama için Runner'lar → Kapasite bölümündeki hesabı kullanın.

Sık karşılaşılan sorunlar

Belirti	Neden	Çözüm
Gece yedeği alınmamış, logda `docker: command not found`	cron'un `PATH`'i kısa	crontab'ın başına `PATH=/usr/local/bin:/usr/bin:/bin` satırını ekleyin.
Logda "Parola gerekiyor."	`SPITFIRE_BACKUP_PASSPHRASE` boş geldi	`~/.spitfire-backup-pass` dosyasının var ve dolu olduğunu kontrol edin.
Geri yüklemede "daha yeni bir sürümün yedeği" hatası	Deneme makinesindeki Spitfire yedeği alandan eski	Önce deneme makinesini güncelleyin, sonra geri yükleyin.
Geri yüklemeden sonra bağlantıların Test düğmesi parola/secret hatası veriyor	Yedek yerine elle döküm yüklendi, anahtarlar eski	`.sfbak` ile geri yükleyin ya da `SPITFIRE_SECRET_KEY`'i yedeğinizdeki değerle değiştirin.
Controller açıldıktan sonra koşu Kesildi, sebep "controller restarted"	Koşu sırasında controller durdu	Beklenen davranış; koşuyu yeniden başlatın.

Yüksek erişilebilirlik ve felaket kurtarma

#Ne işe yarar

#Ne zaman kullanılır

#Bugünkü durum

#Controller kapalıyken ne olur

#Adım adım

#1. Zamanlanmış şifreli yedek (Docker)

#2. Zamanlanmış yedek (Kubernetes ve Helm)

#3. Geri yükleme tatbikatı

#4. Güncelleme ve geri alma

#Kapasite ölçümü

#Sık karşılaşılan sorunlar

#İlgili sayfalar

Ne işe yarar

Ne zaman kullanılır

Bugünkü durum

Controller kapalıyken ne olur

Adım adım

1. Zamanlanmış şifreli yedek (Docker)

2. Zamanlanmış yedek (Kubernetes ve Helm)

3. Geri yükleme tatbikatı

4. Güncelleme ve geri alma

Kapasite ölçümü

Sık karşılaşılan sorunlar

İlgili sayfalar