In this post I want to check out another of my favorite features in Veeam v7. I guess I’m not the only one who wanted this feature so desperately to get a solid remote “copy” of the backup data without scripting and such stuff.
Veeam finally realized this feature with their current release and actually in a really awesome and simple way. Even if it differs from that what most people expect when they think about “backup copy”.
So what do we need to get started?
All we need is to add a new repository, this is actually the exact same process as for primary repository and we all have done that before. As always we are free to choose between all supported typed of backup repositories.
Allow me to skip a complete walkthrough to add a repository, because all you need is a CIFS\NFS share or a Windows machine and proper access rights/login credentials to get that done.
It’s needless to say that this repository should be offsite or a least in a different server room/fire section.
Once the repository has been added we will find it somewhere in our repository list.
Now we are good to go to add a new “Backup Copy” job.
The first step is to select a proper Name & description as well as interval in which the job will check for new restore points. Mare about that in a second, for now it just defines how often data will be copied if there are new data available at the time of the check. Each run will copy the most recent restore point over to the remote repository.
Then we can add all virtual machines which should be protected by coping their backup data to the remote repository.
In this step we can select the remote repository created earlier and the number of restore points to keep at the remote repository. Most of you will be very familiar with that principle because it works the same way as in regular backup jobs.
In addition to that it’s possible to make use of the so called “Grandfather Father Son (GFS)” principle. We can select the number of weekly, monthly, etc. backups we want to keep for archiving purposes, so that these don’t get overwritten over time.
If we want to define which day and time should represent our weekly or monthly backup, we use the “Schedule” button to set these details as we need them for example according to our corporate policies. Veeam will keep the restore point closest to the specified day and time so that they represent our weekly, monthly, etc.
Sorry for the German days in the screenshot, the OS is installed in my native language!
The next step is to select the transport mode Veeam uses for the data transfer. The “Direct” mode by default will copy all new blocks of a restore point and will use as much as bandwidth it can get.
The new Enterprise Plus feature “WAN accelerator” is able to speed up data transfer across slower WAN connections. This mode leverages not only a cache of the paired WAN accelerator nodes, it can also use the complete remote backup repository as “advanced or infinite” cache to verify if a block really needs to be transferred or not.
Anton Gostev explained the WAN acceleration in a deep dive at TFD9 which can be found here:
As last step we can set a time frame in which the job is allowed to copy data. For example we could hold copy jobs during our working hours.
But why I’m always talking about restore points, the feature is backed “backup copy”!?
To answer that lets take a look in the repositories I used in my lab
We can see that they actually have nothing in common.
- The number of restore points / files is differs
- The naming of the backup files is different
Even inside Veeam when I trigger a restore, the number in restore points differs.
So what’s going on here?
The most important fact is that the backup copy doesn’t simply copies files from A to B, it uses its own more intelligent logic.
To be able to combine multiple items within a single job, the files will be named after the name of the job, actually the same principle as we already know from regular backup jobs.
But what about the number of restore points?
The backup copy feature works like an “incremental forever” backup job. So as soon as the job is set up, it will copy the most recent restore point to the remote repository, no matter how much restore points there are already available on the primary repository.
And even if the most recent backup is an incremental backup on the primary repository, the first copy will be a full backup on the remote repository. So in my case the last incremental of my vCenter VM was about 400 MB, the first backup copy resulted in a 38GB full backup .vib file.
From now on every back copy job run will check for new restore points on the primary repository and then transfer those blocks required to represent the according incremental restore point at the remote repository. Even if the most recent restore point is a synthetic or active full, Veeam will only create an incremental at the remote site. Veeam will make use of the complete backup chain at the remote repository to represent the exact same restore point as the full at the primary repository.
Veeam offers a great user guide which depicts step by step how backup files will be transformed once the maximum number of restore points gets exceeded and how in GFS mode the archiving feature respects the need for permanent backup files. I can only recommend to get a copy of the user guide which can be found HERE.
I really love this new feature which had led to this post and I can only recommend using it. Veeam once more proved that they got the magic key to combine good technical solutions with a simple interface in easy way to use.