Feature Requests (GFS in NAS Backups)

[martinuy]

Dear all,

We request the possibility of including in future Veeam V11 updates a new functionality to include Backup Copy Jobs for NAS backups With GFS possibility in SOBR. This is because the functionality of protecting deleted files or modified is not possible for us for space issues for a certain time and we need to keep a GFS backup policy weekly (4), Monthly (12), and yearly (5), and add this jobs to Tape backup.

The client that need this functionality is our client AGESIC in Uruguay.

[Dima P.]

Hello Martin,

Can you please elaborate how customer wants to keep the GFS? As a full backup or as a regular nas backup restore point with a longer retention (this would also mean that content from regular restore points will be reused)? Thanks!

[martinuy]

Hi Dmitry, of course.

This client need a "frozen" backup with this retention, a Full Backup with GFS retention, with the same a possibility of generate a Full backup to tape.

Today this client has a Self Service backup with 2000vms, the retention policy of this Self Service is 14 retention points, but this governement agency has a compliance with the client to generate an archiving with GFS policy of all vCloud Director VMs and Veeam Agent backups without include the NAS Backups jobs with a retention of 4 Week (this to restore without need the use of tape because this backup goes to a Storage) 12 Month and 5 years (this is resolved with tape backup job with GFS policy). In the case of NAS backup jobs don't have the possibility of realize this type of backup to a SOBR or tape and with this retention.

Thanks in advance.

[Dima P.]

Hello Martin,

Thank you for sharing, I've added your post to this feature request!

[aschmieg]

I too request this feature

[j-a-m]

Hello
We need the GFS feature (daily, weekly, monthly, yearly) for storage integration with NetApp for a customer too.
No specific requirement if done with full backup or longer retention. Preferably the method that uses least diskspace on backup targets.

[Dima P.]

Hello folks,

I've added all your votes to this feature request. Thank you for sharing your feedback!

[owilcockmearie]

GFS yes! for retention purposes! The other aspect of the requirement that I think should be fleshed out is the Secondary Target aspect.
As I discovered recently (new Veeam user) the "archive" retention feature doesn't replicate to the secondary target and so the long term retention of deleted files that are preserved in the "archive" are not copied by the secondary target/backup copy job.
Instead what I expect is that the backup copy job to the secondary target can be used to recover any of the preserved backup sets that were created by the GFS policy in the case where the primary site burned.
I echo the requirement "the method that uses the least disk space on backup targets". Synthesizing a full backup to go to tape makes sense but the GFS feature should not do this for on disk and repository to repository backup copies.

[Dima P.]

Hello Oliver,

As I discovered recently (new Veeam user) the "archive" retention feature doesn't replicate to the secondary target and so the long term retention of deleted files that are preserved in the "archive" are not copied by the secondary target/backup copy job.

Correct, but in the upcoming v12 we will provide an option to copy the data to archive repository in addition to current option to extend the retention for needed file versions.

Instead what I expect is that the backup copy job to the secondary target can be used to recover any of the preserved backup sets that were created by the GFS policy in the case where the primary site burned.

So whenever restore point is marked as GFS on the primary job, copy job copy such restore point with the GFS 'flag' preserved, is that correct?

I echo the requirement "the method that uses the least disk space on backup targets". Synthesizing a full backup to go to tape makes sense but the GFS feature should not do this for on disk and repository to repository backup copies

In your case GFS restore point in the primary job must be an active full backup, right?

[owilcockmearie]

Dima P.: Correct, but in the upcoming v12 we will provide an option to copy the data to archive repository in addition to current option to extend the retention for needed file versions.

Since the V11 behaviour makes reference to an archive repository the reference to archive repository in this quote confuses me. I think you may mean the secondary target.

Dima P.: So whenever restore point is marked as GFS on the primary job, copy job copy such restore point with the GFS 'flag' preserved, is that correct?

Perhaps. I think what you are describing is that the GFS flag is the mechanism whereby the retention/clean-up process that runs on the repository where there is a copy knows which restore points to keep. I don't know enough about the implementation to answer confidently. I described the expectation from the perspective of someone who is tasked with restoring a file that went missing (but not reported) a long time before a fire destroyed the primary site.

