Skip to main content

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.

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.
Always verify the remote’s TLS fingerprint out-of-band. A man-in-the-middle attack would otherwise be undetectable. The fingerprint is shown on the remote’s web interface under Certificates.

Create a Push Sync Job (Primary → Backup Site)

This is the recommended configuration for weekly archival replication.

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

If the source datastore holds unencrypted snapshots (legacy or unencrypted-by-policy workloads), enable Encrypt on push so the destination receives encrypted chunks. The destination must hold the matching decryption key for any restore from the Backup site.

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

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.
Compare datastores with ironcore-backup sync diff. The diff lists snapshots present on only one side. Re-run the sync to align.
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