billed monthly, in advance
| Scope | Full system backup of Windows and Linux virtual servers |
|---|---|
| Applications | SQL Server · Oracle · MySQL · Exchange · SharePoint, application-aware |
| Destinations | Two: optional local vault and the encrypted cloud vault |
| Storage | 2,000 GB cloud storage, pooled |
| Schedule | Fully customizable selection and cadence |
| Transfer | Change-tracked: each pass carries the delta, never a fresh full image |
| Encryption | AES-256 at rest and in transit |
| Bare-metal recovery | Yes, including onto replacement infrastructure |
| Restore unit | One file · one database · the whole guest |
| Billing unit | Per virtual machine, per month |
Inside the guest, where the data is
Windows and Linux virtual servers, protected from inside the guest, with the same application-aware handling for SQL Server, Oracle, MySQL, Exchange, and SharePoint as their physical counterparts. A virtualized domain controller, file server, or line-of-business database receives a restore point that returns consistent.
Virtualization changed where servers live. It did not change what happens when the data inside one is deleted, corrupted, or encrypted. The hypervisor will faithfully run a ruined guest all day long.
How it runs
Scheduled full-system backup to an optional local vault and the encrypted cloud vault, with 2,000 GB of pooled cloud storage per virtual machine. Virtual disks churn, because a busy guest rewrites a great many blocks that mean nothing, so change tracking carries the load and each day's protection remains a small delta rather than a full image dragged nightly across your uplink.
A hypervisor breach ends at the vault door
Identical posture to physical servers: AES-256 end to end, with cloud copies held outside your hypervisor management plane and outside your domain. This matters more in virtual estates than in physical ones, because the blast radius is larger. Whoever holds the hypervisor holds every guest on it, and every snapshot stored beside them.
Snapshots on the host are an operational convenience, not a backup. Whoever holds the hypervisor holds every guest running on it, but not a history kept on a platform their credentials cannot open.
Getting it back
Restore individual files, restore a database consistent to a point in time, or stand an entire guest back up on replacement infrastructure once the original host is no longer available. Recovery does not depend on the hypervisor that was running the virtual machine when it failed, which is the entire reason for taking the backup from inside the guest.
Where this line stops
Billing is per protected virtual machine, so a host running twelve guests you care about is twelve lines rather than one. Guests you are content to rebuild from configuration management need no line at all. Physical hardware belongs on Physical Server.