# XCP-ng ## Backup Strategies ### XVA-based In this strategy, the VM is exported as a single XVA bundle containing all of the data. Incremental backup is also supported. Data is transferred directly from the XenServer API without the need to set up anything on the hosts. ![](https://content.gitbook.com/content/0FWMFN0y1yUTAd3cSRaK/blobs/LDOa0H74OISxaskj564G/protecting_ve-virtual_machines-xcp-ng-xva.png) #### Backup Process * crash-consistent snapshot using hypervisor's API only for full backups * optionally quiesced snapshot can be done if enabled and guest tools installed inside - if the quiesced snapshot has been failed we are doing regular one * optional application consistency using pre/post snapshot command execution * data export directly from the hypervisor using hypervisor's API - both full (XVA) and delta (VHD for each disk) * full backup (XVA) contains metadata * snapshot taken with full backup is kept on the hypervisor for the next incremental backup - if at least one schedule assigned to the VM has backup type set to incremental * incremental backups are cumulative (all data since last full backup) * restore recreates VM from XVA, and then applies changes from each incremental backup using Hypervisor APIs ### Changed-Block Tracking In this strategy, the VM is exported using XenServer API (full backup) and the Network Block Device service (NBD, incremental backups) on the XenServer hosts. The CBT feature in Citrix XenServer 7.3+ may require an additional license. The resulting backup has separate files for each disk + metadata, so you also have the option to exclude specific drives. {% hint style="info" %} **Note:** For full backups only you can still use this strategy without CBT enabled on the hypervisor. {% endhint %} ![](https://content.gitbook.com/content/0FWMFN0y1yUTAd3cSRaK/blobs/izGh0Y2nmmfbclrgMGwA/protecting_ve-virtual_machines-xcp-ng-cbt.png) #### Backup Process * crash-consistent snapshot using hypervisor's API * optionally quiesced snapshot can be done if enabled and guest tools installed inside - if the quiesced snapshot has been failed we are doing regular one * optional application consistency using pre/post snapshot command execution * CBT enabled during full backup on each disk if it wasn't done earlier * metadata exported from API * full backup - each disk exported from API (RAW format) * incremental backup - each disk queried for changed blocks and which are exported over NBD * the last snapshot is kept on the hypervisor for the next incremental backup - if at least one schedule assigned to the VM has a backup type set to incremental * restore recreates VM from metadata using API and imports merged chain of data for each disk using API ## Change Block Tracking setup Citrix introduced the CBT mechanism in XenServer 7.3. In order to enable CBT backups, the following requirements must be met: 1. Citrix Hypervisor 7.3 (XCP-ng 7.4) or above must be used - note that CBT is a licensed feature 2. The NBD server must be enabled on the hypervisor 3. The NBD client and NBD module must be installed on Storware Backup & Recovery Node (Storware Backup & Recovery should take care of this automatically during installation) ### Notes on restore 1. When image-based backups (XVA) are used - Storware Backup & Recovery restore VMs as templates and renames them appropriately after the restore 2. When separate disk backups are used: * if there is already a VM in the infrastructure with the UUID of the VM being restored (check `present` flag in VM list) - Storware Backup & Recovery restore it as a new VM (MAC addresses will be generated) * otherwise Storware Backup & Recovery attempts to restore the original configuration including MAC addresses ### NBD Server setup (on XenServer) 1. Get the Network UUID that you intend to use for communication with Storware Backup & Recovery - run on the XenServer shell: ``` [root@xenserver-cbt ~]# xe network-list uuid ( RO) : e16b4e34-47d4-9a6e-371b-65beb7252d69 name-label ( RW): Pool-wide network associated with eth0 name-description ( RW): bridge ( RO): xenbr0 .......... uuid ( RO) : 244a2fa7-ae7c-e45c-819a-44cecf51e8fa name-label ( RW): Host internal management network name-description ( RW): Network on which guests will be assigned a private link-local IP address which can be used to talk XenAPI bridge ( RO): xenapi ``` For example: `e16b4e34-47d4-9a6e-371b-65beb7252d69` 2. Enable the NBD service on your hypervisor: ``` xe network-param-add param-name=purpose param-key=nbd uuid= ``` ### NBD Client setup (on Storware Backup & Recovery Node) {% hint style="info" %} **Note:** This part is done by Storware Backup & Recovery automatically during installation. The article may be helpful in case of problems with the NBD module. {% endhint %} Storware Backup & Recovery comes with a pre-built RPM and modules for CentOS 7 distribution. 1. Go to the NBD directory: ``` cd /opt/vprotect/scripts/nbd ``` 2. Use `yum` to install the NBD client: ``` yum -y install nbd-3.16.1-1.el7.centos.x86_64.rpm ``` 3. If your Linux does not have the NBD module installed you may try to build one yourself (there is a script for Red Hat based distributions that downloads the kernel, enables the NBD module, and builds it) or use the already provided module: * you can compile the module by running: ``` ./compile_nbd_module.sh ``` * if you have Centos 7, you also may use the pre-built module (for CentOS 7.4.1708 with kernel 3.10.0-693.5.2) - which is `nbd.ko` 4. Enable the module by invoking the script (the following command will either use a module in your kernel or copy the provided `nbd.ko`): ``` ./enable_nbd.sh ``` 5. Verify that you have `/dev/nbd*` devices available on your Storware Backup & Recovery node host: ``` [root@localhost nbd]# ls /dev/nbd* /dev/nbd0 /dev/nbd1 /dev/nbd10 /dev/nbd11 /dev/nbd12 /dev/nbd13 /dev/nbd14 /dev/nbd15 /dev/nbd2 /dev/nbd3 /dev/nbd4 /dev/nbd5 /dev/nbd6 /dev/nbd7 /dev/nbd8 /dev/nbd9 ``` 6. Restart your Storware Backup & Recovery Node: ``` systemctl restart vprotect-node ``` ## Supported features **Supported backup strategies:** Single image (XVA), CBT (preferred)
Single image (XVA)CBT
Supported versions8.1, 8.2, 8.38.1, 8.2, 8.3
The last snapshot is kept on the hypervisor for incremental backupsYesYes
Access to hypervisor OS requiredNoYes
Proxy VM requiredNoNo
Single image (XVA)CBT
Full backupSupportedSupported
Incremental backupSupported *Supported (with CBT)
Synthetic backupsNot supported **Supported
File-level restoreNot supportedSupported
VM disk exclusionNot supportedSupported
Quiesced snapshotsSupportedSupported
Snapshots managementSupportedSupported
Pre/post command executionSupportedSupported
Access to VM disk backup over iSCSINot supportedSupported
VM name-based policy assignmentSupportedSupported
VM tag-based policy assignmentSupportedSupported
Power-on VM after restoreSupportedSupported
*\* Not supported when using a synthetic backup destination* *\*\** A synthetic backup destination can be used, but this strategy only supports full backups ## Limitations * VM migration between clusters is not supported. * Cloning VM to another cluster is not supported. ## Supported features **Supported backup strategies:** Single image (XVA), CBT (preferred)
Single image (XVA)CBT
Supported versions6.5, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 8.0, 8.1, 8.2, 8.36.5, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 8.0, 8.1, 8.2, 8.3
The last snapshot is kept on the hypervisor for incremental backupsYesYes
Access to hypervisor OS requiredNoYes
Proxy VM requiredNoNo
Single image (XVA)CBT
Full backupSupportedSupported
Incremental backupSupported *Supported **
RestoreSupportedSupported
File-level restoreNot supportedSupported
VM disk exclusionNot supportedSupported
Quiesced snapshotsSupportedSupported
Snapshots managementSupportedSupported
Pre/post command executionSupportedSupported
Access to VM disk backup over iSCSINot supportedSupported
VM name-based policy assignmentSupportedSupported
VM tag-based policy assignmentSupportedSupported
Power-on VM after restoreSupportedSupported
*\* Not supported when using a synthetic backup destination* *\*\* Requires XenServer 7.3 or higher* ## Network requirements ### Single image (XVA-based) | Source | Destination | Ports | Description | | ------ | ----------- | ------- | ------------------------------------------------------------------------------------------------------------------------- | | Node | Hypervisor | 443/tcp | API access (for data transfer management IP is used, unless `transfer NIC` parameter is configured in hypervisor details) | ### Changed-Block Tracking | Source | Destination | Ports | Description | | ------ | ----------- | --------- | ------------------------------------------------------------------------------------------------------------------------- | | Node | Hypervisor | 443/tcp | API access (for data transfer management IP is used, unless `transfer NIC` parameter is configured in hypervisor details) | | Node | Hypervisor | 10809/tcp | NBD access (data transfer IP is returned by hypervisor) |