Overview
Ironcore Backup Solution (IBS) protects workloads using block-level change tracking, content-defined deduplication, Zstandard compression, and client-side encryption. Every backup transmits only the modified blocks since the previous run, encrypts them on the client before they leave the workload, and writes them into a chunk-addressable datastore that deduplicates identical blocks across every protected source. This page explains the end-to-end flow from a running workload to a restorable snapshot.Prerequisites
- An active Polystack account with project membership
- At least one backup datastore configured by an administrator
- The workload you want to protect is reachable from a backup client
Deployment Model
Ironcore Backup Solution (IBS) uses two complementary deployment models depending on the workload type:Agentless (for VMs and containers)
For virtual machines and system containers running on the Ironcore platform,
backup is fully agentless from the workload’s perspective. The hypervisor
performs block-level change tracking, reads only modified blocks, and
streams them to the backup datastore. No software is installed inside
the guest VM or container. The guest is unaware of the backup.
Agent-based (for physical hosts)
For physical Linux hosts and any standalone workload outside the
virtualisation layer, you install the lightweight
ironcore-backup-client
package on the host. The client reads files directly, applies the same
pipeline (chunk, compress, encrypt), and pushes to the datastore. Best
for configuration, application data, and bare-metal protection.The same pipeline (change tracking, chunking, compression, encryption) runs
in both models. Only the location of the pipeline differs: the hypervisor
for VM and container backups, the host itself for physical machines.
Backup Pipeline
For VMs and containers, every step in this pipeline runs on the hypervisor host. For physical hosts, it runs on the host itself via theironcore-backup-client
package. In both cases the backup server only ever sees encrypted chunks — it
cannot decrypt them without the key, which is held by the workload owner.
Core Concepts
Block-Level Change Tracking
The hypervisor records which blocks have been modified since the previous
backup. Only modified blocks are read, hashed, and uploaded. Unmodified
blocks are skipped entirely.
Content-Defined Chunks
Source data is split into variable-sized chunks at boundaries determined by
content fingerprints. Identical chunks always produce the same identifier,
enabling cross-source deduplication.
Compression
Zstandard compression is applied per-chunk before encryption. Typical
workloads compress at 2-4x with negligible CPU overhead — multiple gigabytes
per second on modern hardware.
Client-Side Encryption
Each chunk is encrypted with AES-256 in Galois/Counter Mode (GCM) using a
key held only by the workload owner. The backup server stores ciphertext
with no ability to decrypt.
What a Snapshot Contains
Every backup produces a snapshot — an immutable, named point-in-time view of the workload.| Component | Description |
|---|---|
| Manifest | Metadata, hash list, owner, timestamp, source ID, signature |
| Chunk index | Ordered list of chunk identifiers (SHA-256 fingerprints) |
| Encrypted chunks | Per-chunk encrypted ciphertext, addressed by fingerprint |
| Verification record | Per-chunk SHA-256 hash for integrity verification |
vm/12345) share
chunks through deduplication. Removing one snapshot does not affect the others —
chunks are garbage-collected only when no live snapshot references them.
Restore Pipeline
Restore reverses the backup pipeline. The client fetches encrypted chunks from the datastore, decrypts them locally with the project’s key, decompresses, and writes the reassembled data to the target — a new VM, a host filesystem, or a file download.Live-Restore
For VM workloads, IBS supports live-restore: the VM is registered and powered on as soon as the manifest is read, then chunks are streamed on demand while the guest OS is running. The guest OS becomes accessible in seconds, even for terabyte-class VMs. The remaining blocks are pulled in the background and seamlessly served to the guest as the OS accesses them.Retention and Pruning
Snapshots are retained according to the policy attached to the backup job or datastore. The most common retention windows are:| Window | Meaning |
|---|---|
keep-last=N | Keep the most recent N snapshots regardless of age |
keep-hourly=N | Keep the most recent snapshot for each of the last N hours |
keep-daily=N | Keep the most recent snapshot for each of the last N days |
keep-weekly=N | Keep the most recent snapshot for each of the last N weeks |
keep-monthly=N | Keep the most recent snapshot for each of the last N months |
keep-yearly=N | Keep the most recent snapshot for each of the last N years |
Where Backups Are Stored
Primary DC Datastore
Primary DC Datastore
Local datastore at the Primary DC for daily incremental and weekly full
backups. Sized for short-term recovery scenarios — typical retention 1 week
daily, 3 weeks weekly.
Backup Site Datastore
Backup Site Datastore
Remote datastore at the Backup site. Receives a replicated copy of every
weekly full backup for long-term archival. Typical retention 52 weeks.
Tape Library
Tape Library
Optional offline archive. Weekly full backups are written to LTO tape and
catalogued for compliance scenarios that require offline media.
Object Storage
Object Storage
Optional S3-compatible object storage backend for elastic capacity or
geographic redundancy beyond the on-premises Backup site.
Next Steps
Create a Backup
Create your first on-demand backup of a VM, container, or host
Backup Jobs
Schedule recurring backups with retention windows
Restore Options
Compare live-restore, full restore, and file-level restore
Architecture
Deeper architectural detail for administrators