Set up R1Soft Disk Safe and Site-to-Site Replication

A single Server Backup Manager (SBM) protects you against agent or source-disk failure. It does nothing for a datacenter event, a ransomware-encrypted backup volume, or a rack power-distribution unit that takes both your primary and your SBM at once. R1Soft 5.10 and later ships two replication modes that fix this — pick by scope.

This guide configures both on a working R1Soft deployment, explains when each fits, and covers the failover and bandwidth tuning that most operators get wrong on the first attempt.

Pick the right mode

There are two replication flavours and they solve different problems:

• Disk Safe Replication — per-disk-safe copy from one SBM to another. Granular. You choose which protected machines replicate. Targets can be different SBMs per safe.
• Site-to-Site Replication — the entire SBM (configuration, all disk safes, policies, users) mirrored to a passive standby. Coarse, but recovery is one DNS change away.

Most hosting fleets run Disk Safe Replication for the customer-facing workloads they sell SLAs on, and skip it for internal infra they can rebuild. A few — typically those with regulated workloads or a small fleet — run Site-to-Site for everything.

Prerequisites

• Two SBMs, both on R1Soft 5.10 or later (replication API changed in 5.10; older versions are not bidirectionally compatible)
• Network reachability from primary SBM to secondary on TCP/8443 (default API port)
• Disk space on the secondary at least equal to the source — compression and dedupe carry over but plan for parity
• A valid R1Soft license on both SBMs (the secondary needs its own license to mount safes for restore)

Disk Safe Replication

Enable the replication API on the target SBM

On the secondary SBM, generate an API key the primary will use:

1. Settings → API → New API Key
2. Name it after the source SBM (replica-from-sbm-lhr01)
3. Copy the key — it is only shown once

Add the replication target on the source

On the primary SBM:

1. Disk Safes → choose the safe → Replication tab → Add Target
2. Target SBM URL: https://sbm-fra01.example.com:8443
3. Paste the API key
4. Choose the target volume on the secondary

Test the connection. A success here only proves the API talks — not that the replication itself works. The first replication run is the real test.

Schedule

Replication runs after recovery points by default. Three options:

• After each recovery point — lowest RPO, highest bandwidth burst. Default and almost always right.
• Hourly — batched, smoother bandwidth profile, RPO degrades to up to an hour.
• Daily — only for tier-3 workloads where one day of data loss is acceptable.

Bandwidth throttling

The Replication tab has per-target throttles. Set them. An unthrottled primary will saturate a 1 Gbps uplink during the initial seed of a multi-TB safe and your monitoring will page you within minutes.

Working hours (08:00-20:00): 200 Mbps
Off hours (20:00-08:00):     900 Mbps

Adjust to your transit costs. The first full replication of a 2 TB safe at 200 Mbps takes ~24 hours; deltas thereafter rarely exceed 50 Mbps.

Site-to-Site Replication

Site-to-Site mirrors the entire SBM. Configure on the primary:

1. Settings → Replication → Enable Site-to-Site
2. Target SBM URL and admin credentials
3. Initial sync direction: usually primary → secondary

On enable, the primary pushes its configuration database, all disk safe definitions, policies, users, and schedules to the secondary, then begins replicating recovery point data for every safe in the background.

The secondary runs in read-only standby. Restores work; new backups do not write to it.

Failover

When the primary is down:

1. On the secondary: Settings → Replication → Promote to Primary
2. Repoint agent SBM addresses (DNS change, or update cdp-agent config)
3. New recovery points now write to the former secondary

Failback is the same procedure in reverse — promote the original primary once it is restored, drain replication lag, then re-promote.

Verify replication is healthy

On the source SBM:

Disk Safes → Replication Status → Last Replication: <timestamp>
                                  Lag: < 1 recovery point
                                  Bytes Transferred: <delta>

On the secondary:

ls -la /backup-volume/disk-safes/

Each replicated safe appears with the same identifier as the source. Mount one read-only and browse a recovery point to prove the data is restorable, not just present.

Monitor the lag

Replication lag is the metric that matters. A safe that has not replicated in 6 hours is not protected — set alerts on the SBM's LastReplicationTimestamp API field. Most operators scrape this with Prometheus and alert at 2x the configured schedule.

For the broader picture of when to choose R1Soft over alternatives, see the R1Soft vs JetBackup comparison. For the initial agent install before any of this works, see installing the R1Soft agent on AlmaLinux.

Next steps

• Choose the right stack: R1Soft vs JetBackup.
• Install fresh agents: R1Soft agent on AlmaLinux.
• Buy or renew: R1Soft license.