Ironcore Backup Architecture

​

Overview

Ironcore Backup Solution (IBS) is a layered architecture optimised for incremental, deduplicated, encrypted backups across virtual machines, system containers, and physical hosts. At its core is Changed Block Tracking (CBT) — the hypervisor identifies precisely which disk blocks have changed since the previous backup so that only modified blocks are ever read, transmitted, and stored. CBT is what makes incremental backups fast and storage-efficient at scale. This page describes each component, the data flow between them, and the design decisions behind the storage model.

---

​

Deployment Model

Ironcore Backup Solution (IBS) splits the backup pipeline between the host that owns the workload and the backup server. The split is fixed: the host always performs change tracking, chunking, compression, and encryption; the backup server always performs deduplication, storage, replication, and verification. The location of the “host side” depends on the workload type:

---

​

High-Level Component Diagram

---

​

Service Inventory

---

​

Host-Side Pipeline

The host owns the most expensive part of the pipeline: identifying changes, chunking, compressing, and encrypting. As described in the Deployment Model above, the “host” is the hypervisor host for VM and container backups (agentless from the guest’s perspective), or the physical host itself for bare-metal backups via the ironcore-backup-client package.

​

Changed Block Tracking (CBT)

Changed Block Tracking (CBT) is the mechanism IBS uses to identify exactly which blocks of a disk have been modified since the previous backup. It is the single most important determinant of backup performance and storage efficiency. The hypervisor maintains a dirty bitmap per disk: a compact in-memory data structure where each bit represents a block on the disk. The bitmap is updated every time the guest writes to a block. At the start of each incremental backup:

1. The hypervisor exposes the current dirty bitmap.
2. The host-side pipeline iterates the dirty bits — and only the dirty bits.
3. For each dirty block, the data is read, chunked, compressed, encrypted, and transmitted to the datastore.
4. After the snapshot is committed, the bitmap is reset so the next incremental captures only post-backup writes.

Clean blocks (those not marked dirty) are never read. This is the core performance contract of CBT.

​

Why CBT Matters

For the production reference fleet (200 VMs × 100 GB × 2% daily change), CBT reduces daily backup IO from 20 TB to ~400 GB — a 50x reduction that makes the standard nightly backup window practical.

​

Content-Defined Chunking

Backup data is split into variable-sized chunks using a rolling hash. Chunk boundaries are determined by content fingerprints, not fixed offsets — this means inserting a byte in the middle of a file does not shift every subsequent chunk boundary, so deduplication remains effective.

​

Zstandard Compression

Per-chunk Zstandard compression precedes encryption. Typical compression ratios on mixed workloads are between 2x and 4x. Throughput on modern x86_64 hardware exceeds 1 GiB/s per core.

​

AES-256-GCM Encryption

Each chunk is encrypted with AES-256 in Galois/Counter Mode using the project encryption key. GCM provides authenticated encryption: any tampering with the ciphertext fails the GCM authentication tag during decryption. See Security and Encryption for key lifecycle, master keys, and paperkey recovery.

---

​

Server-Side Storage Model

The backup server stores data in a chunk-addressed datastore. Every chunk is named after its post-encryption SHA-256 fingerprint. Identical chunks always produce the same fingerprint, so writing a duplicate is detected and skipped.

​

Deduplication

When the client offers a chunk, the server checks whether the fingerprint already exists in the datastore. If so, the client uploads nothing — the snapshot manifest simply references the existing chunk. This applies across all sources sharing the datastore.

​

Append-Only Semantics

Existing chunks are never modified. New snapshots add new chunks; pruning removes snapshot manifests; garbage collection reclaims chunks no manifest references. This append-only model is critical for ransomware protection — see Security and Encryption.

---

​

Datastore Backends

See Datastores for provisioning detail and capacity planning.

---

​

Replication Topology

Replication mirrors snapshots from one datastore to another over an encrypted TLS 1.3 channel. The default topology pairs a Primary DC datastore with a Backup site datastore. See Replication and Sync.

---

​

Compliance Mapping

The following table maps internal architecture features to compliance requirements.

---

​

Next Steps