Rancher operator restore, dağıtıma özgü etcd kurtarma ve EraBackup PVC restore farklı işlemlerdir. Bu rehber topoloji ve kabul planıdır; canlı management/etcd üzerine yazma ya da bütün cluster’ları otomatik kurtarma talimatı değildir.
Ekran görüntüleri 16 Ekim 2026 tarihli gerçek laboratuvar arayüzünden alınmıştır. Arayüz İngilizcedir; açıklamalar seçtiğiniz dilde sunulur. Gösterilen kaynak adları, tarihler ve ayarlar örnektir; kendi ortamınızın değerlerini kullanın.
Doğrulama sınırı: Rancher yönetim veya downstream canlı restore testi yapılmadı. Paylaşılan EraBackup katalog ekranları Rancher operator çıktısı veya Rancher’a özgü başarılı restore kanıtı olarak etiketlenmez.
Kaynak katman, backup kimliği ve sürüm eşleşmesi
Local/downstream hedef ayrımı ve kurtarma sırası
Storage, erişim ve gerekli şifreleme materyali
İzole test, uygulama verisi ve yönetim kabulü
01
1. Kaydın hangi katmana ait olduğunu belirleyin
Kaydın Rancher operator çıktısı mı, node/etcd kaydı mı yoksa downstream PVC/database yedeği mi olduğunu doğrulayın. Her birinin kaynağı, sürümü ve hedefi farklıdır. Yanlış katmana ait yedeği yönetim kurtarması olarak kullanmayın.
Beklenen sonuç
Katman ve kurtarma yöntemi eşleşir.
02
2. Management restore planını resmî prosedürle eşleştirin
Operator çıktısı için kurulu Rancher sürümüne uygun restore/migration prosedürünü kullanın. Hedef local cluster, sürüm uyumu, storage ve gerekiyorsa şifreleme materyali hazır olmalıdır. EraBackup kataloğunda Kubernetes kaydı görünmesi operator restore’unu otomatik yapmaz.
Beklenen sonuç
Management işleminin ayrı kapsamı ve sorumlusu bellidir.
03
3. Downstream kaydını EraBackup’ta bulun
Home → Backups içinde doğru downstream kaynak ve yöntemi bulun. Action → Restore ile öğe ve noktayı inceleyin. RKE2 adı, job adı veya Kubernates etiketi tek başına kaynağın gerçekten Rancher tarafından yönetildiğini kanıtlamaz.
Paylaşılan EraBackup Kubernetes katalog örneği; bu işin Rancher downstream kaynağı olduğu doğrulanmadı. Not Yet Backup durumundaki kayıt restore kanıtı değildir. Büyüt ↗
Beklenen sonuç
Gerçek downstream kaynak ve nokta belirlenir.
04
4. PVC hedefi ve etcd kurtarmasını ayırın
Doğrulanmış PVC akışında sunuluyorsa Different Location ile izole namespace/storage hedefini değerlendirin. ETCD/RKE2 kaydı yalnız Original Location sunuyorsa deneme için ilerlemeyin; dağıtıma özgü uzman planı gerekir. K3s hedefinde RKE2 akışını varsaymayın.
Beklenen sonuç
İş yükü hedefi ve control plane riski ayrılır.
05
5. Bağımlılık ve hedef özetini kontrol edin
Kaynak/backup ID, hedef context, namespace, storage ve uygulama bağımlılıklarını karşılaştırın. Management ve workload erişimlerini karıştırmayın. Yalnız onaylı izole uygulama hedefi ve doğrulanmış yöntem için son restore eylemini kullanın; management işlemi kendi prosedüründe kalır.
Beklenen sonuç
Onaylı hedef ve bağımlılık sırası kaydedilir.
06
6. Yönetim görünürlüğü ve kaynak sağlığını ayrı izleyin
Rancher yönetim erişimi ve downstream bağlantı durumunu, Pod/PVC ve uygulama verisi kabulünden ayrı değerlendirin. Bir cluster’ın arayüzde görünmesi verisinin geri geldiğini göstermez. Başarısız kurtarmayı aynı hedefe tekrar tekrar göndermeyin.
Beklenen sonuç
Yönetim görünürlüğü ile veri sağlığı ayrıdır.
07
7. Katman başına kabul kanıtını belgeleyin
Management oturumu, downstream kaynak sağlığı, test dosyası/database sorgusu ve bağımlılık erişimini ayrı doğrulayın. Sürümler, backup ID, hedef ve süreyi kaydedin. Yönetim backup başarısını downstream veri kurtarma veya tam Rancher DR başarısı gibi sunmayın.
Beklenen sonuç
Her katmanın gerçek sonucu belgelenir.
MERAK EDİLENLER
Yönetim paneli açılınca kurtarma tamamlanır mı?
Hayır. Downstream uygulama verileri ve bağımlılıkları ayrıca kabul edilmelidir.