v9 GFS Media Pool & Tape Job

[Mapleuser]

Yes, that would be an alternative.
However, I will get two full backup running on weekends where the monthly/yearly schedule run.
Will use up double the amount of tape just to backup the weekly + monthly.
I don't have an autoloader at some sites and there are no staff in the office over the weekend.
This will give me a big headache on Monday.... and I need to get the tapes offsite by Monday due to compliance policy
really frustrating

[kmbelt]

Yes, that would be an alternative.
However, I will get two full backup running on weekends where the monthly/yearly schedule run.
Will use up double the amount of tape just to backup the weekly + monthly.
I don't have an autoloader at some sites and there are no staff in the office over the weekend.
This will give me a big headache on Monday.... and I need to get the tapes offsite by Monday due to compliance policy
really frustrating

I have the exact same problem. It wastes tape and time to do this. It would be easier for Veeam to wise up and add Daily Incrementals to the GFS pool and let the USERS decide if they want to use it or not. They rather tall us that they dont want us to use it this way. I'd love to jump ship, i can do the exact same thing with NetBackup and do it just as well.

This is another request for Incrementals to be included in GFS.

[UT2015]

The same here: GFS without daily increments is not really usable for us...

[UT2015]

Nevertheless (although daily increments have to be copied to tape with a different job) we have tried GFS. But it does not work as expected. We have the following jobs:

- (A) Backup job of a virtual environment, which creates an active full backup weekly on Friday. The job is starting on 23:45, it finishes around 11:00 on Saturday.
- (b) GFS backup to tape job, which backs up the result of job A, weekly backup should be done on Saturday.

We expect the GFS job to detect and backup the active full backup file shortly after the backup to disk has been finished (11:00). At that time the GFS Job is waiting, its last output is "No GFS candidate for Weekly media set was found for today, waiting".

When checking the detailed log file, it actually skips the active full backup file with the following reason: "Skipping storage F:\Backup\Backup Job\Backup Job2016-07-15T234607.vbk, because it is created in non GFS date"

The GFS job is actually continuing/starting to backup the next day (Sunday) on 00:17 with the message "No restore points found for the set date. Synthesized full backup was not created because the most recent restore Point is a full backup."

What does that mean? How do we need to configure the GFS job to directly start backing up to tape after the backup to disk is finished? Because that's exactly the behavior we have realized with the "normal" non-GFS job to tape before.

Best regards,
UT2015

[UT2015]

No idea why the GFS job is beginning to backup so late?

[pkelly_sts]

I'm not 100% sure but I *think* GFS jobs default to starting at midnight? I certainly seem to remember something along these lines having a midnight hard-code...

[UT2015]

But the job itself starts correctly on midnight (Saturday). It should find and copy that full backup which appears in the middle of that day, while its running...

[pkelly_sts]

Ah, sorry, I've not played with GFS scheduling enough to be able to offer much more. I do wonder though if the timing of the source job is affecting things - i.e. your source job STARTS on one day, then completes the next day. If at all possible, is it worth trying to switch the scheduling of the source job to 00:01 on the same day (of the week/month) as your GFS trigger?

[veremin]

We expect the GFS job to detect and backup the active full backup file shortly after the backup to disk has been finished (11:00).

GFS tape job detects a candidate to copy based on a backup creation time (time when a backup job starts), rather than on a time backup job finishes.

Since in your case those happen on different days (Friday, Saturday), GFS tape job has to wait till the end of the day before it starts copying anything.

What you can do is to make it not wait till the end of the day, but look at the previous day for restore point selection after some period of time. We have a regkey defining this timeout.

Add it on a backup server, and set it to 720 (12 hours * 60 minutes = 720 minutes).

Code: Select all

TapeGFSBackupWaitTimeout <DWORD>

Thanks.

[UT2015]

Does that mean, that the GFS Job will try to copy the file 12 hours after the backup job started? What if the original backup job takes 13 hours?

What is the exact path for the regkey, "HKLM\Software\Veeam\Veeam Backup and Replication"?

[veremin]

Does that mean, that the GFS Job will try to copy the file 12 hours after the backup job started?

Nope, it will try to copy the file at 12-00. It's recommended that a backup job should have finished before that. But in your case everything seems to be fine, as your job stops around 11 o'clock.

What is the exact path for the regkey, "HKLM\Software\Veeam\Veeam Backup and Replication"?

Yes. All the VB&R related regkeys should be added to the given hive, unless otherwise stated.

Thanks.

[UT2015]

It's recommended that a backup job should have finished before that. But in your case everything seems to be fine, as your job stops around 11 o'clock.

Today it takes that time but I don't know how long it will take in some months.

It would be a lot more practical, if the GFS Job would detect that the source backup job has finished and that a full backup file is on disk.

I think I will not use that GFS job. The idea is great, but it is not really usable for us.

[veremin]

Today it takes that time but I don't know how long it will take in some months.

The regkey is tweakable, even service restart is not needed in order for it to take effect.

It would be a lot more practical, if the GFS Job would detect that the source backup job has finished and that a full backup file is on disk.

That's how it works. Though, your scenario is different as a primary (backup) and secondary (GFS tape) jobs are executed on different days. Thus, the said behaviour.

Thanks.

[UT2015]

The regkey is tweakable, even service restart is not needed in order for it to take effect.

