It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda MSP Knowledge Base

VMware Standard and VMware Quickspin Considerations and Recomendations

  • Last updated on

Applicable Products

These instructions apply to the following products:

  • Barracuda Intronis Backup - MSP

VMware Standard and VMware Quickspin Backups

Barracuda Networks offers a native VMware backup solution as part of the Barracuda MSP ECHOplatform that protects virtual machines using the same, centrally managed platform you use to back up all the rest of your data. Both Standard and QS require a VMware Essentials license or higher.

By managing VMware Standard and VMware QuickSpin services alongside other backup services in the central Barracuda Partner Portal, you can provide real-time client assessments for review and resolution.

With VMware QuickSpin, VMware data can be quickly restored from local storage without the need for an on-site visit or extra software.

General Considerations

VMware Standard backup and VMware QuickSpin replication are both different pieces of a complete data protection strategy for VMware environments. Both can be used in your environment to provide multiple levels of protection.

Standard provides offsite, secure, and fewer backups.

VMware QuickSpin provides onsite, rapid failover, and frequent replication. VMware QuickSpin backups can be set to run every 15 minutes, and a default 96 revisions provides 24 hours of recoverable data.

Depending on customer needs, both can be used to provide coverage and redundancy in virtual machine protection.

Use Standard when:

  • You would like to save a full image copy of your VMs offsite in case of a disaster.
  • You are in a single-host environment.
  • Data encryption (both in the cloud and locally) is a requirement.
  • The customer is sensitive to recovery time objective (RTO) and has standby hardware.
  • You are backing up locally and off-site (off-site only is fine if using VMware QuickSpin) for DR scenarios.

Use VMware QuickSpin when:

  • You have multiple hosts (you have a second host to be used for recovery VMs).
  • You have tighter recovery point objective (RPO) requirements and need to back up your VMs more frequently.
  • You need to have your VMs running and accessible quickly after VM or host failure locally.
  • Partners cannot afford high availability because of the hardware or software expense. The expense of a VMware QuickSpin server is far less than for a high-availability server.
  • The server is running in a VMware environment and partners have multiple available hosts. Optionally, use the system state plugin locally to protect against application failure / administration error.
Recommended Number of VMware VMs to Back Up on a Single Host

Although any number of VMs can be selected for back up on a single host, the system resources of the host and the total number of VMs should be taken into consideration when choosing backup worker settings and creating backup sets.

Backup sets with large number of VMs take longer to back up, especially if the VMs’ data changes frequently. Schedule your backups accordingly.

You can choose how many VMs are backed up at the same time by modifying the Concurrent Workers for VMware setting on the System Settings page.

Recommend_1.png

The default value for VMware is three workers; which means three VMs are backed up at a time. If the VMware host has adequate available resources (RAM and CPU), this value can be increased to back up to five VMs at the same time thereby improving backup speed.

Performance may degrade if backing up multiple VMs at once. Hosts with more robust specifications may be able to back up more VMs simultaneously.

Specific Restrictions and Recommendations

You cannot select the VM:

  • On which the current agent is running.
  • That is already part of another backup set. The names for these VMs are grayed out.

If running on 4.1 or 5.0, the VM can be selected but a warning is displayed letting the user know the prerequisites for this VM is backing up successfully:

  • The Universally Unique Identifier (UUID) attribute must be enabled.
  • The VM must use only SCSI disks.
  • The VM must not use any dynamic disks.

Do not choose a drive/volume/disk within a VM as a Local Vault location because if the VM goes down, all your local-only data could be gone, which defeats the purpose of the Local Vault.

If you try to back up a VM that no longer exists, the system displays an error message. This error must be resolved by editing the backup set. During the Backup Select step, a list of VMs that were selected for back up that no longer exist are displayed to let you know they must be removed from the backup set.

If you restore a VM and a new VM is created as a result, that VM is not automatically selected for back up. You must add this VM to a valid backup set after the restore is successful.

When creating a VM backup set consider the following information.

  • Use a separate Backup Agent for VMs.
  • Do not use the Agent being used for File, Exchange, SQL backups.
  • The first time you create a backup set, you must manually enter the IP address of the server (ESX host or vCenter) that hosts the VMs.

Recommend_2.png

  • If you enter a host IP that is managed by a vCenter, a message is displayed indicating that the vCenter is added.
  • When adding a server, you must authenticate to the server. If the server is a vCenter using Active Directory (AD) credentials, the agent’s credentials are used first. If AD credentials do not work, then you must enter credentials to the vCenter.
  • Select any number of VMs under the selected server.
  • Select VMs from multiple servers in the same backup set. A folder cannot be backed up, but can be accessed to select multiple VMs. All selected and children-selected states are displayed.