Install your repository.
Validate the data path.

1. Plan role, release and capacity

Define master/repository and transfer-node roles, supported Linux architecture and matching package releases. Record DNS/IP, repository ID, actual disk/mount, minimum free space, concurrency and retention sizing. Do not assume every replication flow traverses a repository.

2. Validate the package and actual mount

Check the approved release package and published SHA-256 values. The filesystem must already be mounted; use a subdirectory such as EraRepository rather than the filesystem root. Validate checks preventing writes into an empty local folder after mount loss. This guide does not format disks or create mounts.

findmnt -T <MOUNT_PATH>
df -h <MOUNT_PATH>

3. Map repository identity to storage

Under the multi-repository contract, storages.id=7 maps to storage-7. The master’s repositories.json stores the physical path; clients/catalogs use repository identity. Never reuse an identity for a different physical disk. The documented production path registers <mount-path>/EraRepository through Infrastructure → Add Storage; compare its summary with the actual mount in the installed release.

4. Prepare service and protected credentials

Apply the matching package’s install-master.sh or registered-pool procedure through an approved installation plan. Manage token/credential files through a protected operator process; do not put them in chat, logs or packages. In the documented gateway layout the service listens on 127.0.0.1:19449; check service health and journal results. This inspection performed no installation or service restart.

systemctl status era-repository --no-pager
curl http://127.0.0.1:19449/healthz

5. Validate the HTTPS gateway and public endpoint

Expose an HTTPS /repository endpoint through Nginx/corporate TLS or an approved internal CA. The external data path uses 443; do not resolve endpoint errors by exposing 19449 externally. The public endpoint must be client-reachable; do not send the localhost backend address to compute nodes. Distribute the CA certificate to clients, never its private key. Retain certificate validation.

nginx -t
curl --cacert <CA_FILE> https://<REPOSITORY_DNS>/repository/healthz

6. Check client mapping and the capacity API

Match endpoint, repository ID, CA and protected token reference in client/DataMover configuration. In the authorized status API inspect enabled/healthy, available_bytes, min_free_bytes, reserved_bytes and reservable_bytes; df or UI Free Space alone is insufficient. BackupDisk selection in the image is a shared policy example, not the Infrastructure registration screen.

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.

7. Accept a small Full/incremental and restore cycle

In an approved small test match repository identity, Full/incremental catalogs, actual objects and hash verification. Accept readability with isolated restore; healthz alone is not data acceptance. The native RustFS S3 backend separately requires endpoint/bucket/prefix/credentials/capacity; local development gates remain open, so do not assume production readiness before TLS, retention/GC, fault, scale and WORM acceptance.