Tape restore point selection is worthless

[skrause]

I have been fighting restore point selection issues with automatic tape jobs for months now. I have re-engineered how I move data between datacenters/repositories to try and get it so I can have an automatic job that sends a full from month end of our critical VMs to tape. I finally thought I had it where there would be no issues with having the most recent backup copy point be skipped because tape jobs can't use them, or a network blip causing a total job failure because tape jobs cannot reconnect if there is one infintessimally small network blip between the tape server and the repository.

I come in this morning to see if my GFS tape job set to run on the first Monday of the month is running happily and I find that it has decided to bypass 4 weeks of full VBK files on one of the VMs to create a virtual full from a VIB over a month old. This source job runs an active full every Friday night and yet Veeam has decided to ignore it.

Code: Select all

11/7/2016 12:00:28 AM :: Full backup from FILE012016-10-03T220122.vib (10/3/2016 12:00:00 AM) restore point will be placed to monthly media set 
11/7/2016 12:00:28 AM :: No GFS candidate for Monthly media set was found for today, waiting 
11/7/2016 12:00:28 AM :: Backup file J:\Backups\FILE01\FILE012016-10-03T220122.vib will be excluded from the list of files to backup, because it is unavailable. Virtual full backup creation will be skipped 
11/7/2016 12:00:28 AM :: Source backup files detected. VBK: 0, VBK map: 0, VIB: 0 
11/7/2016 6:05:24 AM :: Source backup files detected. VBK: 0, VBK map: 1, VIB: 0 
11/7/2016 6:05:25 AM :: Creating full backup map for J:\Backups\FFILE01\FILE012016-10-03T220122.vib 
11/7/2016 6:06:36 AM :: Queued for processing at 11/7/2016 6:06:44 AM 
11/7/2016 6:06:36 AM :: Required backup infrastructure resources have been assigned 
11/7/2016 6:06:36 AM :: Backup to media set monthly started at 11/07/2016 00:00:10 
11/7/2016 6:06:39 AM :: Drive 1 (Server: VR01, Library: IBM 3573-TL C.50, Drive ID: Tape1) locked successfully 
11/7/2016 6:07:16 AM :: New tape backup session started, encryption: hardware 
11/7/2016 6:07:26 AM :: Processing FILE012016-10-03T220122.vbk 

Every time I have opened a ticket about tape issues it has been a constant case of effectively telling me "you're doing it wrong". I am starting to lose my faith in this product as I promised my boss that it could do what we wanted easily and more effectively than our old solution of just grabbing the weekly full tape and sending it away but it appears not.

I have not opened a ticket about this yet, since the job is still running "pending" its wait on source backup copy jobs to have a restore point it will deign to use.

[Dima P.]

Hello Steve,

This source job runs an active full every Friday night and yet Veeam has decided to ignore it.

Must admit, we received several cases where GFS candidate selection logic was misbehaving or failing. All reported issues are going to be fixed in upcoming v9.5

network blip causing a total job failure because tape jobs cannot reconnect

Aware of this problem. We are going to fix it as soon as possible (hopefully, we will add the reconnect logic to the upcoming update for v9.5)

This source job runs an active full every Friday night and yet Veeam has decided to ignore it.

Unfortunately, I can’t say what’s going on. Either the latest restore point was locked by source job (which should not be the case if thats Active Full) or something is wrong with the GFS candidate selection logic. Please open a case and ask our support team to investigate the logs. Don’t forget to post the case ID in this thread, so I could ask QA team to check your case and make sure that we have it fixed in new version.

[skrause]

I will open a case once the job completes.

[Dima P.]

TThanks. Can you share the case IDs for previously reported issues with GFS, so we could review them with the team?

[skrause]

New case opened: 01971044

Only other GFS specific issue I opened a ticket for was 01720942. When I could not get GFS to work reliably after a couple months of trying I went back to building a job a month manually until I could re-configure copy jobs to sync daily. Yesterday was the first attempt to use GFS since May.

One other thing that came up in this job yesterday, which is a bit annoying but not game breaking. My source backup copy jobs are all GFS jobs that do a copy-full every weekend so there is a .vbk file no more than 2 days old sitting on disk. When the GFS tape job scans, it uses the most recent .vib and creates a synthetic full for the date/time of the .vib instead of just reading the .vbk from source. It would be nice if the tape logic had way to grab the most recent .vbk and not do any synthetic operations.

[Dima P.]

Thanks Steve!

It would be nice if the tape logic had way to grab the most recent .vbk and not do any synthetic operations.

Good point. There is an existing limitation for backup copy jobs with GFS enabled (backup copy GFS restore points are skipped by GFS tape job). I’ll check with the team.

[Dima P.]

Hi folks,

Getting back to the topic. Reconnect issue is finally fixed in v9.5 Update 1

[doggatas]

My source backup copy jobs are all GFS jobs that do a copy-full every weekend so there is a .vbk file no more than 2 days old sitting on disk. When the GFS tape job scans, it uses the most recent .vib and creates a synthetic full for the date/time of the .vib instead of just reading the .vbk from source. It would be nice if the tape logic had way to grab the most recent .vbk and not do any synthetic operati

I have a backup copy job which has two restore points and 6 monthly archive points, which in file explorer looked like this on the 31/10/2017

Archive1_M
Archive2_M
Archive3_M
Archive4_M
Archive5_M
Archive6_M
Current_30-10-2017_VBK
Current_31-10-2017_VIB

The GFS tape job runs (last day of month) and VBK Maps the vib to a full for the the tape copy

WHat I would like to be able to do is have the GFS monthly job run on the day the the files look like this (which is the first day of the month after the backup copy jobs have finished):

Archive1_M
Archive2_M
Archive3_M
Archive4_M
Archive5_M
Archive6_M
Current_31-10-2017_VBK
Current_01-11-2017_VIB

That way there is an end of month full already on disk and its a straight copy to tape, no synthesis needed. I.e. run the last day of month GFS tape job on the 1st day of the month and have it capture the already synthesised (from the backup copy job with the 2 restore points) restore point.


Is there anyway to achieve this? Happy to run powershell scripts to trigger jobs manually if needed.

I have lodged a ticket: 02368454

Regards