Ron McKelvey (or ronzo) over at PHD Technologies disclosed a new feature of the esXpress backup software. So far the name is EAR (esXpress Advanced Replication). If you have a better suggestion for naming conventions, they're all EARs ;-) Right now esXpress has Simple Replication which can be defined as automatically restoring backups. The more you backup a VM, the more it can be auto restored. Consider Host A, it backs up to your FTP, all VMs once a day, and some VMs more often. Host B can check that FTP for new backups, then restore them. This is currently a DELTA restore, which means if the VMDK is 40 GB, then a new 40 GB VMDK will be created and the backup restored. Simple Replication is basically just a Mass Restore that runs automatically. They’re now getting ready to release the EAR in Beta format. Right now backups are in a Full/Delta methology. As time goes on, the Delta backups get bigger, because they are based on the Full. An EAR backup is just the incremental block level changes done from the last backup. Whether you are making a FULL or a DELTA, an EAR archive is also extracted with just the incremental changes from the last backup. This EAR archive can be send to another NET target (NET only for now).
In the above example, In the above example, I setup Host B to do EAR restores this time. It will search the FTP, find the backup and restore it. If the VMDK does not exist already on the host, then the DELTA backup will be restored, thus creating the VMDK. Then each replicated restore after that will just need to take the EAR file and drop it on top of the replicated VMDK. Host B has been setup to do EAR restores this time. It will search the FTP, find the backup and restore it. If the VMDK does not exist already on the host, then the DELTA backup will be restored, thus creating the VMDK. Then each replicated restore after that will just need to take the EAR file and drop it on top of the replicated VMDK. If your Host B is across a WAN, this works even better, as only the incremental changes need to ever be sent. You can seed Host B by bring the Delta/Full backups physically over and restoring them. Then when you enable the EAR restores, the .ear archives will be applied one by one, bring it up to date (or not as you configure it).
This means that if you backup VMs more often you can replicate them more often. Because this is basically built into the backup engine, it is just another process, much like FLBs. Every time you backup a VM with Delta or a Full, it will also make an EAR file. If the replication gets badly out of syncs, just the previous Delta need be restored, then the EAR files will flow again. And since the replication is based on Delta and EAR files, it is easy to restore a copy of any VMDK from any point in time. This is just the start, the plan will get more complex. Imagine, Doing monthly Full’s, Weekly Delta, and Daily Incremental’s, if you so choose.
