> ## Documentation Index
> Fetch the complete documentation index at: https://docs.polystack.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Infrastructure Sizing

> Capacity planning for Ironcore Backup Solution — Primary DC datastore, Backup site datastore, restore rehydration capacity, and compute requirements.

## Overview

Sizing Ironcore Backup Solution (IBS) infrastructure is a balance of retention
windows, deduplication efficiency, network capacity, and recovery objectives.
This page provides reference sizing for the standard compliance retention
pattern (7-day daily, 3-week weekly at Primary DC; 52-week weekly at Backup site)
plus guidance for adjusting upward or downward.

<Note>
  **Prerequisites**

  * Administrator role on the Polystack platform
  * Knowledge of workload count, daily change rate, and average workload size
  * Inter-site bandwidth between Primary DC and Backup site
</Note>

***

## Inputs

| Input                         | Source                  | Used For                        |
| ----------------------------- | ----------------------- | ------------------------------- |
| Number of protected workloads | Compute inventory       | Storage and throughput          |
| Average workload size         | Disk usage per workload | Initial full size estimate      |
| Average daily change rate     | Workload telemetry      | Incremental size estimate       |
| Retention windows             | Compliance policy       | Total retained generations      |
| Deduplication ratio           | Pilot measurement       | Compression of storage estimate |
| Compression ratio             | Pilot measurement       | Compression of storage estimate |
| Backup window duration        | Operational policy      | Concurrent throughput target    |
| Restore RTO                   | Recovery objective      | Read throughput target          |

***

## Storage Sizing

The fundamental formula:

```
Stored bytes = (Σ full snapshots × workload size + Σ incremental snapshots × change size)
               ÷ (dedup ratio × compression ratio)
```

### Reference Calculation — Primary DC

Assumptions:

* 200 protected workloads
* Average workload size: 100 GB
* Average daily change rate: 2% (2 GB/day per workload)
* Deduplication ratio: 5x (typical mixed workloads)
* Compression ratio: 2.5x (typical mixed workloads)
* Retention: `keep-daily=7, keep-weekly=3`

| Layer                              | Snapshots | Raw Bytes     | After Dedup + Compression |
| ---------------------------------- | --------- | ------------- | ------------------------- |
| Daily incremental (200 × 7 × 2 GB) | 1,400     | 2,800 GB      | 224 GB                    |
| Weekly full (200 × 3 × 100 GB)     | 600       | 60,000 GB     | 4,800 GB                  |
| **Total Primary DC datastore**     |           | **62,800 GB** | **\~5,000 GB**            |

Add **30% headroom** for unexpected growth, deduplication misses, and metadata.
**Provision \~6.5 TB for Primary DC datastore.**

### Reference Calculation — Backup Site

Backup site holds 52 weeks of weekly fulls.

Assumptions same as above plus retention `keep-weekly=52`.

| Layer                                    | Snapshots | Raw Bytes        | After Dedup + Compression |
| ---------------------------------------- | --------- | ---------------- | ------------------------- |
| Weekly full archival (200 × 52 × 100 GB) | 10,400    | 1,040,000 GB     | 83,200 GB                 |
| **Total Backup site datastore**          |           | **1,040,000 GB** | **\~83 TB**               |

Add 30% headroom. **Provision \~110 TB for Backup site datastore.**

Add **rehydration capacity** for restoring archived data during recovery — see
the next section.

<Info>
  Deduplication ratio increases substantially when multiple workloads share an
  OS image, runtime, or dataset. Production environments often exceed 5x.
  Measure on a pilot before sizing — typical observed range is 3x to 8x.
</Info>

***

## Rehydration Capacity at the Backup Site

During recovery, archived data is rehydrated to a working datastore at the
Backup site for compute access. Plan rehydration capacity for the largest
single workload to be restored.

| Scenario                                | Rehydration Capacity Required                        |
| --------------------------------------- | ---------------------------------------------------- |
| Restore single workload (largest)       | 1 × largest workload size                            |
| Restore 10% of workloads simultaneously | 20 × average workload size                           |
| Restore all workloads (disaster)        | All workloads (potentially partial via live-restore) |

