From the deleted file to the machine that no longer boots

A backup that runs is only a hypothesis. Until it has been restored, you know neither whether the data comes back, nor whether it is usable, nor how long the operation really takes on the infrastructure concerned.

That is why restoring is not treated here as an appendix, but as the main function. The four levels below match situations that every operator eventually meets.

Everything is driven from the browser

Files, disks and virtual machines: the whole restore is conducted from the server's web interface, without logging on to the workstation. For a service provider, that changes the nature of the intervention: restoring a file at a client's site is handled from your own desk, with no remote session and no travel.

The same interface exposes around sixty commands on the agents — start or stop a backup, follow progress, list the VSS components and the ESXi VMs, export the file list, restart the machine. See the multi-client console

Retention that follows reality

Silent corruption or slow-spreading ransomware may only be detected weeks after the event. The depth of history therefore matters as much as the frequency of backups.

• A simple rolling history, for the cases where the rule has to stay readable.
• Advanced tiered retention: minimum number of versions, last backup of the day, of the week, of the month, of the year.
• Deletion of an intermediate version without breaking the chain: the versions before and after remain restorable.