BEFORE YOU BEGIN
Check before you begin
Repository destination, source NAS/bucket and replication destination are different roles. Validate local-filesystem pools and native RustFS S3 backend requirements separately. Menus, health or free-space displays alone do not establish successful backup/restore acceptance.
Screenshots were captured from the actual lab interface on 16 October 2026. The interface is in English; explanations follow your selected language. Resource names, dates and settings are examples; use values for your own environment.
Some lab screenshots are withheld pending privacy review. Follow the documented steps and use your own environment values.
Visual limit: the earlier real Linux File Backup policy screen is used only to illustrate Storage selection and BackupDisk capacity. It is not a repository installer, Infrastructure/Add Storage or administration-panel screenshot. No new installation screen was captured; no mount, credential, TLS, service, pool or retention settings were changed. Commands are operator-validated check examples using environment values; they were not executed in this inspection.
- Matching package/service releases and topology
- Stable repository ID and actual mount/backend
- HTTPS/CA, service identity and capacity reservations
- Backup chain, isolated restore and operations owner
011. Match storage and repository inventory
Record Infrastructure storage entries, repository identity, physical mount/backend, enabled/healthy state and source policies together. UI names such as BackupDisk are not repository identities. The earlier image only illustrates policy Storage selection and capacity; it does not establish current inventory or mount health.
Earlier real Agent Policy screen: BackupDisk selection and Total/Free/Used Space. File Backup is selected; this is not repository installation or a storage administration panel. Capacity values are historical lab examples; check current reservations/health separately.
Expected resultRepository identity and the relevant check result are recorded.
022. Monitor available and reserved capacity
Compare available, min_free, reserved and reservable values with active jobs and retention growth. RustFS capacity is an administrative ceiling, not free disk space automatically discovered through statfs. Account for aggregate reservations and headroom across jobs. Distinguish disk fullness, quota, mount and endpoint failures.
Expected resultRepository identity and the relevant check result are recorded.
033. Diagnose mount and access failures
Check actual mount/export, service identity, healthz and client HTTPS access separately. The local incident document traced capacity preflight failed to clients receiving a localhost-only 19449 endpoint; opening more ports was not the fix. Consider running jobs and recovery references before mount or storage changes.
Expected resultRepository identity and the relevant check result are recorded.
044. Manage Transfer Limits and concurrency
Infrastructure → Transfer Limits uses the documented backup_resource_limits records. global/openstack affects total jobs; compute/<hostname> and storage/<backend> add more specific limits. The documented datamover/workers range is 1–32 with default 4; changes affect new transfers while running jobs retain their value. Higher counts do not guarantee performance; pilot using capacity and latency measurements.
Expected resultRepository identity and the relevant check result are recorded.
055. Preserve backup chains when changing policies
A new Full starts on the selected repository; incrementals in an existing Full set remain pinned to its original repository even after policy storage changes. A subsequent Full may start a new set on the new destination. Restore uses repository_id from the authorized catalog rather than guessing from the current policy. Do not treat the old repository as empty or unnecessary after a policy change.
Expected resultRepository identity and the relevant check result are recorded.
066. Separate disable, retention and deletion
Disabling a pool blocks new uploads; it does not remove existing catalogs/restore objects from disk. Do not unmount or remove a disabled pool while recovery points reference it. Retention/GC and bucket lifecycle/WORM are different mechanisms; do not manually delete objects/chunks independently of catalogs. Identity reuse or physical-path changes require a validated migration and rollback plan.
Expected resultRepository identity and the relevant check result are recorded.
077. Maintain watchdog, alerts and recovery tests
The documented era-storage-watchdog.timer checks mounts once per minute; an unexpected loss triggers a transition alert after three attempts and a recovery message when restored. It respects manual eject status=0; this is not a general automatic-mount/HA guarantee. Include service/SMTP/alert routing and periodic isolated restore in the test plan. This inspection sent no alert and performed no pool disable or deletion.
Command examplesystemctl status era-storage-watchdog.timer --no-pager
journalctl -u era-storage-watchdog.service -n 100 --no-pager
Expected resultRepository identity and the relevant check result are recorded.
COMMON QUESTIONS
Does disabling a pool delete all backups?
No. It blocks new uploads; existing objects and catalog references remain. Do not remove storage while a restore chain references it.
