Discussions related to exporting backups to tape and backing up directly to tape.
Post Reply
GrayMan
Novice
Posts: 7
Liked: never
Joined: Oct 31, 2017 3:18 pm
Full Name: Angus Alston
Contact:

Tape backup of latest active full

Post by GrayMan »

Just trying to do something simple with tape backups which is no longer working as it did and hoping someone has a workaround for this!

We are using HP StoreOnce catalyst stores for our backup respositories.
On our prime site we do standard weekly full backups and daily incrementals.
These are copied offsite to another catalyst store using Veeam copyjobs with the GFS option to copy the active full, weekly, from source to the offsite store selected. We hang onto 5 weekly fulls and the last week's worth of incrementals on the offsite store.

We then want to copy, once a month, the latest active full offsite copy to tape. This was achieved simply by specifying on the tape job to use only the 'latest full backup chain' and then in the 'Full Backup' section of the tape job unselecting ALL the days in the full backup schedule. (N.B. Any day that you select that isn't the same day as the full restore point will generate a synthetic full on the tape using the latest active full and all incrementals following it.) By specifying this option only the very latest .vbk files were copied to tape, no synthesis. This is important for two reasons:
1) The synthetic fulls to tape tend to be a lot slower than just copying the active full
2) Due to bandwidth limitations we sometime fail to complete the incremental offsite copies and so if the tape job includes one of these incomplete restore points in a synthetic full it makes it completely unusable. Oddly the tape job only finishes with a warning even if it appears to have written the correct amount of data to the tape and it is impossible to restore from.

So the problem now is that since update 3 (9.5u3) you are now compelled to tick at least one day in the Tape job full backup 'schedule'. If this day does not match the actual day of the latest active full in the copy job restore chain you end up with a synthetic full on the tape.

This sounds easy enough to fix, all you need to do is set that day to the same day as the 'full' shows in the copy job restore point chain. That does work, mostly. However, the backup copy jobs are a law unto themselves and the full backup day can vary (even though it's supposed to copy the active full from the source which is the same day every week).

My question is, does anyone have a reliable method of getting just the latest Active full from a backup copy job chain to tape?
Dima P.
Product Manager
Posts: 14417
Liked: 1576 times
Joined: Feb 04, 2013 2:07 pm
Full Name: Dmitry Popov
Location: Prague
Contact:

Re: Tape backup of latest active full

Post by Dima P. »

Hello Angus.

I am afraid there is no workaround (except matching active full creation with tape job start time): if full backup for the set day does not exist and full backup is scheduled for tape job then it will force the creation of synthesized full.
GrayMan
Novice
Posts: 7
Liked: never
Joined: Oct 31, 2017 3:18 pm
Full Name: Angus Alston
Contact:

Re: Tape backup of latest active full

Post by GrayMan »

Hi Dmitry,

Thanks for the quick response, disappointing though the answer is :)

That would be fine if the copy jobs performed in a logical or even consistent manner. What I'm seeing over the last few months is that the day that the 'Full' shows up in the copy job backup chain bears no relation to either the day of the active full on the source backup or the day that is set in the copy job itself for copying the weekly active full from the source.

So as an example:
Source job active full day set as - SUNDAY
BCJ Transfer day (copy active Full from source) - SUNDAY
actual day of Full in BCJ chain - SATURDAY (also FRIDAY a couple of weeks ago in the same chain)

That's just an example, I have seen the full in the BCJ chain appear two or three days before the source full!!! Makes you wonder if the 'copy from source' is being ignored and a synthetic full is being created.

Because of this variation in the positioning of the full backup it's hard to get a consistent result from the tape jobs.

Does this behaviour sound correct or does it sound like a bug? Should I be raising this as a support issue?

Thanks
Post Reply

Who is online

Users browsing this forum: No registered users and 17 guests