VM Backup Validation
Alike performs background data validation of every disk backed up, immediately after the job completes. The function of validation is to verify data integrity using cryptographic signatures. When validation is complete, a green check mark appears beside that version in your VM’s list of backups.
If any errors are encountered, Alike will immediately mark all affected VMs with a red X, and send a notification email. You can check on the progress of all commit and validate operations in the dashboard.
When performing the validation, Alike only checks new data from the backup job. The data already stored (and previously validated) can be skipped in order to speed up the validation process. After a designated period of time, Alike will re-validate the data in the ADS, to ensure no disk corruption has occurred after the backup was stored to disk.
The setting to determine the age after which data blocks must be re-checked can be found in the Alike Manager->Settings->Backup Setting page. Lowering this number will cause Alike to re-validate the data much more frequently, at the cost of performance. Conversely, a higher number will cause Alike not to recheck data blocks frequently, so you must be sure your ADS’s underlying storage is stable.
Alike’s Network Footprint
All Alike backup jobs perform source-side, local data deduplication, compression and encryption, sending only the unique, new data over your network directly to your ADS storage. This feature considerably lowers the amount of network traffic required to protect your systems.
Furthermore, once the backup data is transferred to your ADS, Alike will perform a second, global deduplication pass on your data, further reducing your storage.
It is important to understand that the first time you backup or replicate any VM or system, Alike will send the largest amount of data over your network to your ADS share. This happens because it has yet to build any local deduplication information, so it must transfer all unique, non-empty data to your ADS. Once there, the global deduplication process will determine what, if any, of the new data must be retained.
Subsequent backups of any given VM will send a small fraction of the initial backup, though the exact amount will vary based on the change rate of the VM’s data.
Alike’s Impact on Your Environment
Alike can have a very low impact on virtual systems, especially if you install Alike on a dedicated machine rather than running it in a VM on your virtual environment. The computer that the Alike services run on will perform varying amounts of I/Os during and after jobs run; see the section above on VM commit and validate.
For ABD based jobs (XenServer only), the majority of the load placed on the hypervisor by Alike is from the creation and reading of the snapshot data. The exact amount of load this can cause depends on the type of snapshot (Quiesced vs. Enhanced) and the Storage Repository itself.
For snapshot behavior and requirements in XenServer, please refer to the Citrix documentation in CTX122978.
For Q-Hybrid jobs, the snapshotting and processing is performed inside the guest, and all backup load is incurred within that guest VM. No additional demands are placed on the hypervisor system.
Additionally, the deduplication, compression and encryption does take CPU cycles by either the ABD processing the job, or with Q-Hybrid, by the VM being protected. In isolation, a single system processing a backup should not generally consume a significant amount of resources; however, running many jobs simultaneously can cause noticeable load, depending on the infrastructure and number of concurrent jobs.
Please take care to monitor your environment to determine the precise impact and thresholds.
Job Concurrency and Scalability
For XenServer Enhanced jobs, Alike dynamically provisions one ABD for each Enhanced job from the template uploaded to your shared storage. This means that each ABD provisioned does not actually consume any additional storage in your SR to exist, as they all point back to the original base image.
Each ABD can simultaneously process all of the drives of a single VM at once. You may also configure how many VMs to process concurrently within the same job. Alike defaults to 1, but you may set this to whatever value works for your schedule and infrastructure.
For example, if you had 20 VMs to be backed up in a job, and set your concurrency to 5, Alike would begin backing up the first 5 on the list. As VMs complete, Alike will move on to other VMs in the job, maintaining 5 active backups at a time.
Please be aware that each ABD requires 1 IP address to operate. By default, Alike uses DHCP to assign IPs to your ABDs, however you can manually enter as many IP addresses as you like in the Alike Manager->Tools->Manage ABDs. You must have enough IP addresses configured to support the number of concurrent jobs you wish to run. Additionally, the IP addresses assigned to ABDs are grouped by Xen Pool.
Also be advised that the IP addresses assigned to the ABDs must be able to access your ADS CIFS (TCP 445) share directly. The IP address/virtual network that you assign to your ABDs determine which network the backup data will traverse. You may segment you backup traffic by selecting a specific VLAN for your ABDs.
Protecting Your Installation of Alike
If you plan on storing most of your backup data in a dedicated secondary location, consider Alike DR’s Offsite Vaulting product feature, described in Offsite Vaulting section of this guide. This will allow you to perform high speed local backups, and ‘vault’ deduplicated copies of your backups to a secure secondary location that’s ready to go to in the case of a disaster.
If you lose your Alike installation, but your Alike Data Store (ADS) is still intact, you may perform a recovery install in order to rebuild your Alike installation. Alike backs up its active database files from your installation directory to the ADS periodically, so in the event your installation is lost, you will be able to recover your latest backups.