Please let me disable the daily tape 'full' job.

[BackupMonkey]

How are people getting around Veeaam's poor handling of GFS tape jobs and the 'full' on the daily tape job?

Our daily inc's go to tape just fine but due to data\time constraints we have to start our tape jobs early on the weekend so what happens is that that daily inc gets merged into the fulls which are written to tape via the daily tape job (Since I can't turn it off)

At midnight the GFS job starts and we get this.

***
41 new backups will be placed into the monthly media set
<6 seconds later>
0 directories and 0 files backed up
Synthesized full backup was not created for 22/02/2019: there are no new restore points between 29/01/2019 and 22/02/2019
***

Is there anyway I can disable the full option on a normal tape job completely. It's unwanted, unneeded and it's getting in my way.

Cheers.

[Dima P.]

Hello BackupMonkey,

Generally daily run does not create synthesized full backups. It may transfer full backups from disk (whenever there is no incremental restore point for the given day). I believe the notification from the log is generic thus displayed for all GFS tape job runs but I'll check that with QA team. Thanks!

[BackupMonkey]

Hi Dima.

The daily job writing the full to tape causes the GFS job to fail since there are no updates to the disk based repository since the daily tape job has already written them to tape. I can watch this behavior in the logs in real time and it's outright silly that Veeam demands that the same data be written to tape twice to satisfy the 'Daily' tape job running a FULL backup and the GFS job running a FULL since the data source is the same. The same VBK files from the disk.

If I remove any tape job the disk based backups create incremental backups then rolls them to fulls.
I add the daily tape job and I get the incremental to tape and the full roll-up to tape.
I add the GFS job and I get errors since there has been no updates to the disk based backup since the daily tape did the full to tape. (This right here is my issue - I can't stop the daily tape job running a full)

If I adjust the timing I get the daily job trying to do a full during the week which takes too long and I have to cancel it and thus goes the week since the tape job writes all changes to tape so the issue is compounded each night until the next weekend when the next full is created.

Just let me disable the daily tape based 'full' job and my problem of your implementation goes away.

[csydas]

BackupMonkey,

We're heavy tape users in my shop and everything you're writing is extremely confusing to me, since we have absolutely none of these issues moving around 40 some TB to tape each week. I realize we're kind of small compared to enterprise level shops, but our Dailies do exactly what they should.

I've been using Veeam for awhile, and you're confusing me with some of your terms -- Veeam doesn't really do "roll-ups" like other products do; the synthetic fulls (virtual fulls) are a new point that is combined, it's not the same as a roll-up from other products.

>If I remove any tape job the disk based backups create incremental backups then rolls them to fulls.

I've never seen this behavior, what exactly do you mean? Removing a job causes other jobs to behave differently? Or you're meaning your disk based backups are doing Synthetic Fulls periodically?

> I add the daily tape job and I get the incremental to tape and the full roll-up to tape.

I'm assuming you mean a Synthetic Full + increments go to tape in the first run after re-enabling Daily GFS backups for tape.

> I add the GFS job and I get errors since there has been no updates to the disk based backup since the daily tape did the full to tape. (This right here is my issue - I can't stop the daily tape job running a full)

I'm assuming you mean you re-enable the other GFS periods, but honestly I'm not sure what you're talking about. I get it's annoying, but accuracy in terminology is important. What you're describing sounds natural because incremental backups by definition rely on a full backup; this is true for any backup application, not just Veeam. Incremental rely on the previous increment back to a Full Backup file, and in your case, when you disable and re-enable jobs, the following logic applies:

1. Daily takes a full because you can't just backup increments, you need a Full also to rely on. As there is no full, it's grabbed by the Daily it seems, as I'm guessing this isn't a weekly day. Per the User Guide here: https://helpcenter.veeam.com/docs/backu ... l?ver=95u4

If today some elder media sets are also scheduled, for example, the weekly media set, the GFS job archives the first restore point to the Weekly media set

If your Weeklies are scheduled on the same day, then it sounds buggy more than anything and it's probably worth just spelling out for Support.

2. Assuming 1 is true, then when the weekly runs it ought just either grab the point made that day (you're scheduling your Weeklies the same day you're making the Synthetic Fulls, right?) or else there's no need for it to grab the backup again. Again, I'm not really clear on what you're seeing since your posts are confusing terminology and the order of operations.

We legit just turned on Dailies and never looked back, and checking now, they're doing what they should. No random fulls.

From what you're saying, it sounds like you're unhappy that Fulls are getting included in the Daily set and you think this is because on the weekend which is when your Synthetic Fulls are running, so there's only a full backup that day.

If this is the case, it sounds wrong and the logic should be investigated so it can be fixed.

But please clarify the order of operations, cause this is super confusing for me to read as is.

[BackupMonkey]

Hi Csydas.

In a nut shell I get this.

The first active full
The daily VIB
and the Friday (Rollup) to virtual full. (Whatever Veeam wish to call it)

Now add the daily tape job so you get this....
The first active full. (VBK Goes to tape)
The daily VIB. (VIB Goes to tape)
and the Friday virtual full. (VBK Goes to tape)


Even that is perfectly fine but now I have to keep 20 tapes (per weekend) for 7 years (Retention policy) - 7280 tapes. That doesn't include the daily ones which are rotated around every 7 days so not much hassle.

So now we add the GFS job - It's long term retention so perfect, I can use less tapes.
The first active full. (VBK Goes to tape)
The daily VIB. (VIB Goes to daily tape)
and the Friday virtual full. (VBK Goes to tape via the none GFS and the GFS job)

Herein lies the issue.
The repositories knows when something is written to tape so whatever job (Either none GFS or GFS) gets to the VBK first, writes it. The other fails because there is nothing in the repository that hasn't been written to tape.

What I need is for Veeam to let me stop the none GFS tape job from backing up the VBK file when a GFS job is active.
It's simply not needed when GFS jobs are in play. There's even an option for GFS weekly to take it's place.



I'm going to try something this week and add yet another layer of complexity into it to get around this.

Add a second repository.
Add a second MSL with one drive (Don't even get me started why GFS jobs can only use one drive )
Once the VBK is created, copy that to the second repository via another job and run the GFS job from that one so that the daily can copy it from the repository1.

With some luck, Veeam haven't linked repository data in the background somehow.

Cheers.

[BackupMonkey]

OR

As support has kindly pointed out making me eat a lot of humble pie on this one. (Which I'm happy to)

Update to Update 4
Move the daily tape job to the GFS tape job and enable parallel processing on the GFS job. (Both of these options don't exist on my version - 1922)

So... I feel like an idiot.

[csydas]

Hey BackupMonkey,

If it makes you feel better, I was clearing data off of some systems and accidentally typed a > instead of a ., which resulted in my command being rm -rf *>vbk instead of .vbk )) We all have to dine on humble pie every so often.

Mistakes happen I wasn't trying to be challenging, it's just I've had a a basically non-issue in my shop with Dailies.

GFS parallel processing was a blessing of U4. No idea why it took 2(3?) versions to get it, but I"m happy it's here.

I wish the best for you.

[Dima P.]

BackupMonkey,

I am glad to hear that your issue was resolved. I was under impression that built-in daily media set in GFS tape job (the one that we've introduced in Veeam 9.5 Update 4) does not work as expected, so thank you for getting back to us. Cheers!