GFS Retention Using Backup Copy Jobs

[BGA-Robert]

Our SOP for retention (weekly, monthly, quarterly & yearly) is to simply schedule additional backup jobs. Reading thru Veeam docs and various forums, this appears to be considered normal for local only backups (not talking about Cloud Connect/Off-Site here). We also just run weekly full backups on the daily incremental, as opposed to reverse incremental or synthetic fulls on forward incrementals. One of the reasons we use this strategy is our repository is on an EMC Data Domain. Data Domains are notorious for being slow to regurgitate data and as such, synthetic operations, that read from the Data Domain, are to be avoided.

But one client wants a somewhat large VM (450GB) backed up over an already over-used, under-provisioned WAN link. So, we're trying synthetic fulls on the nightly backup job, in conjunction with a backup copy job that gives us GFS retention (weekly, monthly, quarterly & yearly). I setup a backup job with forward incrementals and synthetic fulls.

After reading a bunch I still wasn't too clear on the backup copy job.

So, what I did was to set up a backup copy job as a secondary target to the above backup job. I set it to a 1 day interval, starting a few minutes after the source backup job. I set it to two restore points, the minimum.

The 1 day interval was what I was confused about. I mean, I only really need it once a week. But looking at what I was trying to accomplish, the monthly, quarterly and yearly restore points could be generated any day of the week, so my thinking was to let the backup copy job run daily and that would mean the retention restore points could be created on whatever night they happened to fall on.

So far, it seems to be working. I’m about a week in. The synthetic fulls in both the back job and the backup copy job are pretty slow because of the Data Domain, but are much faster that the slow WAN link we’ve been suffering with. The initial full backup ran almost 26 hours. The synthetic full later that week took almost 2 hours. The nightly backup copy job runs between 2 and 5 hours, which is a lot of processing for not really accomplishing anything. Again, I only really need the weekly restore point saved. But the up side is not doing ANY processing over the slow WAN link. Snaps are not being held open for a long time and the bandwidth usage is minimized. Our SOP strategy would have required a weekly full for the nightly job, as well as weekly, monthly, quarterly and yearly backups, all full backups.

On a side note, I had read where the backup copy job cannot read-from and right-to the same repository. Seems like an odd restriction. Anyway, I defined the job using the same repo for both and it took the settings with no warnings or errors. Only when I started the backup copy job did it complain.

I got his at run time:
“8/16/2018 4:38:57 PM :: Restore point is located in Backup Copy target repository and cannot be used as a source”

I spun up a new repo and moved on.

Anyway, I’m not sure if I understood all this correctly. What I didn’t find after a few days of research was a single document that sorta goes thru this strategy start to finish. So, I guessed a little and this is what I came up with.

It seems like Veeam could provide a lot more functionality in this area, like simply incorporating the GFS into the source backup job. I'm not thrilled with the nightly backup copy processing overhead.

Let me know if I’m missing anything.

Thanks,

Robert

[foggy]

Hi Robert, looks like you've set up everything correctly and according to recommendations.

[BGA-Robert]

Thanks for the double-check!