In the last couple posts about Veeam, I mentioned that $Work has been doing backups directly to our offsite storage.  Due to limits on bandwidth, any errors, changes, or server additions can have a drastic impact on our ability to complete backups in a timely manner.  And if you’ve ever tried to do a full backup of a 1.5TB file server over a 10Mbit connection because the VMID changed, you’ll know exactly what kind of pain I’ve felt in the past.

While a backup copy job will eliminate some of this pain, it still needs to be seeded at the remote site. 

I was a little disappointed to learn that an existing backup chain cannot be the target of a backup copy job.  The backup copy job needs to be pointed to a clean full backup that doesn’t include any forward or reverse incremental backups.  I’m not sure what the reason for this is, but it was confirmed in a Veeam in this thread on their support forums.

But there is a workaround to this, and it’s fairly easy.  The process is actually pretty simple.

1. Create a backup copy job.  Use the backup job that currently saves to the remote site or the virtual machine as the source and use a backup repository at the remote site as the destination.
2. Let the Backup Copy job run and create a new full backup of the file.
3. Once the Backup Copy job has successfully completed (see notes below), create a new backup job for those servers and store that backup data at your local/primary site.  You cannot change the target of your existing backup job –  Veeam will require you to copy your existing backup chain to that location.  Its easier, and faster, to just create a new backup job.
4. Edit your Backup Copy job to remove the job that backs up directly to the remote site and add the job that backs up to your primary site.
5. The next time your VMs back up inside the copy window, it will sync the changes from the latest restore point to your remote site.

There are a couple of caveats with this.  You can’t set up a new backup chain at your primary site until you’ve created your backup copy job and created the new full backup file.  If there are more recent restore points available than the ones at your remote storage site, it will eschew the ones at the remote site in favor of the ones at your primary site.  This may mean copying a large amount of data over your WAN.

Second, you need to check to make sure that all of your data has copied over.  A copy job may end succcessfully if the interval expires and it copied some data.  If it hasn’t finished copying all of your data, it will restart and pick up where it left off.  This might give you a false sense of data security by making you think that your offsite backups have fully seeded when you still have to copy large amounts of data over your WAN.  In this case, it would be helpful to have a warning on any job notifications to inform the administrators that the seeding hasn’t completed and that there isn’t a restore point in the remote repository yet.