v9 GFS Media Pool & Tape Job

[UT2015]

I opened a case (ID# 01876213) and the support team can confirm that the GFS job should retry 3 times but they actually don't know why it didn't.

Just as expected...it took already 3 Messages (=more than 2 days) which in my opinion contained all relevant information, but the support does not know anything more...

[veremin]

Got it. I've asked our QA team to take a look at the mentioned ticket. Will update the topic once I have more information. Thanks.

[veremin]

We've contacted your support engineer and now are going to investigate the said issue more closely. Thanks.

[veremin]

Ok, the issue has been analyzed thoroughly and below is the summary of our investigation:

- Under normal circumstances a GFS tape job should be retried after encountering an error
- Your conditions differ from the so-called circumstances, because your GFS job finished one day after the date that is scheduled for GFS restore point creation
- As the result the GFS job was not retried
- During its next cycle the GFS job will archive the missing data that has not been copied previously
- The described problem is addressed in 9.5

Thanks.

[nickl99]

Just going to jump in on this one. I upgraded to v9 U1 today and was quite disappointed to find out that using a GFS media pool will not resolve my issues as it causes a new issue.

I am very surprised to see that you do not support incremental to tape with the GFS media pool. This is a very common scenario. Almost every place I have ever worked kept Incremental backups offsite for 7 days, Weekly for 1 Month and then Monthly for some longer term and yearly for even longer. In my case Monthly for 3 years and Yearly forever.

It makes absolutely no sense to not keep daily incremental backups offsite for at least 7 days. If I send my Full offsite on Saturday and have a catastrophic failure on Tuesday where I lose my production and backup data I will lose 3 days of data when I restore from tape. I understand this is an extremely rare scenario but it is one that we in IT always plan for and for the life of me I can't understand why you all wouldn't implement it here.

Using the current solution of multiple media pools for various retention is a complete pain in the backside.
First off you have to have a media pool for every retention period so 4 in my case.
Then you have multiply that with a media pool for each tape drive because they aren't smart enough to load balance across drives. I have 4 drives. So that means 16 Media Pools to manage in my case.
If you have multiple jobs using the same pool they all have to wait in line for the pool to be unlocked. What that fixed in v9? If I could simply have 1 media pool for each retention and the jobs could just use whatever free drives are available without locking the pool that would reduce management a bit. (EDIT) After doing some reading and playing around I answered my own question here. Parallel Processing for Tape drives is now available but not for GFS Media Pools. https://helpcenter.veeam.com/backup/hyp ... ssing.html (END EDIT)
Then to make things worse the backup jobs only allow you to choose Daily and Weekly pools so every month I have to edit 140+ jobs and change them from weekly to monthly pools. Then after that weekend I move them all back to Weekly pools.
It really is a lot to have to manage when this could be resolved by simply adding daily backups to the GFS rotation.

Yes I also dont understand why the GFS media pool doesnt allow parallel processing: it is the reason i WANT parallel processing. I have 2 drives in my loader and my GFS media pool is for the biggest job, but whilst this takes up tape drive 1, i want the non-GFS pools to parallel process when 2 tape jobs are running. Right now it waits until GFS media pool is finished before it can finally use 2 drives at once for the remaining non-GFS jobs.

WRT to incremental GFS: I'm trying to think through how\ or why maybe it isnt possible. And i think hit has something to do with the way Veeam handles Snapshots of changed blocks, and stores these as vbk fulls and vbi incrementals. Adding in a last step of incremental to tape fragments the chain of backups SO much that you will lose that nice Grandfather full tape having clean synthetics. But I know comvault manages it and at this stage it is looking as the main stand out feature comvault has over Veeam. Otherwise Veeam handles GFS in a way that I dont understand but their smarts does. So i just set it up and say GO, and it will do all the thinking/organising for me, and the tapes coming back you know then you can safely scratch and mark them as free, and any pool can now use.

Also for those having problems getting their Tape GFS job to kick off 24 hours after the last backup copy job or synthetics is created: have you tried just delaying your first GFS tape job for an extra week and letting Veeam build a weeks worth of nicely chained disk copies, at both repositories (doing the 3-2) before it kicks off the 1-out to tape. There is just a bit too much going on in the space of a few days for their smarts to happily write out a recent synthetic that has no job locks on them.

[nickl99]

Question:

Why cant you include backup copy jobs as a source in GFS tape jobs? I have (before I read that you shouldnt) and it seems to be working ok?

[nickl99]

Also, if Veeam doesnt support GFS Incremental backups, why in the Tape job using a GFS target does it show you the Full vs. Incremental current size expectation?

screenshot on pc

[veremin]

Why cant you include backup copy jobs as a source in GFS tape jobs? I have (before I read that you shouldnt) and it seems to be working ok?

Actually, you can. Did you experience any particular issues while doing that?

Also, if Veeam doesnt support GFS Incremental backups, why in the Tape job using a GFS target does it show you the Full vs. Incremental current size expectation?

Seems like information label has been taken from normal media pool wizard as is. We'll remove it, so, thanks for raising that.

[nickl99]

Actually, you can. Did you experience any issues while doing that?

Its mentioned in the help guide that you 'cant'. See below. Just wondering if this should rather read "shouldnt", because it certainly lets you, but maybe there is some reasoning behind to recommend it as 'best practice'.

First note here:

"Do not use backup copy jobs with the GFS retention to create a GFS tape archive. The tape job do not archive the GFS restore points from disk."

[veremin]

Previously (v9 GA) there have been few issues with backup to tape job and GFS backup to tape job processing backup copy job that has GFS retention scheme enabled. Thus, we've added the said note.

Nowadays you can use backup copy job (with or without GFS retention) as a source for both a backup to tape and GFS backup to tape jobs without any issues.

Thanks.

[leithm]

So my understanding is correct..

the 24hr gfs window is based upon the source backup execution time not the backup finish time.. so the source backups need to run after midnight if we want a GFS job to process them that day ?


This appears to be what is happening. Can you please simplify GFS and make it just grab the latest restore point regardless? I would like more flexibility around scheduling ..

Also another request for tape - Can we please have an option to prioritize tape over disk? I want my disk job to be held automatically if a tape job is copying a disk source file


Thanks,

[veremin]

so the source backups need to run after midnight if we want a GFS job to process them that day ?

This is expected behaviour, indeed. It can be tweaked via registry, though.

Can we please have an option to prioritize tape over disk?

Already addressed in 9.5.

Thanks.

[cmaier]

Hi,

Daily incrementals are not addressed in GFS pools in 9.5? Why not? I thought you recognized that almost everyone needs this?

Regards,
Christian

[veremin]

I thought you recognized that almost everyone needs this?

We do recognize that. Nevertheless, we cannot deliver everything within one release, especially if it's . (point) one.

I can rest assured that the matter will be given its full consideration down the road.

Thanks.

[cmaier]

I didn't expect that this one is so complicated. However, if it's on the agenda I'm fine with that.

[Dima P.]

Christian,

Yes, it's in the list of most requested features.

[Alexey_mz]

I think not only me noticed the odd Veeam's features for tape backup. When i create backup job to tape with two media pools for example the fist with retention period 2 weeks for incremental backups and the second for fulls with retention 3 month. Then after some time we have one media pool that contains only incrementals and the second contains only fulls. But when i want to use GFS pool for full backups it starts to happen something strange - the page with incremental disappears and i can't backup incremental backups at all. That is very odd. As you said GFS is only for full backups - i'm totally okay with that, but why we can't store incremental backups for example in just media pool? We will have 2 separate pools as in situation above.

The next thing is automatic repository backup to tapes when backup arrives to disk. That is AWESOME feature, but we can use only media pools. Why we can't use GFS pool for full backup and media pool for incremental?

And the last odd thing is Files to tape backup. GFS pool is not supported for this operation. Why?!?

Veeam has a lot of sweet features like synthetic backup to tape, tape library servers and we can create logical pool with tape libraries. But all this worth nothing when you can't organize backup schedule without ass pain.

[expert]

And the last odd thing is Files to tape backup. GFS pool is not supported for this operation. Why?!?

I'm also missing this feature and hoped that will be integrated in verison 9.5

[Daveyd]

For those whom have a tape library that has multiple tape drives, are you using GFS media pools since they do not support parallel processing utilizing multiple drives?

[final]

For those whom have a tape library that has multiple tape drives, are you using GFS media pools since they do not support parallel processing utilizing multiple drives?

Yeah I do and I'm kinda frustrated about it. I don't quite understand why they've made GFS-Jobs so complicated. I think all that people wanted was regular Tape jobs combined with autmatic creation of retention sets (weekly, monthly, quarterly, yearly). I don't get why GFS-Jobs lack so many features regular tape jobs have. This is most notably for me:
- Parallel Tape processing
- If you can't do parallel tape processing just yet, PLEASE add an option so that all drives of a library are used (more or less) equally. GFS only uses the first drive of a library...
- Option to start a job after a full backup job finishes, instead of this timeout / wait for new backup sets to appear nonsense. To me, this seems to be one of those "why make it easy if we can make it complicated" cases.

And a super-fancy request: Add the option to run the Tape/GFS and the source-job in parallel, i.e. start them both at the same time. If the tape is faster than the disk drive, both jobs could write the input stream to their specific targets. If the disk is faster, then the tape job would have to read from the B2D-device while it's being written to.

[Shestakov]

Add the option to run the Tape/GFS and the source-job in parallel, i.e. start them both at the same time. If the tape is faster than the disk drive, both jobs could write the input stream to their specific targets. If the disk is faster, then the tape job would have to read from the B2D-device while it's being written to.

Source and tape job cannot run at the same time because source job may change the source backups on the fly making it inconsistent for the tape job.
There is a new option in v9.5 to postpone the start of the source job if tape one is still running.
Thanks

[Maurice]

Hello everyone,

i have a question about a GFS Job. It's configured to run on Sunday, but in the report i see it ran on sunday AND monday. Both successful. On Sunday it transfered 1,2 TB on 2 tapes and on monday it has done nothing.
Is that by design or is it a bug?
Running: v9.5 (without U1)



Thanks in advance.

Regards,
Maurice

[Shestakov]

Hello Maurice,
It looks like a bug. I will double-check the behavior with QA team and write back once we have results.
Thanks!

[Maurice]

Thank you! I really appreciate it.

[Shestakov]

Maurice,
That`s not a known issue.
Has it happened just once or you receive 2 notifications from 1 job run all the time?
Thanks!

[Maurice]

It happened last week, too. So it's a periodic behaviour. Should i open a case?

[Shestakov]

Yes, please do. Once you have a support case open, please share your case number here for us to follow the investigation.
Thanks!

[Maurice]

Case-ID: #02051942

[Shestakov]

Thanks.
By the way, QA has reproduced the bug as well. We will fix it in future releases.

[CPCS]

Hi,

Daily incrementals are not addressed in GFS pools in 9.5? Why not? I thought you recognized that almost everyone needs this?

Regards,
Christian

I also upgrade to 9.5U1 recently and am very disapointed that in times of daily new ramsomware i am still not able to protect my daily incrementals on a tape device with GFS