Disclaimer: I do not have any information about the innovations that will be introduced in the next version of Veeam Backup & Replication, this post is entirely the result of my assumptions.
No, this time I am not going to talk about a new feature in Veeam; the name “VeeaMover” was born during the last Veeam User Group held last December in Milan.
Talking to some users of Veeam Backup & Replication, one of the limitations recognized by many was the inability to send the backup file at the same time to two different destinations.
From this discussion, I tried to derive a small description of how I think this need could be solved in an elegant way, integrating it directly into the product instead of relying on an external replication software as of today.
VeeaMover would become the 4th component of the modular solution adopted by Veeam with the release of VBR 6, in addition to console, proxy and repository. Ideally it could be installed on the same server that acts as a repository, but like the other modules its position could be determined.
Its function would be to read the backup files from a repository and replicate them to one or more remote repositories (or network shares). A range of options would regulate how this replication would work. A preliminary list of options that should ideally have would be:
– Send to multiple remote repositories simultaneously (hub and spoke)
– Select the level of compression
– Management of bandwidth consumption and time in which not to work
– Management of a different retention from the original repository (for example, retain 180 days of backup while the primary repository retains 30)
– Ability to create backups excluded from retention as historical points
– Ability to encrypt backups stored remotely (in my opinion this is much more important than to be able to encrypt local backups, that if encrypted would require more time during restores)
Why Veeam would offer this solution instead of relying on a third party software? For two main reasons in my opinion: first, the management of the schedules. Veeam server already has very good ability to handle job cuncurrency and their concatenation. A “Mover Job” could be linked to a backup job, and make checks on bandwidth consumption that are already in place and act accordingly.
But the main reason that from the beginning led me to think about this component, would be the possibility of using Reverse Incremental backup type even in “critical” situations like remote replicas. This type of backup is by far the most efficient way to save disk space and at the same time provide instant restore and faster recovery. But the fact that the last backup file is constantly updated and changed at every execution creates problems with replication software, they see this file as if it was entirely new. A replication system directly integrated with Veeam would instead identify which blocks have been updated from the previous execution of the backup (Veeam was responsible at first for these writes!) and replicate only those blocks. Just like in the proxy, you would expect to have a couple of Movers where the local one would send only changed blocks, and the remote one would be responsible of re-assemble those blocks in a reverse incremental chain.
If anyone from Veeam is reading, think about it! 🙂