Feature Request: Retroactive Backup Copies

[ChuckS42]

I've got a situation where I need to create copies of existing backups, and maintain them for awhile separate from the primary job (with different retention). A Backup Copy Job (in Mirroring mode) would be ideal for this, but the Backup Copy Job will only grab the most recent backup, then new ones as they are written. It'd be nice if there were an option to copy previous restore points as well.

[Gostev]

There should be a registry value to enable this behavior... I will check with the devs.

[Gostev]

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Name: BackupCopyMirrorAll
Type: Multi-string value (REG_MULTI_SZ)
Data: Backup Copy job names you want to behave this way.

[Gostev]

Please note that the value must be created before the job runs for the first time.

[ChuckS42]

Wow, great! Thanks!

By any chance is the a KB article or something that lists all the non-standard registry keys for VB&R?

[Gostev]

Those registry values we're willing to share are documented in the user-facing documentation: User Guide, What's New or Release Notes (depending on how common we expect the need to be). This particular one can be found in the v10 Release Notes.

The rest are provided by support, and only if they are reasonably sure it will fix the specific issue, because most come with drawbacks and we don't want customers randomly using them at their discretion, without having full understanding of our architecture. Besides, the more behavior modifiers they will use, the further they will deviate from product setups our QC is testing in their labs.

[ChuckS42]

Thanks.

I've got it working, but I think I'm trying to do something not covered in the manual. What I've got is a chain of backups for a pair of servers that goes back to June, sitting on my regular storage. They won't be expiring any time soon (legal stuffs). My intent is to move this long chain to a different storage location using a Backup Copy Job in Mirroring mode to create a separate chain that I can more easily store long-term. The job is running, and started with the oldest backup and is moving along nicely.

A thing I've noticed is its not copying the original backups as they are; it grabbed the first full from June, and since it's only been copying incrementals. I thought it'd copy the Fulls as it came across them. The job is set with retention set to a high number, and no GFS options. If I were to set a Weekly Full for GFS, will it synthesize one on that day of the week and move on? And is the date for the Weekly full the actual current date, or the date the original backups were created?

Another thought: This thing is writing to a SOBR; it seems it's going to put the whole backup chain on one extent. I'd like to spread it around other extents. The usual way to do that (using ExaGrid) is to stop the job, put the current extent in to Maintenance Mode, then restart the job. With this situation, would that work? That is, would the Backup Copy Job synthesize a new Full on a different extent from the next date available to copy, or would it do something else (like start over from the beginning)?

[ChuckS42]

As for the last bit above, looks like the BCJ is doing what it's supposed to; synthesizing a new Full on a different extent. So that's good.

[Gostev]

It is expected that Backup Copy job synthesizes its own backup chain vs. just copying backup files.

Yes, if you add a GFS schedule to your Backup Copy job, then it will do synthetic fulls, likely on the actual dates. I never encountered your scenario before, so I'm not completely sure to be honest - but I'd be surprised if it "looked at original backups" (sounds like too much extra logic for a scenario hidden behind a registry key).

[ChuckS42]

It's running now with a weekly full configured; we'll see what it does. Thanks!

[ChuckS42]

Yah, it's not creating Weekly Fulls based upon the actual backup chain. I set the job to create one on Sunday, but if its going to do it on the actual Sunday (four days from now) it's not very helpful since its trolling through months' worth of old backups. Oh, well - one Full and a looooooooooong string of Incrementals it is, then. Seems fragile. Maybe this functionality could be enhanced a bit?

[Gostev]

Sure, we will consider it if there are many similar requests.

[igormartini]

Hello.
I have the same problem here. After finished the backup copy, old backups didn't receive the correct retention flag like W,M...
Does it make sense?

[ChuckS42]

Update: After the latest Veeam hotfix, the backup copy job is synthesizing full backups as it should have been. Thanks for fixing!

[foggy]

I have the same problem here. After finished the backup copy, old backups didn't receive the correct retention flag like W,M...
Does it make sense?

Hi Igor, was it the very first backup copy job run? It doesn't assign flags to previously created backups but does this according to the GFS retention algorithm.

[igormartini]

Hey foggy, yes it was the very first time backup copy job run.
Could I have my old backups in the target repository with the correct GFS retention?
If not, do you know if it's in roadmap?
Thanks a lot

[foggy]

No, the copied backups will not have any GFS flags assigned. The backup copy job has its own GFS retention. Currently, we have no plans to change that.

[jveerd1]

Do I understand correctly that the below scenario is expected?

Create regkey -> Create Backup Copy Job (14d, 4w, 12m) -> Backup chain is created with 1 Full backup file and Incremental backup files
Retention on none of the backup files is set after the mirroring of the files.

Backup Copy Job will apply the retention policy to the mirrored Full backup file and the Incremental files, meaning every mirrored backup file is lost after about 14 days on the Backup Copy Job target?