Struggling to implement retention requirement with GFS

[YounesF]

Hello,

We have recently made the decision to implement Veeam, moving away from another backup product. However, I am having a hard time trying to implement our company's retention requirements using GFS.

We have 2 sites (Site1 and Site2) that run production workloads. we have 1 Datadomain in each site.
our requirement is backup all production servers in both sites, and duplicate the backup to the second site.
For example, if I backup server A in site1, I need to also keep a copy of the backup in site2, and vise-versa.
Also, we need to backup daily and keep for 30 days, but the backup of the last Friday of the month needs to be retained for 7 years.

what is the recommended way to do this in Veeam?

Thanks

[DGrinev]

Hey Younes,

The settings below should let you achieve what you're after:
1. Source Backup Job - Daily incremental with Active full every friday, restore points to keep 30.
2. Backup Copy Job - interval Daily; Restore Points to keep: 30; GFS retention: weekly 1, monthly 84 (7 years); schedule: weekly on Friday, monthly on Last Friday of the month, check - Read the entire restore point from source backup...

It requires a lot of free space to retain so much restore points for two sites, you can use RestorePoint simulator to estimate the space needed. Thanks!

[YounesF]

Hi Dmitry,

Thank you for taking the time to answer my question.
The problem I am facing is that with backup copy job I can only chose a different repository (than the source backup) as a destination for the copy.
How do I achieve (with backup copy) the requirement of having 2 copies of the monthly backups (one copy in the primary site, and one copy in the secondary site)?

I've seen in other forums people suggesting having a different logical repository pointing to the same DataDomain, but I'd rather if I didn't do that.

Thanks

[DGrinev]

It's mandatory to use a separate repository for the backup copy job.
You should create the third backup copy job to meet your requirement of having 2 monthly backup copies.
3rd Backup Copy Job - Daily incremental without Active Fulls, Restore points to keep: 2, GFS retention: monthly 84; schedule: monthly on Last Friday of the month, Target: Second repository on the Site 1.
With this approach you will get one more very short backup chain consisting of 2 RPs, that will create another copy of monthly GFS restore points.

Can you elaborate on the requirement, why do you need to retain 2 copies of monthly backups? Thanks!

[sosborne]

I have two sites each with its own backup server. And I found working with backup copy jobs tricky particularly for my retention requirements (daily incremental with weekly full for 4 weeks, a monthly active full for two years and then an annual active full for 7 years). So I ended up using backup copies for my 4 week retention needs and separate 'unscheduled' backup jobs for monthly and yearly retention which are initiated by scheduled tasks from a Veeam power shell script. It maybe convoluted but it not only gave me greater control over retention given my circumstances but also scheduling which can be difficult if wanting to get month/year ends. Offsite jobs I just robocopy offsite at an appropriate time.

[YounesF]

Can you elaborate on the requirement, why do you need to retain 2 copies of monthly backups? Thanks!

Hi Dmitry,

Since we do not use tapes, we need to keep 1 copy onsite, and 1 copy offsite of all our backups. So in case we lose the primary site, we have copies of all our backups in the secondary site.
Initially I thought of using a Backup Job with 30 restore points that will use a Copy job to the second site. This will satisfy my daily incremental requirements. However, for my long retention requirement, we need to have a full backup and also copy that to the second site.
I think I will end up using another backup job with full actives that gets replicated to the secondary site.

[foggy]

Just keep in mind that with two backup jobs you're going to touch production VMs twice, while backup copy uses backups as a source, not affecting actual VMs performance.