Ana içeriğe geç

Backups sekmesi

Tek bir uygulamanın Velero yedekleri — anlık yedek alma, zamanlanmış yedekler ve restore. Her şey baktığınız release'e scope'ludur.

Top-level bir "Backups" sidebar girişi ve edge seviyesinde bir yedek yüzeyi yoktur. Yedekler bir uygulamanın altındadır: Applications → release'e tıkla → Backups sekmesi. Orada gördüğünüz her yedek ve schedule o release'e (namespace'i + kaynakları) aittir; başka release'lerin yedekleri görünmez.

Velero edge'de kurulu değilse sekme boş bir liste gösterir — önce Velero'yu kurun (standart edge preset içerir).

Yedek listesi​

SütunAnlamı
AdCluster'daki yedek adı (otomatik üretilir: <release>-backup-<zaman>)
DurumNew / InProgress / Completed / Failed / PartiallyFailed
BaşladıVelero'nun yedeği başlattığı an
ÖğelerVelero'nun yakaladığı kaynak sayısı
İşlemlerGeri Yükle (yalnızca Completed satırlarda aktif) / silme

Durumlar anlamsal renk kullanır — Completed yeşil, InProgress sarı (spinner ile), Failed kırmızı, PartiallyFailed turuncu. Liste sekme açıkken 30 saniyede bir yenilenir.

Bir yedekleme veya restore sürerken Yedek Al ve Yedek Zamanlamaları butonları ile satırlardaki Geri Yükle devre dışıdır — release başına aynı anda tek Velero işlemi. Backend de aynı kuralı uygular (OPERATION_IN_PROGRESS).

Yedek Al dialogu​

Yedek Al (sekmenin sağ üstünde) küçük bir dialog açar:

  • Saklama süresi (TTL) — yedeğin ne kadar tutulacağı. Varsayılan 720h (30 gün). Biçim: 720h, 24h, 30m gibi Go tarzı bir süre
  • Yedekleme Konumu — yalnızca org'da en az bir yedekleme konumu tanımlıysa render edilir (Organizations → Yedekleme Konumları). Seçenekler: varsayılan seçenek (org'un varsayılan konumu işaretliyse adı, değilse Cluster içi depolama (varsayılan)) + tanımlı tüm konumlar. Harici konumlar cluster kaybında bile hayatta kalır.

Formun tamamı bu — yedeğin adı ve kapsamı release'ten otomatik türetilir (namespace'i + kaynakları; cluster'da CSI snapshot desteği varsa volume verisi dahil). Submit asenkron bir operation kuyruğa atar; satır listede belirir ve kendi kendine ilerler. İlerleme Operations Center'da da görünür.

Yedek Zamanlamaları drawer'ı​

Yedek Zamanlamaları (Yedek Al'ın yanında; schedule varsa sayı rozeti taşır) release'in schedule'larını listeleyen bir yan drawer açar:

SütunAnlamı
AdSchedule adı (otomatik üretilir: <release>-schedule-<zaman>)
Cron İfadesiStandart 5 alanlı cron
Son YedekEn son zamanlanmış çalışma
İşlemlerSilme

Zamanlama Oluştur drawer içinde inline bir form açar:

  • Cron İfadesi — örn. her gece 02:00 için 0 2 * * *. Form 5 alanlı olmayan hiçbir ifadeyi kabul etmez
  • Saklama süresi (TTL) — her çalışmaya uygulanır
  • Yedekleme Konumu — harici konum tanımlıysa, Yedek Al dialogundaki dropdown'ın aynısı

Cron'un sahibi Velero'dur; her zamanlanmış çalışma yedek listesinde bir satır olarak görünür. Schedule silmek ürettiği yedekleri silmez — onlar kendi TTL'leri dolana kadar yaşar.

Restore​

Completed bir yedekte Geri Yükle bir onay dialogu açar — restore her zaman release'in kendi namespace'ini hedefler, doldurulacak ek seçenek yoktur. Onaylayınca asenkron bir operation kuyruğa girer; uygulama yedekteki duruma döner.

Yedek silme de bir onay dialogudur; Velero yedeği hem cluster'dan hem storage'dan kaldırır.

Backup'lar nereye gider​

Seçtiğiniz Yedekleme Konumu'na (seçmediyseniz varsayılana) bağlıdır:

  • Cluster içi depolama — Velero, cluster kurulurken yapılandırılan BackupStorageLocation'a yazar. DT Edge Platform bu storage'ı yönetmez — Backup / Restore CR'lerini okur ve durumlarını gösterir.
  • Harici yedekleme konumu — Organizations → Yedekleme Konumları altında tanımlanmış bir S3 hedefi (org'unuz veya platform admin'i tarafından). Oraya giden yedekler cluster tamamen kaybedilse bile hayatta kalır. Varsayılan işaretli konumlar, açık seçim yapılmadan alınan yedekleri yakalar. Bkz. Nasıl yapılır: yedekleme konumlarını yönet.

Her konumun Test Et aksiyonu vardır (bir uç birim seçilir; o uç birimin yedekleme ajanı doğrular, 90 saniyeye kadar sürebilir) — sonuç Available / Unavailable. Konum silmek mevcut yedekleri geri yüklenebilir bırakır; yeni yedekler artık o konumu seçemez.

Bir BackupStorageLocation doğrulamak için:

kubectl -n velero get backupstoragelocation

Yeni yedeklerin başarılı olması için Available görünmeli.

Sık hatalar​

  • Geçersiz TTL biçimi — 720h, 24h veya 30m gibi bir süre kullanın
  • Geçersiz cron ifadesi — 5 alan olmalı (örn. 0 2 * * *)
  • OPERATION_IN_PROGRESS — bu release üzerinde başka bir işlem sürüyor; bitmesini bekleyin
  • BACKUP_LOCATION_UNAVAILABLE — seçilen harici yedekleme konumuna erişilemiyor; endpoint, kimlik bilgileri ve CA sertifikasını kontrol edin (veya konumun Test Et aksiyonunu çalıştırın)
  • BACKUP_LOCATION_NOT_VALIDATED — konum zamanında doğrulanamadı; uç birimde Velero'nun sağlıklı olduğundan emin olun
  • PartiallyFailed — kaynakların çoğu yakalandı ama en az bir item hata verdi; edge'teki Velero loglarına bakın

Ayrıca bakın​