GFS for primary backup jobs

[JHarman]

+1 for GFS on regular backup jobs here too, I'll still be using copy jobs to a cloud storage system, but for "restore" purposes I'd really like to be able to hold longer full backups on site so I can avoid the extra bandwidth/cloud cost, so cloud is for restoring when my repository goes boom, but we can still recover that server someone deleted a year ago ;o) Failing that an "Archive Copy" job type that lets me copy full backups only to simulate this.

[SHL]

+1 for this request.

Thank you!

[GreenAlpha55]

Hello members!

I wanted to see if there is an update on when this feature will be available? I am anxiously waiting. Hopefully by v10?

[Gostev]

Yes, it should be in v10.

[GreenAlpha55]

Thank you Gostev!

[SHL]

Yes, it should be in v10.

Thank you Gostev for the good news.
But one more question is can current 9.5.4b can upgrade to v10?
And how long will v10 release?
Many of us are waiting this GFS for Primary backup jobs. Thanks again.

[wishr]

Hello SHL,

Yes, it will be possible to upgrade if your subscription is still valid at the time when v10 becomes GA.

As for the ETA, we plan to ship by the end of this year.

Thanks

[DerOest]

Hello there,

I understand that it's way too early to ask for specifics on the feature. But maybe I'm lucky and someone can give some insight:

We're slowly running out of backup storage, so we're approaching the point where we have to buy additional backup storage.
This is mainly due to having to have Primary+GFS copies...

Will the "GFS for Primary Jobs" offer some kind of migration/merging/reconfiguration of previous jobs?
Or will we need to start a completely new Backup Chain with the new feature enabled? (which would again be a second copy due to long retention of the previous GFS)


So yeah... should we buy more storage or plan a party for the release of v10?
Thanks a lot!

[Gostev]

In the current version, GFS is available for Backup Copy jobs only.

However, primary GFS is a feature of primary backup jobs, just as the name implies. And as you know, these are two completely different job types. You cannot somehow reconfigure Backup Copy job to make it a primary backup job, or vice versa.

If I were you, I would just offload those old GFS restore point to tape or cloud, because what are the chances you'd ever need to restore from them? Probably makes no sense to keep them on spinning disk anyway.

Thanks!

[DerOest]

Hello Anton,

sure, currently GFS is a backup-copy - and i understood the new feature as a way to eliminate this copy (because a lot of people store primary+copy on the same storage anyway).

If we can not merge the current GFS into the new primary-GFS, we'll have to keep the old GFS until their expiration (in xx months) while building up the new retention period with the new PrimaryGFS Job.
If the new job had an option to "map to exisiting backup files", we could immediately reuse our existing GFS - and simply throw away the until-now-primary backup job chain, which only contains a few daily backups (but eats 100% space because it needs a full).


As for tape: We keep everything longterm on disk for performance reasons and administrator-time-efficiency - tape costs us too much time for restores (tapes are in another building - retrieve tapes from safe - insert - go to workstation - restore - go to tape-facility to receive tapes again - put into safe again)...
And with forward forever incremental, staying on-disk is cheap.

Here, tape is only used for short-term retention for desaster-recovery/crypto etc.

[Gostev]

If the new job had an option to "map to exisiting backup files", we could immediately reuse our existing GFS

Unfortunately you cannot do that, as even GFS retention itself is different in primary backup jobs (it is now time based, instead of GFS restore point count based). This was another big feedback item on our GFS retention capabilities that we implemented.

Here, tape is only used for short-term retention for desaster-recovery/crypto etc.

Nice!

[ChillyHellion]

I'm glad that this feature is now being considered. I know the original argument against GFS Primary Backup is that is allows inexperienced admins to rely on a single backup repository when the best practice is to make at least one secondary copy; however, this argument never made sense to me because both Backup Copy Jobs and secondary backup repositories are completely optional to begin with. There's nothing preventing an inexperienced admin from forgoing both features and just relying on a primary backup job with a single backup target.

At least with GFS in the primary backup job, an inexperienced admin would be able to rely on more than a few week's worth of backups, while also giving experienced admins more flexibility to implement their backup copies in a way that best suits their environment. All while helping Veeam reach feature parity with other backup solutions that have had GFS primary backup for a while now. I see this as a good move by Veeam and I'm a bit disappointed Veeam has resisted this long.

[wishr]

Hi Kyle,

This feature is not merely considered, but it has already been shipped in v10, which is just around the corner

Thanks!

[wa15]

This is going to save us over 100TB+ of local disk space as data is being duplicated for long-term retention so GFS for primary backup jobs is VERY welcome!

Question: Once we upgrade from V9.5 U4 to V10, will this option be available on existing backup jobs to enable? Or do we need to create new backup jobs to use this feature?

[Shestakov]

The feature is to be available on existing jobs, yes

[wa15]

One more question regarding GFS for Primary Jobs: if a job has its regular retention policy of 30 restore points (incremental), along with weekly synthetic fulls, and I enable a monthly GFS on this job (set to 120 for a monthly backup for 10 years), I assume ONLY the GFS restore points will be offloaded to capacity tier and the synthetic full VBKs will remain on performance-tier correct? Would only make sense, but want to make sure!

[Gostev]

It depends solely on your Capacity Tier offload window setting. If its over 30 days, then yes.

[wa15]

So VBKs that are part of the regular retention chain can indeed get offloaded to the capacity-tier if the capacity tier offload is set to lets say 1 day? Wouldn't that "mess up" the chain of incremental backups that rely on that particular VBK? I guess I thought only "sealed" backups can get offload to capacity-tier, which would be the GFS copies.

[Gostev]

No, it won't mess anything up as only inactive chains are processed by the move policy. But, since you said you do weekly synthetic fulls, you have 3 inactive weekly full chains available in addition to those monthly GFS fulls. So if you set your offload window to 1 day, they will be offloaded too.

[wa15]

Got it, thanks Gostev. So in our case, if I only want monthly GFS to be offloaded, and NOT any of the regular retention point VBKs/VIBs, I will need to set the offload window to 30 or 40 days?

[Gostev]

30 will not address your requirement, it has to be more than 30. You should always keep in mind that "extra" full backup of the oldest incremental chain - the chain which cannot be removed in its entirety until its last increment is still under the retention policy. Which is why with classic incremental backup, the number of restore points on disk fluctuates significantly beyond set number of restore points or days.

40 is a safe bet assuming daily backup, you can go a few days lower but you need to do the math based on your specific schedule. Although frankly speaking, you should not be scientific about this, because there may be things like missed full backups occasionally. So, it's good to have some gap.

[wa15]

That makes sense, thanks. Almost wondering if we should stick to GFS on backup copy jobs in our case then, for the purpose of long-term retention (10 years). It'll all be local traffic and will consume double the disk space, but it'll be more of a defined schedule unlike having GFS on primary backup job.

[Gostev]

Well, Backup Copy jobs retention policy has its own share of issues, so many that we're actually changing it in v11 to be inline with GFS retention in primary job (making it also time-based, as opposed to GFS restore point count based).

"Consuming double the disk space" is the necessary evil regardless of what we're discussing here though, since you have to have a copy of your backups (3-2-1 rule). Backup Copy job only would not be necessary if you also used Capacity Tier copy policy to duplicate backups to object storage, in addition to move policy, but I understand you're not doing that.

[wa15]

Got it, thanks! We'll stick with GFS on primary jobs then I think!