Veeam v7.0 – My favorites – Backup Copy 4

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.RemoteRepo

Now we are good to go to add a new “Backup Copy” job.

CopyBackup1The 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.

CopyBackup2Then we can add all virtual machines which should be protected by coping their backup data to the remote repository.

CopyBackup3In 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!

CopyBackup5The 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:

CopyBackup6As 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

CopyBackup9 CopyBackup10

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

CopyBackup8Even 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.


My conclusion?

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.

Print Friendly, PDF & Email

Related Post

It's only fair to share...Tweet about this on TwitterShare on LinkedInEmail this to someone

Leave a comment

Your email address will not be published. Required fields are marked *

4 thoughts on “Veeam v7.0 – My favorites – Backup Copy

  • Phil

    The backup copy is great on paper and works well for a few VMs, but you don’t want to use it for a large backup. I back up a cluster follow with a backup copy to a remore location. The remote location is connected at 1 GB so network is not a bottleneck. A full backup is about 4 TB and we are using reverse incrementals; about 300 GB/day. After a few weeks:

    Backup: approx 11 hrs (numerous other backups running on same proxy/repository)
    Backup copy: approx 13 hrs.
    Transform: approx 18 hrs.

    … so a losing game of catch up. It would actually be faster for me to backup directly to teh remote site. One of the biggest design flaws is that the backup copy won’t start till the job is done, even though the copy is on a per VM basis. Throughout the job, my infrastructure is not hurting. CPU, RAM, Disk, Network all good.

    Veeam has some work to do on this.

    • Pete

      I’ve been suspecting the same thing. I’ve used two separate jobs (one with local target, the other with a remote target), and have experimented with a Veeam Backup Copy as a planned replacement for this topology. But I’ve had challenges with it, and based on the forums, I’m not the only one.

      Right now having a separate backup job is not the theoretical most efficient method, but it offers the most consistent, predictable results. Something I need for my offsite backups.

      Great on paper for sure, and I will continue to look forward to the day I can use it. Needs some work before it really offers a competitive advantage to getting another backup offsite.