Veeam V8 - will it support GFS strategy for Tape Jobs

[joerg.hermanns]

Hi everyone

not sure if this already has been answered, but is GFS strategy a feature for the upcoming V8 Version?
Then i do not have to ask my question about GFS "howto" with V7

Thanks
Joerg

[Gostev]

Hi Joerg, there is a chance, but not clear yet. It's one of the last features scheduled for the implementation, so it may or may not make it. Thanks!

[joerg.hermanns]

Then let me ask the basic question in that case.
One of our customer wants to achieve the following ..

1) Equipment attached to the Veeam Server

- FC SAS Storage for first instance backups (12 TB)
- iSCSI SATA Storage for long-term archiving (around 30TB, with deduplication maybe even more)
- Tape loader LTO5 / LTO6 with two drives

2) Goal

- Backup daily to FC Storage, retention 28 generations (15 for some less critical servers)
- Archive backups to SATA Storage with GFS (4 Weeks / 12 Months / 10 Years retention)
- Weekly "full" backups to tape (but only NEW full backups) -> GFS for tape ...

But: It must be possible with as less effort as possible to "rebuild" the SATA Storage from the tape backups if that storage crashes.
Is this a "common" situation ?
I am thinking around what might be the best solution / settings for that?

Thanks for any thoughts on this!

Regards
Joerg

[veremin]

Hi, Joerg,

Currently, tape GFS can be implemented by creating separate tape jobs pointed to different media pool. You can find more information here.

Thanks.

[joerg.hermanns]

Hi, Joerg,

Currently, tape GFS can be implemented by creating separate tape jobs pointed to different media pool. You can find more information here.

Thanks.

I already did find that entry - but how "easy" is it then to restore the ENTIRE disk-repository from tape?
As far as i did understand, the tape-database (of course) only keeps track of vm-backups (lets say metdadata) when i do a VM-to-Tape job and not a Files-to-Tape-job?
So how can we then find out, which tapes are needed to restore the repository to the latest versions?

[tsightler]

As far as i did understand, the tape-database (of course) only keeps track of vm-backups (lets say metdadata) when i do a VM-to-Tape job and not a Files-to-Tape-job?
So how can we then find out, which tapes are needed to restore the repository to the latest versions?

That's actually not a true statement. There are two types of tape jobs, Backups-to-Tape and Files-to-Tape. Backups-to-Tape allow you to select Backup Job or entire repositories that should be sent to tape and tracks VMs on the tapes as well, however, this still also tracks the individual files. If you do a "Backups-to-Tape" job you can navigate to the Backups...Tape node and select a backup and a VM to restore. However, in the case that you lost your repository and you wanted to repopulate it, you'd need to Files tab and then drill to the repository to restore the files. I'm not saying this would be super easy, but it would be possible.

Of course, this is assuming you could actually do a "Backups-to-Tape" job from a Backup Copy, which you can't with V7. To actually accomplish this today would require the use of a Files-to-tape, but even then it would be difficult to meet your requirement of only ever sending full backups to tape once and being able to easily restore.

My suggestion would probably be to write a Powershell that copies only the most recent full backup to tape.

[joerg.hermanns]

The fact that i cannot copy from a "Backup copy" to tape is excactly the problem i think ...
But is my wish so uncommon?

But one more question (because i actually cannot try myself):
If all files in the repository (lets say from a "copy files" job which sources from a "backup copy" job) are then visible in the "Files" area....
Wouldnt it then be possible to just right-click the directory-node of the repository and by thus restore ALL files saved in the Veeam-Database?
Of course - we would have to make sure that all tapes needed are then available ...

Hope you understand?

Thanks for your help and time!

[tsightler]

The fact that i cannot copy from a "Backup copy" to tape is excactly the problem i think ...
But is my wish so uncommon?

Not so uncommon I don't think, and I believe that this limitation is being addressed in V8.

If all files in the repository (lets say from a "copy files" job which sources from a "backup copy" job) are then visible in the "Files" area....
Wouldnt it then be possible to just right-click the directory-node of the repository and by thus restore ALL files saved in the Veeam-Database?
Of course - we would have to make sure that all tapes needed are then available ...

If you did a regular full backup, yes, but you asked specifically about only sending the most recent VBK to disk, which is really more of an incremental backup of the repository. In that scenario I believe that the directory would show every VBK that was ever backed up from that directory rather than the current state of the directory, the latter being what you would actually want.

[joerg.hermanns]

If you did a regular full backup, yes, but you asked specifically about only sending the most recent VBK to disk, which is really more of an incremental backup of the repository. In that scenario I believe that the directory would show every VBK that was ever backed up from that directory rather than the current state of the directory, the latter being what you would actually want.

I think we then have to live with that ...
There would be one really "cool" thing, which (i think) would be easy (?) to handle - regarding the GFS schema handling with "backup copy" jobs.
If Veeam would make a SUBDIRECTORY for each GFS schema - then it would be WAY easier to identify what actually would be needed to be restored from tape:

(basedirectory) only has the "latest" restore-points
WEEKLY has all backups generated by the weekly retention
MONTHLY has all backups generatey be the monthly retention
... and so on ...

By this i could restore
WEEKLY, MONTHLY and YEARLY and would not care about all those additional backup-files in the (basdirectory) as those still would reside on my primary SAS storage (or if they are older and had been processed already by GFS handling - they are not needed any longer)

@VEEAM - please take this as feature request.
Even if NOT backing up to tape i still think the features would come very handy and would make structure a bit more clear!