Overview
Replication mirrors snapshots from one datastore to another over an encrypted channel. Ironcore Backup Solution (IBS) supports both push (Primary site initiates) and pull (Backup site initiates) topologies, with bandwidth throttling, schedule control, and end-to-end integrity verification. This page covers configuring sync jobs, choosing the right topology, and validating the result. The standard configuration mirrors weekly full backups from the Primary DC to the Backup site for long-term archival.Prerequisites
- Administrator role on the Polystack platform
- At least two datastores — one at the Primary DC site, one at the Backup site
- Network connectivity between sites on TCP/8007 (TLS 1.3)
- Identical encryption keys configured on both sites if push-time encryption is enabled
Topology
Register the Remote Site
Before creating a sync job, register the remote endpoint as a Remote.- Deployment Console
- CLI
Open Remotes
Navigate to Backup Solution > Replication > Remotes.
Add a new remote
Click Add Remote. Enter:
- Name:
backup-site - Host:
ibs.backup.<your-domain> - Port:
8007 - Auth-ID:
sync@polystack!replication - Fingerprint: TLS certificate fingerprint from the remote
Test connectivity
Click Test. The Dashboard probes the remote and reports reachability.
Save
Click Save.
The remote is listed under Replication and is selectable in sync jobs.
Create a Push Sync Job (Primary → Backup Site)
This is the recommended configuration for weekly archival replication.- Deployment Console
- CLI
Open Sync Jobs
Navigate to Backup Solution > Replication > Sync Jobs.
Click Create Sync Job
Click Create Sync Job.
Set source and target
Set:
- Name:
primary-to-backup-archival - Source datastore:
ibs-primary - Remote:
backup-site - Remote datastore:
ibs-archival - Direction: Push
Filter snapshots
Set Include filter to
keep-weekly=* so only weekly snapshots
replicate, not daily incrementals.Set schedule
Set the schedule to
Sun 04:30 — runs after the weekly full backup at
03:00 and after the daily prune at 05:00.Set bandwidth and encryption
Configure:
- Bandwidth limit: based on your inter-site link capacity
- Encrypt in transit: enabled (default)
- Encrypt snapshots on the fly: enabled — encrypts at push time using the project key
Save
Click Save.
The sync job appears in the list with the next scheduled run time.
Create a Pull Sync Job (Backup Site → Primary)
A pull sync runs on the Backup site, fetching snapshots from the Primary. Used when the Backup site cannot accept inbound connections from the Primary, or for security separation.Create a pull sync job
A pull sync requires the remote registration on the Backup site, with the
Primary site as the remote.
Encryption in Transit
Bandwidth Management
Sync jobs typically run during off-hours, but inter-site link capacity may be shared with production traffic. Use bandwidth limits to coexist.Filter Expressions
Integrity Verification
After every sync, the destination runs a SHA-256 verification on the newly received chunks. The result is recorded in the destination snapshot’s verification report. If a chunk fails verification, IBS automatically retries up to 3 times before marking the sync as failed and emitting a notification.Replication Monitoring
Recover From a Failed Sync
Sync failed mid-transfer
Sync failed mid-transfer
Failed syncs do not leave the destination in an inconsistent state — chunks
are committed only after the full manifest is signed. Re-run the sync; only
chunks that did not complete are retransmitted.
Destination drifted from source
Destination drifted from source
Compare datastores with
ironcore-backup sync diff. The diff lists
snapshots present on only one side. Re-run the sync to align.TLS fingerprint mismatch after certificate renewal
TLS fingerprint mismatch after certificate renewal
The remote’s TLS certificate was renewed. Update the registered fingerprint
after verifying the new certificate out-of-band.
Disaster Recovery Workflow
When the Primary site is unavailable and you need to restore from the Backup site:Designate the Backup site as the new restore source
Operators connect their backup CLI or Dashboard to the Backup site directly.
Restore the workload
Use the standard restore procedures from the Backup site datastore. Choose
the most recent weekly archival snapshot.
Reverse the sync
After the Primary site is recovered, configure a temporary reverse sync to
re-seed the Primary datastore with any snapshots created in the meantime.
Restore normal direction
Once the Primary is fully re-seeded, restore the original sync direction.
Next Steps
Verification and Validation
Schedule SHA-256 verification on both sites
Tape and Object Storage
Layer on long-term tape archival from the Backup site
Security and Encryption
Key handling for snapshots that replicate between sites
Infrastructure Sizing
Capacity planning across both Primary and Backup sites
