Using VirtualBoot

VirtualBoot boots a system volume backup image into a Virtual Machine (VM) environment without performing a restore operation or converting backup files to a different format. By leveraging the open source Oracle VirtualBox software, VIrtualBoot provides a quick, temporary replacement system for a failed server.

VirtualBoot provides an innovative solution to the following situations:

System Fail-over: Restoring a failed system with terabytes of storage using traditional methods can take days. A VirtualBoot replacement can take minutes and gives users full access to system resources and applications after only a brief downtime to cut-over to the new system.

Backup Test: Few administrators perform backup and restore tests using traditional methods. VirtualBoot can mount any backup image in a VM for testing to make sure a restored system would function properly.

Access Application-specific Data: While backing up data is a critical operation, sometimes the data files alone aren't useful without their associated applications. VirtualBoot can mount an entire system, both applications and data, in a VM where you have access to data within its associated application.

For information about VirtualBoot usage scenarios, see VirtualBoot Scenarios.

This section includes the following topics:

Note: DeveloperNotes_VirtualBoot.txt contains developer-level information related to VirtualBoot. You can find this file in the <install_folder>\StorageCraft\ShadowProtect\ folder. This file gives troubleshooting and advanced technical details for using VirtualBoot.

Warning: If you want to preserve any changes made to a VM created with VirtualBoot, do not select Restore current snapshot VirtualBoot as a shutdown option. This causes VirtualBox to discard all new data written in the VM since its creation. Select this option only if you want to revert the VM back to its original state.

Also, ShadowProtect and SPX pause existing local and ShadowControl policy-based backup jobs when run on a VM launched through VirtualBoot. This prevents mixing backup files from the source system with those of the VM if the source is still active on the same network. (Launching a VM of a still active system might occur when testing VirtualBoot or when testing backup files from the existing system.)

Do not unpause these backup jobs then unless the source system is no longer on the same network. Mixing backups corrupts the chain and prevents a valid restore later on.

Terms and Conditions of Use - Privacy Policy - Cookies