Typical practice: provision rehydration capacity for **10% of total workload
footprint** to support routine restores plus a planned multi-workload drill.

For the reference example above: 200 workloads × 100 GB × 10% = **2 TB rehydration capacity**.

<Tip>
  Use live-restore for the largest workloads — it begins serving the guest OS
  in seconds, avoiding the need to rehydrate the full disk to local storage
  before powering on.
</Tip>

***

## Throughput Sizing

Throughput drives both backup window duration and restore RTO.

### Backup Throughput

```
Backup ingest rate = (Σ incremental change bytes per day) ÷ backup window seconds
```

For the reference example:

| Setting                   | Value               |
| ------------------------- | ------------------- |
| Total incremental per day | 200 × 2 GB = 400 GB |
| Backup window             | 4 hours (14,400 s)  |
| Required ingest rate      | \~27 MB/s           |
| With 50% safety margin    | \~40 MB/s           |

A single backup server with a modern HDD or SSD datastore comfortably handles
this load. For larger fleets (1,000+ workloads), distribute across multiple
backup servers each owning a subset of namespaces.

### Restore Throughput

```
Restore RTO = workload size ÷ restore throughput
```

| Workload Size | Restore Throughput | RTO          |
| ------------- | ------------------ | ------------ |
| 100 GB        | 200 MB/s           | \~8 minutes  |
| 500 GB        | 200 MB/s           | \~42 minutes |
| 1 TB          | 200 MB/s           | \~85 minutes |
| 5 TB          | 200 MB/s           | \~7 hours    |

Live-restore shifts the perceived RTO to **seconds** for the guest OS, with
background restore continuing while the workload is running.

***

## Backup Server Compute Sizing

| Resource           | Per Backup Server             | Notes                                                 |
| ------------------ | ----------------------------- | ----------------------------------------------------- |
| **CPU**            | 8-16 cores                    | Heavy compression and verification load               |
| **RAM**            | 32-64 GB                      | Chunk cache improves dedup hit rate                   |
| **Datastore disk** | Sized per storage calculation | SSD or hybrid for primary; HDD or object for archival |
| **Local OS disk**  | 200 GB SSD                    | OS, logs, configuration                               |
| **Network**        | 10 GbE minimum                | Both ingest and replication                           |

For very large environments, scale horizontally — multiple backup servers each
owning a partition of the datastore namespace.

***

## Network Sizing

### Within a Site

Backup traffic between workloads and the local backup server is intra-DC,
typically over 10 GbE or 25 GbE. The 27 MB/s figure above sits well within
either capacity.

### Between Sites

Inter-site replication runs over a metro or WAN link. Size for the weekly
archival sync.

```
Inter-site bandwidth = (weekly archival data) ÷ sync window
```

For the reference example with 200 workloads:

| Setting                                       | Value                    |
| --------------------------------------------- | ------------------------ |
| Weekly full snapshots per week                | 200                      |
| Per-snapshot size (after dedup + compression) | \~8 GB                   |
| Total weekly archival                         | 1,600 GB                 |
| Sync window                                   | 6 hours overnight Sunday |
| Required sustained bandwidth                  | \~75 MB/s                |
| With 50% safety margin                        | \~110 MB/s = \~1 Gbps    |

For typical enterprises, **1 Gbps dedicated inter-site link** is sufficient for
the reference example. Use bandwidth throttling on the sync job to coexist
with other traffic during business hours.

***

## Sizing Worksheet

Use this worksheet to derive a custom sizing.

| Input                            | Your Value         |
| -------------------------------- | ------------------ |
| Number of protected workloads    | \_\_\_\_\_\_\_\_\_ |
| Average workload size (GB)       | \_\_\_\_\_\_\_\_\_ |
| Daily change rate (%)            | \_\_\_\_\_\_\_\_\_ |
| Deduplication ratio              | \_\_\_\_\_\_\_\_\_ |
| Compression ratio                | \_\_\_\_\_\_\_\_\_ |
| Retention: keep-daily            | \_\_\_\_\_\_\_\_\_ |
| Retention: keep-weekly (Primary) | \_\_\_\_\_\_\_\_\_ |
| Retention: keep-weekly (Backup)  | \_\_\_\_\_\_\_\_\_ |
| Backup window (hours)            | \_\_\_\_\_\_\_\_\_ |
| Inter-site sync window (hours)   | \_\_\_\_\_\_\_\_\_ |

