billed monthly, in advance
| Scope | Full system backup, physical Windows and Linux servers |
|---|---|
| Applications | SQL Server · Oracle · MySQL · Exchange · SharePoint, backed up 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, to keep backup windows short |
| Encryption | AES-256 at rest and in transit |
| Bare-metal recovery | Yes |
| Restore unit | One file · one database · the entire server |
| Billing unit | Per server, per month |
The server and everything running on it
Physical Windows and Linux servers in full and, critically, the applications that make them worth protecting. SQL Server, Oracle, MySQL, Exchange, and SharePoint are handled application-aware, which means the backup coordinates with the database engine rather than photographing its files mid-write.
The difference presents itself exactly once, at the worst possible moment. A database captured mid-transaction restores into a state its engine never intended, and you discover whether it opens on the morning you most need it to. An application-aware restore point returns consistent because it was taken consistently.
How it runs
Full system backup with selection and schedule under your control, written to two destinations: an optional vault on your own premises, and the encrypted cloud vault. Each server carries 2,000 GB of pooled cloud storage, drawn from a fleet-wide pool rather than a per-machine cap requiring supervision.
Transfers are change-tracked, so backup windows stay short enough to run aggressively rather than nightly and hopefully. Short windows are not a convenience feature. They are your recovery point objective, expressed in engineering terms.
Backups that outlive the domain
AES-256 at rest and in transit, with the cloud copy isolated from your Active Directory. Intrusions against Windows estates follow a well-worn order of operations: acquire domain administrator, inventory the backup targets, destroy them, and only then encrypt what remains. Every copy the domain can authenticate to, including the NAS, the second server, and the share the backup service writes into, is removed in that first sweep.
A vault your domain cannot authenticate to is a vault that sequence cannot touch. Every restore point is verified, and a failed job reaches an on-call engineer, so the copy is not merely unreachable by an intruder. It is known-good for you.
Getting it back
- A single file or folder: the routine case, completed in minutes with no downtime.
- A database: restored consistent to the chosen point and ready to mount, rather than restored in hope.
- The entire server, bare metal: onto replacement hardware when the original is gone, destroyed, or held as evidence.
Where this line stops
This line covers one physical server. Virtual servers are priced separately on Virtual Machine: the same capability against a different unit. Note also what a backup is not. It is not high availability. If your tolerance for downtime is measured in minutes rather than hours, pair this with clustering and add Recovery Testing so the recovery time you are relying on is a measurement rather than an assumption.