Review this page to decide how you can configure your system to support backup and recovery operations most efficiently while meeting organizational objectives.
-
Tiers Based on Service Level Agreements (SLAs)
-
Data Recovery
-
Sizing, Performance, and Load Balancing
-
Scheduling
-
Related Topics
Tiers Based on Service Level Agreements (SLAs)
Different virtual machines (VMs) can have different backup and recovery options that are defined in a service level agreement (SLA) for each class of VM. For example:
-
High transaction VMs that provide customer application support, with multiple daily backups and the requirement to recover virtual machines quickly.
-
User VMs that require recovery of files and folders on a daily basis.
-
Development and test VMs that require weekly backups or the ability to recover to predefined states.
To manage different SLAs, you can create a separate subclient for each class of VM. Each subclient can have its own storage policy, backup schedule, and recovery options.
Data Recovery
The frequency and granularity of backups should be based on your requirements for data recovery. Consider the following guidelines:
-
If you will only recover full VMs, you can increase the speed of backups by disabling metadata collection during backups.
-
To determine your backup frequency policy, determine how much data your organization can acceptably lose in the event of a virtual machine failure.
For example, if your policy allows no more than one hour of work to be lost in the event of a virtual machine failure, hourly backups are required.
-
For disaster recovery, you can deploy a copy of a virtual machine that is frequently updated based on incremental backups.
Sizing, Performance, and Load Balancing
There are no explicit limits on the size of backups, number of virtual machines, or size of virtual machines that can be backed up, but you must ensure sufficient storage.
Note
In addition to space on the library, the storage repository where virtual machines reside must contain sufficient space to hold temporary snapshot files used for the backup. The required space can be equal to the sum of the sizes of all VMs that are backed up simultaneously; for example, if a 100 GB VM and a 200 GB VM are being backed up at the same time, up to 300 GB space is required on the storage repository. This temporary space is released when the backup is complete and the snapshot is deleted.
The following factors can affect backup performance:
-
Size and type of backup: More data means longer backups. The size and number of virtual machine disks affects backup time, and full VM backups take longer than incremental backups. Best practice is to monitor backup operations against operational windows to ensure that virtual machines are backed up within expected times.
-
Network speed and traffic: Backups are faster on high-speed networks and during times when network traffic is low.
-
Application activity: To lessen the impact of backup operations on applications running on VMs on the same XenServer, perform backups when host usage is lower.
-
Number of Virtual Server Agent proxies: Add multiple proxies to a XenServer to back up multiple VMs in parallel. However, limit the number of additional proxies to reduce the performance impact on the host.
-
Number of backup streams: Although you can define multiple streams to run backups and restores in parallel and improve the data transfer rate, only one data read stream is supported for each disk. For more information, see Streams - Overview.
A Xen VM can have up to 16 Virtual Disk Images (VDIs) attached. For large environments, you can improve backup performance by configuring multiple proxies and less than 16 streams for backups.
Scheduling
Create backup schedules for subclients to ensure that backups are performed at regular intervals. To balance full VM protection against the need for more frequent backups, you can schedule regular full backups and more frequent incremental backups between full backups. You can recover full VMs and files and folders from full or incremental backups.
When possible, schedule backups for different subclients at different times to avoid competition for resources, and schedule large backup operations during times when the network is less congested.