Depolamayı izleyin.
Kurtarma zincirini koruyun.

1. Storage ve repository envanterini eşleştirin

Infrastructure storage kaydı, repository ID, fiziksel mount/backend, enabled/healthy ve kaynak politikaları birlikte kaydedin. BackupDisk gibi UI adları tek başına repository kimliği değildir. Önceki görsel yalnız politika Storage seçimi ve kapasite örneğidir; güncel envanter veya mount sağlığı kanıtı sayılmaz.

Önceki gerçek Agent Policy ekranı: BackupDisk seçimi, Total/Free/Used Space. File Backup seçilidir; bu görüntü repository kurulumu veya storage yönetim paneli değildir. Kapasite değerleri geçmiş lab örneğidir; güncel rezervasyon/health ayrıca kontrol edilir.

2. Kullanılabilir ve rezerve kapasiteyi izleyin

available, min_free, reserved ve reservable değerlerini aktif işler ve saklama büyümesiyle karşılaştırın. RustFS kapasitesi yönetimsel tavandır; statfs ile otomatik keşfedilen disk boşluğu değildir. Birden çok iş için toplam rezerve alanı ve güvenlik payını hesaba katın. Dolu disk, quota, mount ve endpoint sorunlarını aynı hata gibi ele almayın.

3. Mount ve erişim hatalarını teşhis edin

Gerçek mount/export’u, servis hesabını, healthz ve client HTTPS erişimini ayrı kontrol edin. Yerel olay belgesinde capacity preflight failed hatası client’a localhost-only 19449 endpoint’i verilmesinden kaynaklanıyordu; geniş port açmak çözüm değildi. Yeni mount veya storage düzenlemesinde açık işleri ve kurtarma referanslarını dikkate alın.

4. Transfer Limits ve eşzamanlılığı yönetin

Infrastructure → Transfer Limits, belgelenen backup_resource_limits kayıtlarını kullanır. global/openstack toplam işi, compute/<hostname> ve storage/<backend> daha özel sınırları etkiler. datamover/workers belgede 1–32, varsayılan 4’tür; değişiklik yeni transferlerde geçerli, çalışan iş kendi değerini korur. Sayıyı artırmayı otomatik performans kazanımı saymayın; kapasite ve latency ölçümüyle pilot yapın.

5. Politika değişikliğinde backup zincirini koruyun

Yeni Full seçili repository’de başlar; mevcut Full setinin artımlıları, politika storage alanı sonradan değişse bile eski repository’ye bağlı kalır. Sonraki Full yeni hedefte set açabilir. Restore yetkili katalogdaki repository_id değerini kullanır; mevcut politika hedefinden yol tahmin etmez. Eski repository’yi politika değişti diye boş veya gereksiz saymayın.

6. Disable, saklama ve silmeyi ayırın

Pool disable yeni upload’ları engeller; mevcut katalog/restore objelerini diskten silmez. Kurtarma noktaları referans veriyorsa disabled pool’u unmount etmeyin veya kaldırmayın. Retention/GC ve bucket lifecycle/WORM ayrı mekanizmalardır; katalogdan bağımsız elle obje/chunk silmeyin. Kimliği yeniden kullanma veya fiziksel yol değişimi için doğrulanmış taşıma ve rollback planı gerekir.

7. Watchdog, alarm ve kurtarma testini sürdürün

Belgelenen era-storage-watchdog.timer mount’u dakikada bir kontrol eder; beklenmeyen kayıpta üç deneme sonrası durum geçiş alarmı ve düzelince recovery mesajı gönderir. Manuel eject status=0 durumuna saygı duyar; bunu genel otomatik mount/HA garantisi saymayın. Servis/SMTP/alarm rotasını ve periyodik izole restore’u test planına ekleyin. Bu çalışma alarm göndermedi, pool disable veya silme yapmadı.

systemctl status era-storage-watchdog.timer --no-pager
journalctl -u era-storage-watchdog.service -n 100 --no-pager