Introduced in v2.6, Alike supports Incremental Restores for all VM backups. When supported, incremental restores can vastly cut the amount of time and data transferred over a network, required for a restore operation.
How it works
An incremental restore will detect and write only the necessary changes required to revert a VM to the specified backup state. When a restore job is run, as long as the "overwrite target" option is specified, Alike will revert the targeted VM to the selected version, instead of performing a full VM restore.
If no pre-existing VM is found, Alike will simply perform a traditional full restore.
The major requirement for this feature is that the target VM for the restore operation be renamed (in XenCenter) with the "-Alike Restore" suffix. So, for example, if you wanted to revert to a previous version of the the VM named "Exchange Server", you would rename that VM in XenCenter to "Exchange Server-Alike Restore" prior to the restore job.
Additionally, the target VM must contain the same number and size disks of the system being restored.
This feature is an optimization for the restore process, and can be used in many ways. For example, the target VM does not have to be the same as the VM being restored. If the VM being restored and the target a similar, Alike can detect all similarities and only write the differences between them. So, for instance, if you had a pool of XenApp servers, and you needed to restore one of them, you could copy an existing XenApp server, rename it, and perform a differential restore.
Please note, Incremental restores will still work even if the source and the target VM are completely different (say, restoring a Linux VM over a Windows target). In this case, a full restore would have been slightly faster, as Alike would not have to attempt to detect any differences, but an incremental restore will work nonetheless.
This feature when combined with a scheduled restore can provide a compelling way to keep a target VM in sync on remote system.