Derived:

```
Daily incremental volume = workloads × workload_size × daily_change_pct
Weekly full volume = workloads × workload_size

Primary DC raw retained =
  (daily_incremental × keep_daily) +
  (weekly_full × keep_weekly_primary)

Backup Site raw retained =
  weekly_full × keep_weekly_backup

Primary DC datastore size =
  Primary_DC_raw × 1.3 ÷ (dedup × compression)

Backup Site datastore size =
  Backup_Site_raw × 1.3 ÷ (dedup × compression)

Inter-site bandwidth =
  (weekly_full × workloads) ÷ sync_window × 1.5
```

***

## Reference Sizing Table

| Fleet Size                  | Primary DC | Backup Site | Inter-site |
| --------------------------- | ---------- | ----------- | ---------- |
| 50 workloads, 100 GB avg    | 1.5 TB     | 25 TB       | 250 Mbps   |
| 200 workloads, 100 GB avg   | 6.5 TB     | 110 TB      | 1 Gbps     |
| 500 workloads, 200 GB avg   | 32 TB      | 540 TB      | 5 Gbps     |
| 1,000 workloads, 500 GB avg | 160 TB     | 2.7 PB      | 25 Gbps    |

Assumes 5x dedup, 2.5x compression, 2% daily change rate, `keep-daily=7,
keep-weekly=3` at Primary and `keep-weekly=52` at Backup site.

***

## Growth Planning

| Metric                        | Source                     | Action                                                  |
| ----------------------------- | -------------------------- | ------------------------------------------------------- |
| Datastore fill rate (GB/week) | Datastore statistics panel | Project fill date; expand at 70% used                   |
| Inter-site sync duration      | Sync job history           | Expand bandwidth or shorten retention if duration grows |
| Restore time trends           | Restore task history       | Tune live-restore usage or storage tier                 |
| Verification job duration     | Verification task history  | Expand backup server compute or partition datastore     |

<Warning>
  At 80% datastore utilisation, plan immediate expansion. At 95%, IBS refuses
  new backups to protect data integrity. Free-space alerts at 80% and 90%
  are configured automatically — confirm they dispatch to your operations
  notification group.
</Warning>

***

## Multi-Region Topology

For platforms with multiple Primary sites and a shared Backup site:

```mermaid theme={null}
graph LR
    subgraph "Primary DC A"
        PA[Primary DC A datastore]
    end
    subgraph "Primary DC B"
        PB[Primary DC B datastore]
    end
    subgraph "Backup Site"
        B[Shared backup datastore<br/>partitioned by source namespace]
    end
    PA -->|Push sync| B
    PB -->|Push sync| B
```

Size the Backup site for the **sum** of all Primary sites. Deduplication
extends across all sources sharing the datastore — workloads that share an
OS image at any Primary site contribute only one copy.

***

## Next Steps

<CardGroup cols={2}>
  <Card title="Datastores" icon="database" href="/services/ironcore-backup/admin-guide/datastores" color="#bf9667">
    Provision the sized datastores
  </Card>

  <Card title="Replication and Sync" icon="arrow-left-right" href="/services/ironcore-backup/admin-guide/replication-sync" color="#bf9667">
    Configure replication to match the sized inter-site bandwidth
  </Card>

  <Card title="Retention Policies" icon="calendar-days" href="/services/ironcore-backup/admin-guide/retention-policies" color="#bf9667">
    Adjust retention windows to match the sized capacity
  </Card>

  <Card title="Architecture" icon="layers" href="/services/ironcore-backup/admin-guide/architecture" color="#bf9667">
    Architectural background for the sizing factors
  </Card>
</CardGroup>