Skip to main content
  • EN

One of the biggest mysteries of Veeam’s list of features in my opinion is the Backup Copy Job. On the surface, they’re easy to understand – you create a Copy Job, use some supported backup source, and copy this source VM data to a designated target to implement part of the 3-2-1(-1-0) Rule – have multiple copies of your data and/or at least 1 offsite copy of your data. Easy, right? Well, when you look under the hood of the technology behind the retention, scheduling, interval, etc. things start to get murky pretty quick, at least for me. The most difficult to understand about Copy Jobs in my opinion is how the retention algorithm works when using the GFS (grandfather-father-son) archive option. And with the changes brought to Copy Jobs with the release of Veeam v11, I believe things got worse instead of better. As such, I thought it would be beneficial to the Veeam Community for me to go through the Backup Copy process from a deep-dive perspective, and see if I can make a bit more clearer sense, for myself and the Community, of how Backup Copy Jobs retention works. I will tackle this topic in a “3-part” series of posts – Part I Intro, Part II Short-Term Retention, and Part III Long-Term (GFS) Retention.

 

In this Part I post, I thought it would be best to share explicitly what Veeam states Copy Jobs are, then move on to their requirements, as well as some considerations and limitations. This will give us a foundation from which to begin our retention discussion in subsequent posts.

 

WHAT ARE COPY JOBS?

From the Veeam User Guide, a Backup Copy Job allows you the ability to create several instances of your backup data in different locations, whether onsite or offsite, for long-term storage, to help you meet the 3-2-1 Rule

 

REQUIREMENTS / LIMITATIONS

Sources:

– Instead of listing all the sources you can create a Backup Copy job from (see full list here), I will list jobs for which a Backup Copy job cannot be created:

  • Immediate Copy Mode – you cannot create a Copy Job from any Veeam Agent for Windows, Linux, or MAC sources in Standalone Mode when using Immediate Copy Mode. The Agent Jobs have to be in Managed Mode (managed by the VBR Server). Other Veeam Agents – Nutanix AHV, Oracle Solaris, AWS, & Azure – are not suppported in Immedicate Copy Mode
  • Periodic Copy Mode – does not support sources which use Enterprise Plug-Ins such as: Oracle RMAN, SAP HANA, and SAP on Oracle
  • Other Backup Copy Jobs – I know I said I would share what isn’t supported, but this option can be a bit confusing, so I will discuss it here. The short answer is YES, using other Backup Copy Jobs is supported, but there is no explicit option to select them when adding your source objects. To use other Copy Jobs as a source for a new Copy Job, you have to do so indirectly by adding the source Copy Job Repository. Click the Add button > Repository option when using Immediate Mode; or in Periodic Mode, click the Source button. Then choose the Repo the source Copy Job you want to use resides on

 

Task Behavior:

  • If the Backup Copy job is utilizing the source Backup job chain for a Copy task, and the source Backup job starts a task, the Copy job task will be put on hold until the source Backup job releases from its chain
  • Copy job Interval setting is only allowed when using Periodic Copy Mode
  • Active Fulls vs Synthetic Fulls – Synthetic is the default and Active is only available for Periodic Mode & recommended when using dedup appliances for Copy job target Repos

 

Limitations:

  • Because of logic differences between the two, you cannot change between Immediate and Periodic Copy Modes
  • Immediate Copy Mode only allows copying Transaction Logs; Periodic Copy Mode is not supported (see below):
     
     
  • Veeam does not copy incomplete source restore points
  • Veeam does not copy source restore points if the data block size differs from the block size of the data already copied. To be able to do so, you would need to create an Active Full, then perform the copy
  • If you’re using a target Repo for the Copy Job which uses rotated drives, you’re not able to use GFS retention
  • GFS Fulls cannot be merged or deleted by Short-Term Retention; Short-Term (Regular; ‘R’) Fulls can be
  • When using Periodic Copy Mode, if the configured interval for the Copy Job isn’t long enough to create an Active Full, the interval will be prolonged until it’s completed
  • When using Deleted Items Retention, this feature only applies to Short-Term Retention, not GFS Retention. Also, when data is deleted, space is not freed up in the Repo; instead, it is marked as available to be used for overwriting of subsequent Copy Job runs. If using Per-VM, the space is not marked as available but instead just deletes the single VM data
  • Periodic Copy Mode Interval behavior – if the interval is not configured long enough – e.g. is configured for only 1 day – and the full source Backup chain needed to retrieve for the Copy Job is for longer than the configured interval (e.g. 1 week’s worth), Veeam will not be able to Copy those restore points because they fall out of the interval’s search scope

 

