Backup Copy Job Retention Question

[justdoit_]

Hello!

My question is around the use of a Backup Copy Job for keeping offsite backups.
What I am looking for is the following:

I want to keep 4 weeks of retention on an offsite appliance and have it look like this:

Week 1: Initial Full (Saturday) + 5 Incrementals (Monday - Friday)
Week 2: Synthetic Full (Saturday) + 5 Incrementals (Monday - Friday)
Week 3: Synthetic Full (Saturday) + 5 Incrementals (Monday - Friday)
Week 4: Synthetic Full (Saturday) + 5 Incrementals (Monday - Friday)

The thought here is that as time progressed, week 4 would become week 1 and it would continue like forward like this.
The configuration we have tried is 7 Restore Points and 4 Weekly backup restore points for archival purposes.

Is this possible? How would I set up the Restore points and archival restore points?

Thank you for reading.

[foggy]

Backup copy jobs do not have synthetic fulls. Such retention is possible with regular backup jobs. With backup copy you can do it with active fulls ("Read the entire restore point from source..." check box) or have 30 restore points in the incremental chain starting from the first full and 4 weekly GFS fulls set aside for archival purposes (separate from the incremental chain).

[justdoit_]

Thank you for the reply.

So the target backup copy job screen would look like this:

Restore points to keep: 7
Check the box to Keep the following restore points for archival purposes
Set Weekly backup to 4
Check the box to Read the entire restore point from source backup instead of synthesizing it from increments

This will keep the offsite backup copy job looking like my initial post?
What we are trying to accomplish is have 4 weeks of offsite backups that have a shorter block chain.
For example, if we wanted to restore from Wednesday on Week 2, we would need the Week 2 full + only the incrementals up to Wednesday, which would result in a very short block chain.

Thank you again for your reply.

[veremin]

Restore points to keep: 7

Everything looks good besides the quoted setting. If you want to keep increments in between those full backups, you will need to set this option to 28. Thanks.

[foggy]

Just keep in mind, that entire VM data will be copied from source site to create weekly full.

[justdoit_]

Restore points to keep: 7
Everything looks good besides the quoted setting. If you want to keep increments in between those full backups, you will need to set this option to 28. Thanks.

Thank you for the reply.
Does this mean that my block chain will go back 28 days?

What we are trying to accomplish is have 4 weeks of offsite backups that have a shorter block chain.
For example, if we wanted to restore from Wednesday on Week 2, we would need the Week 2 full + only the incrementals up to Wednesday, which would result in a very short block chain.

[foggy]

When backup copy active fulls are enabled, it behaves just like regular forward incremental job, so you will see the behavior you're requiring.

[justdoit_]

So we would leave the restore points at 7, and not adjust them to 28, correct?

[foggy]

No, to achieve 28 restore points on disk, you need to set it to 28. This way you will have 4 weekly fulls with increments in-between.

[justdoit_]

Ok, so from a block chain perspective:

Week 1: Full (1) + Incrementals (2-7)
Week 2: Full (8) + Incrementals (9-14)
Week 3: Full(15) + Incrementals (16-21)
Week 4: Full(22) + Incrementals (23-28)

So, if we wanted to do a restore from Week 3, Wednesday, assuming that the Full's are on Sunday, we would need:
The Week 3 Full (block chain 15) + Monday, Tuesday, Wednesday incrementals (block chain 16, 17, 18)

Correct? We would not have to read from block chain 1 all the way through block chain 18?

[foggy]

Correct.

[justdoit_]

Sorry for the back and forth, but we sure that is the case? From this document:
https://helpcenter.veeam.com/backup/vsp ... cycle.html

Step 5 states:
The primary full backup file remains on the target backup repository. Veeam Backup & Replication sets it aside and marks it as a weekly full backup. The weekly backup is no longer used in the backup chain.

This is stating that it removes the weekly backup from the chain, so if we needed a restore like the example above it would have to pull from block chain 1 up until block chain 18? Or am I misunderstanding?

[foggy]

This is the case for synthetic fulls, however doesn't apply to active fulls. I will let documentation team know so that they update the page, thanks.

[justdoit_]

So I just had a call with the VVEEAM Integration Team around this.

Backup Copy Job was not designed to do what we want it to do.
It is not meant to take Daily Incrementals for a long period of time. It was meant to keep Weekly/Monthly/Quarterly/Annually for long periods.

What we want to do is not possible.
The solution that they provided me with is to create two Backup Jobs, one replicating to each set of storage (Onsite/Offsite) or have the existing one Backup Job and replicate it at the storage level.

[veremin]

Backup Copy Job was not designed to do what we want it to do. It is not meant to take Daily Incrementals for a long period of time. It was meant to keep Weekly/Monthly/Quarterly/Annually for long periods.

That is not true. Otherwise it wouldn't be possible to specify daily synchronization interval for backup copy job. And by no means can you consider 28 days to be a long period of time.

What we've recommended in this thread should work fine and without any issues.

Thanks.

[foggy]

Looks like you was given an incorrect answer, either due to some misunderstanding or lack of knowledge. I'd appreciate you sharing your case ID, so we could pay support management attention to it.

[justdoit_]

Ok, I would love the Backup Copy Job to do what we want it to do. We are just being told it is not possible.

We are using this with an HP StoreOnce appliance.
How it was explained is that the limitation of this hardware tie-in with VEEAEM is that it has a maximum of 14 Restore Points with a backup copy job due to the hardware's file structure limitations.

Also, if we were to do a 28 day Restore Point the block chain would not reset with the Full Weekly's as we had been discussing above.
Instead, if would be continuous incremental's and if we wanted to restore from Week 2, on a Wednesday we would need to start at the initial Week 1 full and then proceed through all of the incrementals up until the specific day. This will cause for long restore times and is not a recommended setup according to the VEEAM Integration Specialist.

[foggy]

StoreOnce indeed has some limitations in terms of the number of concurrently open connections to the storage, however, this doesn't apply if you enable active fulls in the backup copy job, since, as it was stated above a couple of times already, in this case it is doing simple forward incremental backups, where each active full resets the backup chain.

What is your support case ID?

[justdoit_]

Foggy I PM'd it to you.

[foggy]

Thanks. There're not much details in the case notes, most likely everything was discussed on the call. Anyway, I suggest you to try the settings described in this thread and see whether they allow you to meet your requirements.

[justdoit_]

It looks like to use Active Full for Backup Copy it is a manual process. How can it be automated?

[foggy]

Active fulls can be done manually and be automated with the help of PowerShell. However, selecting the "Read the entire restore point from source..." check box essentially enables automatic active fulls on the days you specify in the job settings.

[justdoit_]

It looks like we are facing an issue with the hardware then. I am unable to bump the Restore Points of the Backup Copy Job above 7.
So it is possible to do within VEEAM, where we set up the backup copy job as we had discussed, but due to the hardware limitations of the storage, we cannot set the restore point long enough.

[foggy]

Provided you have Veeam B&R v9 Update 2, you should be able to set above 7 with active fulls enabled. What version are you currently at?

[justdoit_]

We are at version 9.0.0.1491.

[foggy]

Please update to the latest available build.

[justdoit_]

Hello,

For anyone else wondering or having the same problem, the configuration settings advised in this thread meet the requirements that were outlined.
We were able to test and validate that using the settings.

Thanks guys, you were very helpful and your input was much appreciated.