VM Recovery

VM Backup and Bare Metal Restore — Estimate Your Recovery Time

Recovery time depends on VM content, data size, network and hardware. The estimator below uses assumed inputs, so treat its result as an estimate. Scheduled restore verification records real restore times in your environment. Recover a single file from a backed-up VM, recover the entire VM to different hardware, or restore a specific snapshot.

Varies

Depends on VM content

15 Min

Min. snapshot interval

Parallel

Recover several VMs in parallel

Recovery granularity levels

IT Director / CIO

RTO: typical, depends on VM content
RPO: Every 15 minutes or more frequent snapshots
Included - no separate VM backup licensing
Boot-test results show recovery time before an incident

Solutions Architect

Agent-based protection for guests on any hypervisor
Granular restore: individual files, volumes, entire VM
Boot from backup data
Point-in-time snapshots and recovery testing

System Administrator

Simple recovery workflow (click, select VM, recover)
Testing capability without affecting production
Health checks before failover
Centralized recovery from cloud dashboard

Granular Recovery Options

Recover entire VM

Restore to the same or different hardware, with boot repair and optional driver injection.

Recover individual files

Mount VM snapshot, browse file system, extract specific files without full restore.

Recover volumes

Restore specific disks without recovering the whole VM.

Boot from backup data

Boot a recovered VM straight from backup data while you plan a full restore. A brief reboot is needed to cut over to the restored VM.

Virtualization Engine

You Choose Where the VM Runs

ShadowCradle stores the backup data. When you need to spin up a VM from that data, you are not limited to the appliance that holds it. Any peer ShadowCradle appliance on the network can act as the virtualization engine - pulling data from its peer and running the recovered VM locally. The receiving appliance does not need to match the original in CPU, RAM, or storage size.

Standard

Local Appliance Recovery

Appliance A
backup data + hypervisor

VM 1

VM 2

VM 3

The appliance that holds the backup data also runs the recovered VMs. Simple: no separate recovery host needed.

Peer Virtualization

Peer Appliance as Engine

Appliance A

backup data

stream

Appliance B

runs VMs

VM 1

VM 2

VM 3

Any peer hardware

A peer appliance streams backup data from Appliance A and runs the recovered VMs locally. Hardware specs do not need to match - any peer can serve as the compute engine.

LiveCD Virtualization Engine

Physical Hardware via LiveCD

ShadowCradle

backup data

iSCSI

Any Hardware

LiveCD + QEMU

VM 1

VM 2

VM 3

No OS install required

Boot the ShadowCradle LiveCD (Ubuntu-based ISO) on any physical machine. The ISO auto-launches a built-in QEMU hypervisor, connects to the backup appliance over iSCSI, mounts the backup volumes directly, and starts running your VMs on bare metal - no OS installation or existing infrastructure needed.

iSCSI Integration

Your Own Hypervisor via iSCSI

ShadowCradle
iSCSI target

Your hypervisor
iSCSI initiator

VM 1

VM 2

VM 3

Use your existing hypervisor, or any platform with an iSCSI initiator. ShadowCradle exposes backup volumes as iSCSI targets. Your hypervisor connects directly and presents the volumes - VMs run from backup data with no copying required.

Flexible Recovery Hardware

The peer appliance acting as the virtualization engine does not need to match the appliance that holds the backup data in CPU architecture, RAM, or storage size. You can use whatever compute is available, such as a smaller standby appliance at a DR site or a larger appliance for scale-out.

VM Recovery Capabilities

Capability	ShadowCradle
Boot from backup data	Boot a recovered VM from backup data while you plan a full restore. A brief reboot cuts over
Granular file recovery	Mount a VM snapshot, browse the file system and extract single files
Scheduled restore verification	Scheduled boot tests with per-VM pass/fail reports
Peer appliance as virtualization engine	A peer appliance runs the recovered VM
Application-consistent snapshots	Snapshots taken in an application-consistent state

Real-World Use Cases

Ransomware Recovery

Ransomware infects VM; must recover to a clean state quickly.

✅VM recovered online from a clean snapshot

✅Measured restore time recorded

✅Restore to the snapshot you choose

✅Automatic detection of pre-infection snapshot

Hardware Failure - 12 VMs

Physical server fails; must recover 12 VMs.

✅All 12 VMs recovered in parallel

✅Recovered to the chosen snapshot

✅No manual configuration needed

✅Automatic network/storage setup

Rapid Scale-Out

Need to clone a database VM 5 times for dev environment by tomorrow morning.

✅5 identical VMs from one backup

✅No manual configuration

✅Each clone is an independent VM

Key Advantages

✅Recovery time depends on VM content

✅Granular options: Recover files, volumes, or entire VM

✅Live testing: Verify recovery works without affecting production

✅Cloud-ready: Works with AWS, Azure, on-prem equally

✅Simple operations: No specialist knowledge needed

Verified RTO

No Guesses. You Know Exactly How Long Recovery Takes.

ShadowCradle periodically boots every protected system in an isolated test environment - your entire back office, virtualised from the latest backup, running live. You see what comes up, how long it takes, and any issues before you ever need to recover for real. By the time a real incident happens, your RTO is not a guess. It is a number you have already measured.

How It Works

Automated Periodic Boot Test

Scheduled Test Run

Weekly, nightly, or on-demand

Latest Backup Mounted

Isolated network, no production impact

Every VM Booted

Full back-office environment spun up

Boot Time Recorded

Per-VM and total RTO logged

Report Delivered

Pass / fail + exact times per system

Sample Boot Test Report

DC01 (Active Directory)1m 12s

SQL01 (Database Server)2m 44s

APP01 (Line of Business)3m 08s

FILE01 (File Server)1m 55s

MAIL01 (Mail Server)4m 17s

Total back-office RTO13m 16s

Your RTO is a Measured Fact

When a real incident occurs, you already know your measured RTO - not a guess. Tests run in an isolated environment that never touches production traffic.

Scheduled Automatically

Configure nightly, weekly, or custom schedules. Tests run unattended and report results without administrator intervention.

Fully Isolated

Test VMs run on an isolated internal network. No production traffic, no IP conflicts, no risk of anything leaking into your live environment.

Alerts on Failure

If a VM fails to boot or boots beyond an expected time threshold, an alert fires, giving you time to fix the backup before you need it.

Audit-Ready Reports

Every test generates a timestamped report with per-VM boot times and pass/fail status - ready for compliance audits, insurance requirements, or board presentations.

RTO Estimator

Estimate Your Recovery Time

Configure your server environment and storage pool speed to see an estimate based on the numbers you enter. The boot times and storage figures are assumptions, not measurements. Systems boot in parallel directly from backup data.

Storage Pool Speed1.5 GB/s

300 MB/s (HDD)8 GB/s (NVMe)

Systems to Recover

Domain Controller

AD / DNS - boot first

Database Server

SQL, Postgres, MySQL

Mail / Exchange

Exchange, Zimbra

Application Server

Line-of-business apps

File Server

Windows shares, DFS

Desktop / Workstation

Windows 10/11

Linux Server

Ubuntu, CentOS, Debian

Total systems3 VMs

Estimated Total RTO

3m 25s

3 systems · all booting in parallel

Bandwidth per VM

500 MB/s

Last online

Database

Recovery Timeline - Fastest to Slowest

File Server1m 38sFIRST

Domain Controller1m 46s

Database Server3m 25s

Estimates based on parallel boot from iSCSI-mounted backup with typical OS boot I/O profiles. Actual times depend on VM content, services configured, and network conditions.