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!
