Force yearly GFS flag now?

[ConradGoodman]

I created a new backup job to archive a VM before deleting it.

The job was a Backup Copy Job, with archive set to yearly for 7 years, to keep the backup in object storage for 7 years and then automatically purge it.

I created a couple of active fulls with this job, so to have a sealed backup chain.

The yearly backup was due for 1st day of the year (the default).

No archive flags have been set on any of the backups, I guess because we haven't gotten to the right date yet.

I've since deleted the VM and the backup job.

Will Veeam keep the full backup until the 1/1/2022 and then create an archive flag? Or do I need to restore the VM from the current backup, and start another job with the yearly backup date in the next day?

[HannesK]

Hello,
I'm not sure what you really configured. can you maybe post your backup copy job configuration? The two first sentences of your post say the opposite what you have done. A backup job backs up a VM. The backup copy job copies the data from one or multiple backup jobs.

The easiest way to set the archive flag is to schedule the yearly backup for "today". There is no way to make a backup in the past the a GFS restore point. That might be an issue in your scenario (I did not fully understand it to be honest)

You could export your backup and keep it for one year. But only V11 can copy / move exported backup to capacity tier. So you would have to wait until V11 is available (launch event is on 24th February). There you could also set a deletion date: https://helpcenter.veeam.com/docs/backu ... ml?ver=100

Best regards,
Hannes

[ConradGoodman]

Apologies, let me do a better job of explaining.

[Objective]
I have 1 VM that I want to decommission (delete from our infrastructure).

I need to make a one off GFS copy of this VM that will be kept for 7 years.

[Configuration]
The VBR server has 2 repositories, a Local (standard) Repository, and a Copy (Scale-Out) Repository.

I created a job that backs the VM up to the local repository

I created a VM Backup Copy Job that instantly copies the backup to the SOBR. This job has a GFS Archive setting, set ONLY on the yearly flag for 7 years.

Today I restored the backup of the VM to start again, as I had deleted the Backup and Backup Copy jobs.

Today, I have set the yearly backup date to today (2 February).

I started the backup job, which triggered the backup copy job.

I then did another 'Active Full' synchronisation of the copy job, so I have 2 full backups on the SOBR, both on the date that should be a yearly GFS backup, set to 7 yearly backups.

Is my understanding correct, that this should retain the yearly GFS point for 7 years, regardless of the fact I will now delete the VM again and the backup jobs?

If not, what is the best way to achieve this with SOBR/Capacity tier and GFS archive job?

[veremin]

If you check the backup properties, can you see the corresponding GFS mark (Retention: Y) set for the restore point? Thanks!

[ConradGoodman]

No, just 2 x full backups both with the R flag.

I swear I have previously tested this process before implementing veeam in our production environment, hence I'm confused I can't seem to get the flag to appear.

[ConradGoodman]

Could do with some help on this, else will raise it with support on Monday.

[veremin]

You can post here some screenshots of both retention settings and backup properties, may be there is something obvious we're missing. Otherwise, reach support team and let them confirm your environment - the described situation looks unexpected, based on what you've shared so far. Thanks!

[foggy]

Seems like you're expecting a GFS restore point to be set aside immediately, it is not how it works. The regular chain should first reach the simple retention setting and then, after the full backup in the regular chain reaches the date specified for GFS restore point offload, it will be set aside. For your use case, it is better to use either VeeamZIP or backup export functionality and keep the created backup for the required number of years (VeeamZIP allows you to control that automatically).

[ConradGoodman]

@foggy

Don't think that's going to work as I need it exported to the capacity tier, which requires V11.

The date has been reached that I set for it to create a GFS Yearly restore point.

I will revisit this later today and raise with support.

[veremin]

Posting the requested screenshots might allow us to catch some obvious misconfiguration or misunderstanding. But if you decide to utilize support assistance, don't forget to post ticket number for the convenience of future readers. Thanks!

[ConradGoodman]

[ConradGoodman]

As you can see, the copy job executed on 2nd February, and I have done 2 active fulls, so the chain should be good to be marked a yearly.

[veremin]

I think in this case the Foggy's assumption is correct: you have 7 restore points as simple retention, so, you need to wait, until 6 other restore points are created, and the base .vbk is moved forward and marked as yearly GFS restore point.

To confirm this you can temporarily lower simple retention to 2, wait for the next job's run and see whether the yearly label is set to the corresponding restore point correctly.

Thanks!

[ConradGoodman]

Thanks for the help.

I have changed the retention on the copy job to 2.

I did a sync now, but there were no restore points in the source backup job (do I need one?)

I then did an active full, so I now have 4 active fulls in Backups (Copy).

None of them have anything but R in the flags.

[veremin]

With the currently configured settings and GFS creation mode (synthetic), the manually created full backups do not play any role in GFS restore point creation. Just wait, until a backup job does its next real run, after that the GFS restore point should be synthesized automatically. Thanks!

[ConradGoodman]

Thats the issue, the source backup job is not scheduled to run as its a one off to archive this VM

I have kicked it off manually, and will do that a couple of times.

[ConradGoodman]

Still no GFS flag

[foggy]

Keep an eye on the regular full - if it passes the Feb 2d day, it will not be marked as a yearly until the next year.

[Gostev]

This thread makes me so happy about the changes to the Backup Copy GFS retention in v11

[ConradGoodman]

Do we have a release date for that?

@Foggy, the regular full being the full backup of the original backup job?

Bottom line for me is, I have achieved this once before but didn't write down the steps. It's complex and I really need to get this VM in the cloud today...

[veremin]

This is the quote about v11 release date from the latest forum digest:

In other news, we are getting really close to shipping our v11 platform update! Based on the current state, I expect the RTM build to be signed off by our QC team in the next few days – and once that happens, v11 will enter the Early Availability phase. As usual, first thing we will do is share the RTM build with all of our partners, to give them some time to get acquainted with the new versions before they become generally available in a few weeks. And if all goes well, we will also allow all enthusiasts to get the bits through our customer support – more on this when the time comes!

Thanks!

[foggy]

Do we have a release date for that?

We're expecting an RTM build in the next few days.

@Foggy, the regular full being the full backup of the original backup job?

No, I was talking about the one for the backup copy.

[ConradGoodman]

So is there a potential solution for me to move the GFS Yearly date to 10 February, and set the Weekly full to today and run it manually?

[ConradGoodman]

Case opened: Case #04646550

I tried today setting the copy job GFS retention to have a weekly point on a Monday, and did an active full of the VM Backup Job.

This created a weekly flag. But I've done plenty of these active fulls and never had a yearly created.

I'm wondering if the yearly relies on a monthly and weekly before it will even make one?

[foggy]

No, yearly is independent of other tiers, please keep looking into this with the help of our support engineers.

[ConradGoodman]

Thanks foggy, have requested a webex.

[ConradGoodman]

Good morning guys.

So I have upgraded to v11 this morning.

I've exported the backup, from a point on the SOBR. And now have the VeeamZIP backup on both the performance and capacity tier Great feature, thanks guys.

Only one minor disappointment... Our data retention policy is 7 years, I can only set auto-delete to a maximum of 5 years.

[foggy]

That is something we could adjust in the future, I believe.

[ConradGoodman]

Would be nice to have the possibility. Can we do a feature request please foggy

[Egor Yakovlev]

Noted and added to the list for overall VeeamZIP enhancements!
/Thanks!