GFS Logic and Naming in V11

[MSweetman]

Hi Product Mgt,

We have been a long term MSP user of VBR and are normally quite happy with the product and it's enhancements however, we are concerned on the changes to the GFS logic and naming changes in V11.
We welcome the addition of being able to operate a GFS method in the Backup jobs as well as the Backup Copy jobs however, there seems to be some disconnect in the new logic. Specifically in 2 main areas

1. In a backup job with GFS enabled, the omission of a _W, _M or _Y seems to be a backward step. We are aware that there are now flags in the DB for GFS and are shown in the properties under Retention. A Backup Copy Josb show both W, M and Y in the Retention column of the properties as well as the _W, _M, _Y in the .vbk filename.

2. The second is of major concern, being when the Monthly and Yearly are actually created. You are able to set which day the active or synth Full is created for the Weekly however, the creation
of the Monthly uses the first or last Full. This is not a Monthly as it should be created on the last day of the Month. If the last day of the month coincides with the weekly, then you would have two flags one for W and one for M however the M would override the W. If the last day on the month is not a W, and new active or synth Full should be created and flagged as M.
The same should apply to Yearly backups. If the last day is not a W or M, a new active or synth Full should be created on that day.

Hoping to hear back and potentially the re-instatement of the _W, _M, _Y .vbk and creation of the Monthly and Yearly on the the correct days, i.e last day of the month and last day of the year.

Regards....Mark

[HannesK]

Hello,

1. I got lost here... what is "_W" vs "W"? Before V11, there was no GFS for backup jobs at all. Or are you saying, that we changed the filename format for backup copy jobs (if yes, do you maybe have an example or a screenshot?)?

2.

You are able to set which day the active or synth Full is created for the Weekly however,

in the GFS settings, you can select which full should be taken if there are multiple fulls within one week

This is not a Monthly as it should be created on the last day of the Month

different customers have different opinions on that from a space savings perspective. But yes, agree, that feature got lost compared to V10 backup copy job. It's something we consider to bring back in future (not V12)

Best regards,
Hannes

[MSweetman]

Hi Hannes,

Thanks for the response.
I hope this clarifies my comments.

In reference to the GFS Naming conventions...
If you look at the properties of a BU Copy job under Backups > Disk (Copy), the Files panel shows the file name with a xxxxxx_W.vbk under the Name column and a W under the Retention column.
Same applies to the Monthly and Yearly .vbk files. (This naming convention has not changed)

If you look at the properties of a BU job under Backups > Disk , the Files panel shows the file name with a xxxxxx.vbk under the Name column and a W under the Retention column.
Same applies to the Monthly and Yearly .vbk files (GFS was added for BU jobs in V11)

So there is an inconsistency between the naming conventions of BU and BU Copy jobs which have GFS enabled.

In reference to the GFS Logic...
The Configure GFS screen allows you to select how many weekly full to keep and you select which day to create it.
The main concern is that the Monthly setting allows you to select how many full backups to keep however, you have to use the Weekly full from the follow week of a month - either First or Last. This is not the normal backup convention. The monthly should occur on the last day of the month.
The same applies to the Yearly setting. The Yearly setting allows you to select how many full backups to keep however, you have to use the monthly full from the following month - (have to select a Month) Again, this is not the normal backup convention. The yearly should occur on the last day of the month that you select or last day of the year.

Being forced to use the weekly full (first or last) for the monthly and in turn the monthly full for the yearly is not the norm.

Regards...Mark

[HannesK]

Hello,

So there is an inconsistency between the naming conventions of BU and BU Copy jobs which have GFS enabled.

do you maybe have a support case number for that? Because it's different in my environment. Below is a screenshot of a V11 backup copy job and I cannot find _W anywhere



For the GFS logic: I already agreed on your view. The idea of taking las / first weekly for monthly backups was saving disk space for customers. As mentioned before, we consider bringing "x day of the month" back after V12

Best regards,
Hannes

[david.domask]

I think I can answer this actually; v11 did change the naming schema because the file naming was done via rename (GFS points start their lives as normal restore points and used to get renamed), and that can't happen on an immutable repository once the item is immutable. I would need to double-check in a v10 lab but I think the Synthetic full process made the full first, then GFS calculations were ran but I might be off on this.

I realize it's not as convenient as just looking at the backup file name (for example, via scripting), but you can get the GFS period from the Storage object in Powershell.

$backup = Get-VBRBackup -Name 'your backup'
$storages = $backup.GetAllChildrenStorages()

Then check the object properties and you'll see the GFS periodicity there. I think if you're doing scripts, even though it's a small bit of extra logic, it saves a lot of string validating glitches for your scripts. Maybe there's another use case though that you're using for the old naming schema?

For the inconsistency, are you maybe seeing older points that had the text added? I'm fairly certain that on the next full it should drop the _[gfs period] and look like HannesK's screenshot.

[MSweetman]

Hi Hannes and David...

I have opened case 05458925 and documented with screenshots to clarify my points.

Thank you....Mark

[david.domask]

Thanks for sharing -- regarding the naming, it's much as you suspect, and for right now I'm not aware of plans to return it (But maybe you can share your use case?).

For the timing, if possible can you please export logs for one of the backup copies with the unusual behavior following https://veeam.com/kb1832. Use the first radio option and select the Backup Copy Job so we for sure get the correct logs.

We can check the GFS calculations pretty quickly and understand the logic.