VirtualBoot

SPX VirtualBoot lets you easily create server and workstation virtual machines from ShadowProtect backup files. 

VirtualBoot works on three hypervisors:

You can VirtualBoot a system-volume backup image created with ShadowProtect SPX in a Virtual Machine (VM) environment on these hypervisors. VirtualBoot does not require a restore operation to a VM or converting backup files to a different format. 

VirtualBoot provides a quick, temporary replacement system for a failed server in these situations:

System Fail-over

A failed system with terabytes of storage can take days to restore using traditional methods. VirtualBoot for the same system (backed up with ShadowProtect) takes only minutes and gives users full access to system resources and applications. Cut-over to the new system with VirtualBoot can significantly reduce downtime.

Backup and Restore Test

Administrators in the past seldom performed restore tests due to the limitations of traditional methods such as tape. Now you can quickly do a backup and restore test in a VM by VirtualBooting any system image that was backed up with ShadowProtect. The restore test gives added confidence that a real restore using the same image files will be successful. Administrator's can configure VirtualBoot operations at regular intervals in conjunction with ImageManager's Advanced Verification.

Access Application-specific Data

Backing up and restoring data is a critical operation, but the data files often aren't useful without their associated applications. VirtualBoot mounts an entire system, both applications and data in a VM. This allows you to access your data from its associated application.  

For information about VirtualBoot usage scenarios, see VirtualBoot Scenarios.

Important: To prevent mixing backup files from the source system with those of the VirtualBooted VM, ShadowProtect SPX pauses existing local and ShadowControl policy-based backup jobs when run on a VM launched through VirtualBoot. 

Do not unpause these backup jobs if the source system (system down) is still on the same network as the VirtualBooted VM. Mixing incremental backups from two sources in the same chain adversely affects future restore operations.

Terms and Conditions of Use - Privacy Policy - Cookies