> For the complete documentation index, see [llms.txt](https://docs.kangal.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kangal.dev/tr/production-operasyonlari/backup-restore.md). # Backup ve restore Yedekler kontrol düzlemi durumunu korur; yapılandırma anlık görüntüleri ise daha dar bir yapılandırma iş akışına hizmet eder. Bu iki yöntem birbirini tamamlar, birbirinin yerine geçmez. ## Veri sahipliği * **MongoDB:** Tenant'ların, gateway'lerin, route'ların, politikaların, kimliklerin, denetim kayıtlarının, yapılandırma sürümlerinin, bölgesel durumun ve diğer kontrol düzlemi verilerinin doğruluk kaynağıdır. * **Redis:** Ortak sayaçları, oturumları, önbellekleri, çalışma zamanı koordinasyonunu ve Redis Streams etkinse kalıcı iş stream'i ile dizinini tutar. * **Veri düzlemi depolaması:** İmzalı `last-known-good` yapılandırmayı ve anti-rollback güven dayanağını tutar. Çevrim dışı sürekliliği destekler; kontrol düzlemi yedeğinin yerini almaz. * **Sürüm ve ortam yapıtları:** Hizmeti yeniden kurmak için gereken imzalı chart, imaj özetleri, values özeti, haricî Secret sürümleri ve altyapı tanımlarıdır. Kalıcı işler etkinse Redis verilerinin tamamını gözden çıkarılabilir kabul etmeyin. Kabul edilmiş bir stream kaydının kaybı işi kaybettirebilir; sonucu belirsiz bir işi yeniden oynatmak haricî yan etkiyi tekrarlayabilir. Redis kalıcılığını, yedeğini ve idempotency kullanımını iş yükünün RPO'suna göre tasarlayın. ## Yedekleme otomasyonu Yedekleme yardımcısı ve isteğe bağlı chart CronJob'u `mongodump` çalıştırır, gzip arşivi oluşturur ve yanına SHA-256 ile boyut içeren bir JSON manifest yazar. Yardımcı, URI kimlik bilgilerini manifest ve dry-run çıktısında maskeler. Oluşturulan arşiv MongoDB'yi kapsar. Operatörler arşiv ile manifesti şifreli, değiştirilemez depolamaya aktarmalı; çoğaltma ve saklama politikasını uygulamalı; geri yükleme testlerini yürütmeli ve manifesti hassas metadata olarak korumalıdır. Redis, Kubernetes Secret sürümleri, DNS, sertifikalar ve altyapı kendi platform hizmetleri üzerinden yedeklenmelidir. Geri yükleme hedefi seçimi ve yıkıcı işlem onayı her zaman kontrollü operatör adımlarıdır. Sıkı bir belirli zamana geri dönüş hedefi için uygulama arşivlerini sağlayıcı destekli MongoDB snapshot veya PITR ile birlikte kullanın ve transaction tutarlılığındaki kurtarma davranışını sınayın. ## Hedefleri tanımlama Her ortam için şu kararları kaydedin: | Konu | Zorunlu karar | | ---------------- | ------------------------------------------------------------------------------------------------------------ | | RPO | Kaybedilebilecek en uzun onaylanmış veri ve iş aralığı | | RTO | Kurtarma ilanından doğrulanmış hizmete kadar geçen süre | | Saklama | Günlük, haftalık ve aylık kopyalar ile yasal saklama | | Kopyalar | En az bir şifreli, değiştirilemez, küme dışı kopya | | Yetki | Yedek başlatma, şifre çözme, geri yükleme ve silme yetkileri | | Tatbikat sıklığı | Günlük doğrulama, aylık hazırlık ortamı geri yüklemesi ve üç aylık bölgesel tatbikat pratik bir başlangıçtır | ## Arşiv oluşturma ve doğrulama MongoDB Database Tools kurulu, erişimi kısıtlı bir ana makineden çalıştırın. Bağlantıyı kabuk geçmişine yazılan komut argümanı yerine süreç ortamı veya projected file ile verin: ```bash test -n "${MONGODB_URL:-}" export MONGODB_DATABASE=kangaldb python scripts/backup_restore.py \ --database "$MONGODB_DATABASE" \ backup \ --output-dir /secure/backups/kangal ``` Komut, arşiv ve manifest yollarını yazdırır. Aktarımdan önce doğrulayın: ```bash python scripts/backup_restore.py verify \ /secure/backups/kangal/.archive.gz ``` Arşiv ile manifesti tek birim olarak şifreli ve değiştirilemez depolamaya kopyalayın. Nesne sürümünü, retention lock bilgisini, şifreleme anahtarı referansını, sağlama toplamını, veri tabanı küme kimliğini, sürüm etiketini, tamamlanma zamanını ve yedek işinin kimliğini ayrıca kaydedin. Manifest bağlantı metadata'sı içerdiğinden erişimini sınırlandırın. ## Zamanlanmış Kubernetes yedekleri Chart, mevcut bir PVC'ye yazan tek CronJob oluşturabilir: ```yaml backup: enabled: true schedule: "0 2 * * *" concurrencyPolicy: Forbid database: kangaldb existingSecret: kangal-runtime mongoUriKey: MONGODB_URL persistence: existingClaim: kangal-backups networkPolicy: enabled: true ``` CronJob'u etkinleştirmeden önce PVC'yi sağlayın ve tamamlanan her arşiv için küme dışı aktarım düzenleyin. Çok bölgeli tek bir veri tabanına karşı yinelenen, belirsiz arşivler oluşmaması için yalnızca bir yetkili zamanlama çalıştırın. Bağlantı dizesini göstermeden tek seferlik bir çalıştırma başlatıp inceleyin: ```bash CRONJOB=$(kubectl -n "$NAMESPACE" get cronjob \ -l app.kubernetes.io/instance="$RELEASE",app.kubernetes.io/component=backup \ -o jsonpath='{.items[0].metadata.name}') JOB="kangal-backup-$(date +%s)" kubectl -n "$NAMESPACE" create job --from="cronjob/$CRONJOB" "$JOB" kubectl -n "$NAMESPACE" wait "job/$JOB" --for=condition=Complete --timeout=1h kubectl -n "$NAMESPACE" logs "job/$JOB" ``` Tamamlanmış bir Job yalnızca komutun bittiğini gösterir. Arşivi erişimi kısıtlı bir doğrulama iş yüküne salt okunur bağlayın, SHA-256 değerini yeniden hesaplayın ve takvime göre hazırlık ortamında geri yükleme yapın. ## Geri yükleme tatbikatı Her zaman önce yalıtılmış bir hazırlık veri tabanına geri yükleyin: 1. Değişiklik kaydı açın; arşivi, manifesti, hedefi, RPO/RTO'yu ve onaylayanı belirleyin. 2. İndirmeden önce ve aktarımdan sonra nesne saklama metadata'sını ve SHA-256 değerini doğrulayın. 3. Hedef bağlantının hazırlık ortamını gösterdiğini ve gerekli veri içermediğini teyit edin. 4. Maskelenmiş komutu incelemek için dry-run çalıştırın. 5. Yalnızca hedef onaylandıktan sonra sağlama toplamı doğrulaması ve `--drop` ile geri yükleyin. ```bash python scripts/backup_restore.py \ --database "$MONGODB_DATABASE" \ restore /secure/backups/kangal/.archive.gz \ --verify \ --drop \ --dry-run python scripts/backup_restore.py \ --database "$MONGODB_DATABASE" \ restore /secure/backups/kangal/.archive.gz \ --verify \ --drop ``` `--drop`, geri yüklemeden önce hedefte eşleşen koleksiyonları siler. Hedef URI'yi, veri tabanı adını ve değişiklik yetkisini birbirinden bağımsız olarak kontrol etmeden bu seçeneği çalıştırmayın. ## Üretim kurtarması 1. Kurtarmayı ilan edin, trafik değişikliklerini durdurun, zaman çizelgesini ve mevcut durumu koruyun. 2. Yönetim yazmalarını durdurun; API üreticilerini ve çalışanları sıfıra indirin. Politika izin veriyorsa veri düzlemleri yalnızca doğrulanmış `last-known-good` yapılandırmayla trafik sunabilir. 3. Arızalı veri tabanını ve sağlayıcı günlüklerini koruyun. Kurtulabilecek veya seçime katılabilecek birincil üzerine geri yükleme yapmayın. 4. Mümkünse yeni bir kurtarma hedefi oluşturun; topolojiyi ve transaction desteğini doğrulayın. 5. Seçilen arşivi veya sağlayıcı PITR noktasını doğrulayıp geri yükleyin. 6. Redis'i tanımlanmış iş ve oturum RPO'suna göre kurtarın. Yeniden oynatmadan önce bekleyen işleri ve haricî idempotency kayıtlarını inceleyin. 7. API replikalarını başlatıp `/ready` yanıtını doğrulayın; ardından uyumlu çalışanları başlatın. 8. Tenant, gateway, route, politika, consumer, sertifika, denetim ve yapılandırma sürümü sayılarını olay öncesi kanıtla karşılaştırın. 9. Veri düzlemi sürüm ve sağlama toplamı yakınsamasını, yönlendirilmiş trafiği, oturum açmayı, arka plan iş sağlığını, metrikleri ve denetim teslimini doğrulayın. 10. Yazmaları ve trafiği kademeli açın; ölçülen RPO/RTO'yu ve izleme eylemlerini kaydedin. Etiket tabanlı iş yükü durdurma aşağıdaki gibi hazırlanabilir. Olay yöneticisi uygulamayı onaylamalı ve özgün replika sayıları önceden kaydedilmelidir: ```bash kubectl -n "$NAMESPACE" get deploy \ -l app.kubernetes.io/instance="$RELEASE" kubectl -n "$NAMESPACE" scale deployment \ -l app.kubernetes.io/instance="$RELEASE",app.kubernetes.io/component=api \ --replicas=0 kubectl -n "$NAMESPACE" scale deployment \ -l app.kubernetes.io/instance="$RELEASE",app.kubernetes.io/component=background-jobs \ --replicas=0 ``` ## Kabul kanıtı Başarılı bir tatbikat; arşiv ve manifest sağlama toplamını, kaynak ve hedef küme kimliklerini, sürüm ve şema sürümlerini, başlangıç/bitiş zamanlarını, geri yüklenen kayıt sayılarını, örnek tenant okumalarını, yönlendirilmiş bir isteği, çalışan ve kuyruk durumunu, veri düzlemi yakınsamasını, ölçülen RPO/RTO'yu ve temizlik kanıtını içerir. Kanıta bağlantı dizesi, token, özel anahtar veya müşteri payload'u eklemeyin. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.kangal.dev/tr/production-operasyonlari/backup-restore.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.