Discussions related to exporting backups to tape and backing up directly to tape.
Post Reply
redhorse
Expert
Posts: 203
Liked: 10 times
Joined: Feb 19, 2013 8:08 am
Full Name: RH
Location: Germany
Contact:

GFS starts too early with Endpoint as source

Post by redhorse »

Hello,

I have a GFS-Job for Tape which has two Endpoint-Backups as a source and as I understood the GFS-Job should start when a new restore point is created on the GFS-day. Unfortunately the GFS-Job seems to start about one minute too early so I see in the Job Summary that Veeam failed to detect backup files to copy to tape. With the second or third try it works but the whole job is marked as failed an I get an error mail that the job failed. Is this a known issue?

I see in the job summary that the GFS-Job tries to catch the Endpoint Backup at 17:12:53, in the Endpoint-Log I see that it is still merging at 65 % and it is finished at about 17:13:55. This behaviour happens with every backup cycle.

Case #01800757
Dima P.
Product Manager
Posts: 14396
Liked: 1568 times
Joined: Feb 04, 2013 2:07 pm
Full Name: Dmitry Popov
Location: Prague
Contact:

Re: GFS starts too early with Endpoint as source

Post by Dima P. »

Hi redhorse,

GFS job kicks in at 00:00 of the scheduled day and waits for new restore points. I assume VEB locks these restore points, causing GFS job to fail. Now, due the daily retry cycle, GFS job starts a retry and takes the VEB backups, since it has been unlocked by the source job.

I’ll check with QA folks regarding the job failure state and email report, as this part sounds a bit confusing.
redhorse
Expert
Posts: 203
Liked: 10 times
Joined: Feb 19, 2013 8:08 am
Full Name: RH
Location: Germany
Contact:

Re: GFS starts too early with Endpoint as sour

Post by redhorse »

Dima P. wrote:GFS job kicks in at 00:00 of the scheduled day and waits for new restore points. I assume VEB locks these restore points, causing GFS job to fail. Now, due the daily retry cycle, GFS job starts a retry and takes the VEB backups, since it has been unlocked by the source job.
That's what I see in the logs, but why does the GFS job try to catch the new restore point from an Endpoint Backup during the running merge? After the merge is complete (about 10 minutes later) the GFS works after two failed events. Sometimes I see this behaviour also with backup copys with Endpoints as source where the source can't be locked because the Endpoint Job is not finished yet but backup copy wants to catch the restore point.
Dima P. wrote:I’ll check with QA folks regarding the job failure state and email report, as this part sounds a bit confusing.
What I want to say is that Veeam marks the GFS job in the GUI als failed and also sends an error mail for it although all parts of the GFS job have the success status.

I think the failed attempts to lock the Endpoint Backups too early shouldn't happen as it makes no sense but at the end all parts of the GFS job are successful with some retries, so the job status should also be successful.
Post Reply

Who is online

Users browsing this forum: No registered users and 26 guests