This article is the canonical reference for every measured performance and security number published on www.statewarden.com and in StateWarden materials. It states what was measured, on which systems, and under which conditions.
1. Why this page exists
StateWarden labels every public performance and security claim by its source. There are four labels:
- Measured in lab: a repeatable test result produced on the reference systems described below, with the test method disclosed in this article.
- Engineering target: a design goal the system is built to meet; it is not yet a published measurement.
- Self-assessed: our own evaluation against a published framework, with the scoring method disclosed (for example the SEAL assessment).
- Third-party verified: confirmed by an external organization, with the scope of the verification stated next to the claim.
If a number appears on a StateWarden page without one of these labels, that is an editorial error - report it via a Support ticket.
2. Test environment
Measurements come from two sources.
On-premises lab:
- Hypervisors: Proxmox VE 9 and VMware ESXi/vCenter 8.0.3.
- Client systems: Debian 13 and Windows 10/11.
- Reference workstations: AMD Ryzen 7 7700X with Kingston NVMe storage (Windows 11) and AMD Ryzen 9 9950X3D (Debian 13).
- Lab network: 1 Gbps.
Own production fleet: 24 machines (workstations and servers, Windows and Linux) running against the production control plane.
Verification method: every measurement is repeated across multiple runs. Results are cross-checked against system journals and database records; no result is accepted from a UI confirmation alone.
3. Agent resource footprint
| Measurement | Windows 11 rig (Ryzen 7 7700X) | Debian 13 rig (Ryzen 9 9950X3D) |
|---|---|---|
| CPU at idle | 0.02% | 0.02% |
| RAM at idle | ~24 MB | ~24 MB |
| CPU during full backup | 26% | 21% |
| CPU during incremental backup (Smart CBT) | 28% | 18% |
Two boundary conditions apply to these numbers. First, the 1 Gbps lab network was the bottleneck in every backup run - the agent was never the limiting factor. Second, disk throughput was measured as identical with and without the agent installed.
The write-path overhead of the change-tracking driver has not been measured yet. It is listed under Engineering targets below, and no figure for it appears anywhere in StateWarden materials.
4. Recovery times
Instant iSCSI Mount (see Instant Mount: File Recovery via Native iSCSI):
| Scenario | Measured time |
|---|---|
| Linux volume | 5-20 s |
| Windows volume | 5-120 s |
Mount time is independent of volume size. Volumes tested: 30 GB, 500 GB, 10 TB, and 1 PB.
Proxmox Instant Boot: the mount task completed within 15 s; the guest OS reached its booted state in ~120 s.
Smart BMR bare-metal recovery (see Bare Metal Recovery Walkthrough), measured wall-clock from booting the Recovery ISO to the OS login screen, on 2 TB reference disks:
| OS | Individual runs (minutes) | Range |
|---|---|---|
| Linux | 5, 6, 5, 6, 4 | 4-6 min |
| Windows | 7, 8, 7, 9, 8 | 7-9 min |
The measurement includes booting the recovery environment, authentication, recreating the disk layout, transferring the system data over the 1 Gbps link, and the first boot of the restored OS to its login screen. It excludes post-restore activities such as application reconfiguration, domain rejoin, and restoring additional data volumes. In these runs the operator entered the recovery key manually, which is a known source of variance - automated key delivery would be faster.
5. Scale and deduplication
- Largest protected volume: a 1 PB Ceph cluster.
- Largest single Realm: 24 devices.
Deduplication measured on production Realms, as logical restore size compared to physical storage occupied:
| Logical restore size | Physical storage | Key mode |
|---|---|---|
| 13.10 TB | 210 GB | Realm key |
| 8.15 TB | 207 GB | Per-device key |
| 30.15 TB | 620 GB | Realm key |
| 3.15 TB | 177 GB | Realm key |
An incremental backup of a typical volume with ~5% daily change completes in about 2 minutes. A reference VM is backed up every 4 hours.
Deduplication ratios are workload-dependent. The figures above describe four specific production Realms; they are not a prediction for any other workload.
6. Fleet reliability (own production use)
StateWarden protects its own production fleet with the same software shipped to customers:
- 24 machines under continuous protection for 6 months.
- 100% 30-day backup success rate across the fleet.
- ~40 agent OTA updates delivered since April 2026.
- Longest uninterrupted run: 6 months.
7. Active Defense test results
The following results come from live tests of the entropy-based ransomware detector and its response options (see Ransomware Protection: Response Policies):
- Simulated attack data measured at an average entropy of 7.51/8, compared to 3.73 for ordinary data.
- The alert was dispatched 5 seconds after detection.
- The affected backup was automatically quarantined and marked.
- The optional network lockdown kept the management channel alive and persisted across a hard reset, until reversed by an MFA-confirmed unlock.
- With Smart CBT armed, detection triggered after roughly 500 MB of encrypted writes.
- The forced-poweroff response option was also exercised.
All results were reproduced on live production systems.
8. Claims glossary
- RTO (Recovery Time Objective): the targeted maximum time between a failure and the restored service being available again. Instant Mount time and full BMR time are different metrics: Instant Mount measures access to backup data on a running system, while BMR measures a complete machine rebuild to the login screen. Quoting a mount time as the RTO for full system recovery would be misleading, so StateWarden publishes both numbers separately.
- Instant Mount: attaching a backup snapshot to a running system over iSCSI so that files can be read or copied immediately, without restoring the whole volume.
- Instant Boot: starting a virtual machine directly from its backup on the hypervisor, before any data is transferred back to local storage.
- Smart BMR: StateWarden's bare-metal recovery procedure: boot the machine from the Recovery ISO, authenticate, select a restore point; the disk layout is recreated and the system data is written back.
- Incremental-forever backup: after one initial full backup, every subsequent run transfers only changed blocks; restore points are synthesized from the deduplicated chunk store, so no periodic repeated full backup is required.
- "Measured" vs "engineering target": "measured" means a number produced by the test process described in this article; "engineering target" means a design goal that has not yet been published as a measurement, and it is labeled as such wherever it appears.
9. Engineering targets (not yet measured)
The following are design goals, not published measurements:
- Recovery-time guarantees under a contractual SLA.
- Write-path overhead of the change-tracking driver.
- Agent resource overhead on networks faster than 1 Gbps.
- Crypto-layer throughput figures.
- A deduplication ratio for any specific customer workload.
When a StateWarden page states a number without the measured label, it belongs to this list.
10. How to verify
- The Security Challenge describes how external researchers and customers can test StateWarden's security claims directly.
- The SEAL sovereignty whitepaper documents the self-assessment against the EU Cloud Sovereignty Framework, including the scoring method.