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
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.