We use cookies on our website to ensure we provide you with the best experience on our website. By using our website, you agree to the use of cookies for analytics and personalized content.This website uses cookies. More Information
It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda Backup

How to Manage Cloud LiveBoot Virtual Machines

  • Last updated on

This article refers to the Barracuda Backup firmware version 6.3.04 and higher, and supported versions of VMWare and Microsoft Hyper-V.

Cloud LiveBoot is available to all Barracuda Backup customers with Instant Replacement and a Cloud storage subscription, and is available to all customers excluding those in Japan.

Barracuda Cloud LiveBoot supports a maximum of four virtual disks per guest virtual machine.

The Restore > Cloud LiveBoot page displays details about each added virtual machine as described in Table 1.

Table 1. Cloud LiveBoot Table.

Column Description
VM Name

Hyper-V VMs:

  • VM name
  • Hard disk size used
  • Expiration date

VMware VMs:

  • VM name
  • Actual hard disk size
  • Expiration date

Displays the VM status:

  • Running
  • Not Running
  • Stopped
  • Failed
  • Configuring
Revision Click to select the desired backup revision to restore.
VNC Displays the VNC Information details necessary to connect to the VM.
Interface Type

Displays the selected interface option:

  • Internal (default) – Private VM
  • External – Displays the VM public IP address and password

Displays the available actions based on the VM status:

  • Stop
  • Start
  • Restart
  • Download
  • Destroy
  • Delete


Cloud LiveBoot a Virtual Machine

Use the following steps to Cloud LiveBoot a VM:

  1. Log in to the Barracuda Backup web interface, and go to the Restore > Cloud LiveBoot page.
  2. The Revision column displays the latest revision. Click the date picker to display the Revision History calendar selector. If there are multiple revisions, you can pick a specific revision from which to boot.
  3. Click Done. The Revision column displays the selected revision. When a user selects to boot the VM, the selected revision boots.

Connect to your Cloud LiveBooted Virtual Machine

Use a Virtual Network Computing (VNC) client to connect directly to a Cloud LiveBooted VM:

  1. Log in to Barracuda Backup, and go to Restore > Cloud LiveBoot.
  2. In the VNC column for the VM, the VNC Information details display.
  3. Open a VNC client, for example, TightVNC, and enter the VNC Information in the Remote Host field:
  4. Click Connect. You should now be connected to your Cloud LiveBooted VM:

Manage Cloud LiveBooted Virtual Machines

Use the options in the Actions column of the Cloud LiveBoot table to manage your Cloud LiveBooted VMs:

  • Stop – Click to pause the VM
  • Restart – Click to restart the VM
  • Destroy – Once you shut down a VM, click Destroy to permanently delete all changes made since the VM was started
  • Download – Click to download the VM as a VHD or VHDX file to your local system
  • Start – Click to start a new Cloud LiveBoot instance
  • Delete – Click to delete the VM from Cloud LiveBoot

Change the Virtual Machine Private IP Address to a Public IP Address

  1. Log in to Barracuda Backup, and go to Restore > Cloud LiveBoot.
  2. In the Actions column, click Stop.
  3. In the Interface Type field, click Edit, and then click External and make note of the Public IP Address and Default Gateway fields (you will need these values in a later step).
  4. In the Actions column, click Start.
  5. Open the VNC client again, and connect to the virtual machine:
  6. Log in to the virtual machine, and open TCP/IPv4 Properties:
  7. Enter the Public IP address values from Step 3 in to the associated fields; You can use public DNS server values such as and

    You may need a subnet calculator to calculate the subnet mask.


  8. Click OK to apply your settings. Open a web browser and confirm that you can connect to the Internet.

Two Cloud LiveBooted VMs can communicate with each other provided they are both on the same account. Note that each account is assigned a VLAN. The same is true if the VMs have a public IP address.

Last updated on