Dima P.: In your case GFS restore point in the primary job must be an active full backup, right?

I don't think so. I meant to support the request by j-a-m of using the least disk space and contradict martinuy, who posted about wanting full backups. I think the present behaviour that preserves File Share restore points does not create "full backups", instead the restore client allows one to select the restore point and then, I think, it synthesizes the state of the source at the time of the backup during the restore operation. Unfortunately I'm not sure of the definitions of the phrases used in this topic nor the underlying implementation mechanics.

When you say "active full backup" I think of the active full backup that occurs for a VM where, it seems, Veeam reads every byte of the source and writes every byte to the target. I suppose it is reasonable for someone to want this (especially for a tape backup), but not me. I have to follow this excessive duplication of data with a file system level dedup (wasteful of resources and probably even riskier than long incremental chains; who knows how long the effective incremental chain becomes when dedup gets involved). I would rather have the GFS retention independent of the need for active full backups and trust to the CBT mechanism and the Veeam File Share version tracking mechanism to identify the files that belong in the restore points flagged for preservation according to the GFS policy. If I was forced to to use an active full backup to get the benefit of GFS and the longest interval was monthly (this seems to be the case for the VM backups), I would choose monthly.

[Dima P.]

Oliver,

Since the V11 behaviour makes reference to an archive repository the reference to archive repository in this quote confuses me. I think you may mean the secondary target.

For v11 you are absolutely correct but I was talking about upcoming v12, where we will support sending a copy of your backup to the archive repository in addition to the archived files with a longer retention.

I described the expectation from the perspective of someone who is tasked with restoring a file that went missing (but not reported) a long time before a fire destroyed the primary site.

Got it, thank you!

When you say "active full backup" I think of the active full backup that occurs for a VM where, it seems, Veeam reads every byte of the source and writes every byte to the target. I suppose it is reasonable for someone to want this (especially for a tape backup), but not me. I have to follow this excessive duplication of data with a file system level dedup (wasteful of resources and probably even riskier than long incremental chains; who knows how long the effective incremental chain becomes when dedup gets involved).

Also noted, thank you for all your feedback!

[stevepogue]

I understand this is not supported yet in V12 GA. We request this feature in V12

[Dima P.]

Hello Steve,

It's not going to be included in v12, however it's already planned for next versions.

[lampshade]

Second this. We are coming from a competitor's product and I am surprised this is not an option for SMB shares. Especially when our retention is 1 year.

[Dima P.]

Thank you for your feedback lampshade. Can you please clarify if you need a full backup for the GFS to be stored aside from the regular day-to-day backups or you want the retention for file versions for the GFS date to be prolonged?

[lampshade]

Dima..

Essentially - for our use case - we just need to retain the backups for a 1 years period as per policy. In the past we just kept a full monthly for 12 months. I guess a full backup aside from regular day-to-day backups stored for 12 months would suffice - isnt this were gfs comes into play?

[mark49808]

+1 for this feature. Same as prior comments. A "point in time" monthly backup of a NAS share would be huge for us.

[Samba222]

+1

... we also need a GFS for NAS Backups - as Full Backup to store it aside from regular (for 2-4 years)

[mark49808]

It's not going to be included in v12, however it's already planned for next versions.

By 'next versions' do you mean v12a or v13? Thanks in advance.

Is there any workaround in the interim that would ideally not consume additional licensed protected shares (VULs)?

[Dima P.]

Hello Mark, it's not planned for 23H2 update, I was referring to next major versions.

Is there any workaround in the interim that would ideally not consume additional licensed protected shares (VULs)?

You can perform backup to tape from NAS backup files and store those tapes for a longer retention, however please note that GFS media pools are still not supported for NAS backups on tape. Secondary jobs such backup to tape does not consume the license.

[mark49808]

Ok thank you for the reply. I was hoping to avoid tapes in the mix here. But I suppose that will have to wait for the next major version.

[s.eichner@vega.com]

+1
We also would have this feature as this would make the fileshare backup interesting.