I don't want to adjust registry keys to make different backup Jobs work, which are depending on eather other. This should automatically be done by the application IMHO.

Though, your scenario is different as a primary (backup) and secondary (GFS tape) jobs are executed on different days. Thus, the said behaviour.

What would be different, if they were both executed on the same day? If the backup to disk would start Saturday 00:00 and would take up to approx. 13:00, the GFS Job to tape would still only start on Sunday, 00:00, wouldn't it?

[veremin]

If the backup to disk would start Saturday 00:00 and would take up to approx. 13:00, the GFS Job to tape would still only start on Sunday, 00:00, wouldn't it?

Nope, it would not. The newly-created restore point will be copied some time after it appears within the same day. Thanks.

[Sarek70]

we use GFS to backup weekly/month/year. On saturday a reversed incremental is made but somehow the .vbk file does not end up to tape. The GFS starts at 00:00 on sunday (cause is can't be sheduled on a other time for some reason). At that time the conversion of de incrementals from .vib to vrb. and make the .vbr file up to date is not done. Below are the detail of the job. i'm running version 9.0.0.1491

Code: Select all

7/24/2016 12:00:23 AM :: Building source backup files list started at 7/24/2016 12:00 AM 
7/24/2016 12:00:23 AM :: Source backup files detected. VBK: 0, VBK map: 0, VIB: 0 
7/24/2016 12:00:23 AM :: No GFS candidate for Weekly media set was found for today, waiting 
7/24/2016 4:20:47 AM :: No restore points found for the set date. Synthesized full backup was not created because the most recent restore point is a full backup Backup NfsVol22016-07-23T203034.vbk (7/23/2016 8:30:34 PM).

[veremin]

Your problem seems to be similar to the one discussed on the previous page. So, kindly, take a look at the answers provided there. Thanks.

[cmaier]

Are there any plans to get incrementals into GFS media in version 9.5?
Are there any plans to have GFS media (with incrementals/differentials) for File 2 Tape Jobs?

I would really like to throw our Backup Exec far away but at the moment the Veeam way looks too camplicated.

[UT2015]

Nope, it would not. The newly-created restore point will be copied some time after it appears within the same day. Thanks.

I changed it as suggested by you, meaning Backup-to-Disk-Job and GFS-Job are both running on the same day. You are right, the GFS-Job finds the candidate to backup earlier, BUT: this does not work in combination with Endpoint Backup!

The GFS Job finds files from the Endpoint Backup, although that Endpoint Backup is still active. Therefore the complete GFS Job fails, because the file to backup cannot be accessed (because Endpoint Backup is still writing to it).

It's really sad what a big effort is needed to get B+R in combination with Endpoint and GFS running...

[veremin]

Do you mind answering few additional questions:

- What is selected as a source for a backup to tape job? EP backups? Backup copy jobs taking care about EP backups? Repository as a whole?
- What particular error does the tape job fail with?

Thanks.

[UT2015]

(1) Source of GFS Job is one big VMware backup and several Endpoint Backups of physical Servers

(2) "Creating full backup map for F:\Backup\_svc_veeamendpoint\Backup Job SRV11\Backup_Job_SRV112016-08-06T130611.vib
Failed to detect backup files to copy to tape from (_svc_veeamendpoint)Backup Job SRV11 backup Job"

This is because the Endpoint Backup is still active at that time.

[veremin]

It's a known issue that GFS tape job starts processing EP backups before actual merge happens. That leads to the described issue.

However, GFS tape job has built-in retry mechanism. And once it retries at the time when EP merge has finished, it should process those files just fine. Or you're saying even after several retries EP files were archived to tapes?

Thanks.

[UT2015]

The Job actually did not retry. It tried once, failed and by this screwed up the montly backup...

[veremin]

It should be re-scheduled automatically to next hour. If that doesn't happen, kindly, contact our support team for further assistance. Thanks.

[UT2015]

How can I handle this incomplete backup on tape? Is it possible to finish it in any way?

Is it possible to delete that backup from GFS media pool and mark another (namely the next weekly backup) as monthly backup?

[veremin]

How can I handle this incomplete backup on tape?

During retry a GFS tape job should start from a point where it left.

Is it possible to delete that backup from GFS media pool and mark another (namely the next weekly backup) as monthly backup?

It's possible to erase a particular tape, meanwhile, it isn't possible to mark specific cassette as a GFS restore point.

Thanks.

[UT2015]

It's possible to erase a particular tape, meanwhile, it isn't possible to mark specific cassette as a GFS restore point.

I don't what to mark a specific cassette. I want to move/rename a Media Set from "Weekly" to "Monthly", because the GFS Job left me without a valid monthly backup. I "just" want to change the "category" and the expiration date...

If that's not possible, I would have to manage my media sets (weekly, monthly, yearly, etc.) outside Veeam (as done before) without using GFS job...

[veremin]

It's not possible.

However, the fact that GFS failed and didn't archive EP backups successfully (even after series of retries) doesn't look expected. So, if I were you, I would open a ticket with our support team and let them investigate it directly.

Thanks.

[UT2015]

The support actually didn't help us a single time, although we had opened already several tickets in the past, so we don't want to spend any more time on that...

[veremin]

Then, there is not much we can do from our side to resolve the issue.

I've described the way our mechanism is supposed to work and said that the fact it misbehaved should be investigated closely, but without opened case and provided logs we cannot take any further step in the investigation.

Thanks.