Whew! That sure is a lot of “gotchas” to know about with regards to setting up and configuring your Copy Jobs, isn’t it? See what I mean by ‘Copy Jobs being murkey’? And, I didn’t even cover all of the requirements/limitations. But I did share most of them and the above are the most important for our purpose of moving on to Part II and Part III.

 

If you have any questions about any of the above, don’t hesitate to comment below.

 

Cheers!

 

Want to copy all restore points to a backup-hardened repository, but only one restore point is being copied. the primary backup has 10 restore points but the hardened backup copy repo only has one. We choose "All" when running the Sync option.Running in immediate mode.

My setting for the source job is not using use-per machine but the target repo is using per-machine 

Any thoughts?

Check this link for an explanation as to why only one file is there as the copy job is creating it during the process - https://helpcenter.veeam.com/docs/backup/vsphere/backup_copying_process.html?ver=120

 

Thanks Chris. I read that article but need some clarification.The source backup job tuns every day and create restore points, so as per immediate mode these restore points should be copied right? Also my understanding was that both repo should be same mode , correct me if I am wrong

If you read the link it indicates how it creates the file. You should do per VM on both repos as it makes things easier.

If you read the link it indicates how it creates the file. You should do per VM on both repos as it makes things easier.

Thanks, so I need to change per VM on source job repo side, need to upgrade backup chain as well ?

If you read the link it indicates how it creates the file. You should do per VM on both repos as it makes things easier.

Thanks, so I need to change per VM on source job repo side, need to upgrade backup chain as well ?

Yeah you should upgrade the chain too.

It’s cool that this has become a recently active topic again as Veeam has made changing mode of a backup copy job possible now:

https://helpcenter.veeam.com/docs/backup/vsphere/backup_copy_modes.html?ver=120#changing-backup-copy-modes

If you read the link it indicates how it creates the file. You should do per VM on both repos as it makes things easier.

Thanks, so I need to change per VM on source job repo side, need to upgrade backup chain as well ?

Yeah you should upgrade the chain too.

My bcj is running now with per-vm and the source job is not per-vm , I don't have much space to go for per-vm on source. Bcj is getting restore points but having per-vm backup files. I just want to know if going with this approach cause any issues if incase this bcj is used for restores.

If you read the link it indicates how it creates the file. You should do per VM on both repos as it makes things easier.

Thanks, so I need to change per VM on source job repo side, need to upgrade backup chain as well ?

Yeah you should upgrade the chain too.

My bcj is running now with per-vm and the source job is not per-vm , I don't have much space to go for per-vm on source. Bcj is getting restore points but having per-vm backup files. I just want to know if going with this approach cause any issues if incase this bcj is used for restores.

There will not be issues with the BCJ for restores as it has the data from the source job.  I would test a restore if you are in doubt once the copy finishes to ensure.

If you read the link it indicates how it creates the file. You should do per VM on both repos as it makes things easier.

Thanks, so I need to change per VM on source job repo side, need to upgrade backup chain as well ?

Yeah you should upgrade the chain too.

My bcj is running now with per-vm and the source job is not per-vm , I don't have much space to go for per-vm on source. Bcj is getting restore points but having per-vm backup files. I just want to know if going with this approach cause any issues if incase this bcj is used for restores.

There will not be issues with the BCJ for restores as it has the data from the source job.  I would test a restore if you are in doubt once the copy finishes to ensure.

Thanks Chris 

Comment


Terms & Conditions