Backup Copy Job to tape question

[McClane]

Hi,

I have a Backup Copy job that starts at 10pm. And a Tape Job that starts at 1am. The Copy Job is finish around 10:30pm. But it always put the restore point from the day before on the tape. Not the one that was finished a few hours earlier.
The copy interval is set to daily 10pm and the original job is finish around 9pm.
It there any reason for this behavior?

Greetings,

Manuel

[Shestakov]

Hi Manuel,
are you sure backup copy job is done by 1am? My guess is it can still be working on merge.
By the way, is it GFS tape job?
Thanks!

[veremin]

Also, isn't it a virtual full backup by any chance? If so, isn't it scheduled for the previous day (the day a job starts)? Thanks.

[lyapkost]

Hi Manuel. This behavior is expected. The last point of backup copy job is not processed by tape jobs. UG:

If the source job is backup copy job, keep in mind that the last restore point of the backup copy job stays active until the next restore point is created. The tape job does not copy such active points, because they may be updated. For this reason, the backup chain on tape will be always one restore point shorter than on disk.

[AJ83]

This behaviour is to be expected according to documentation, but i was fully expecting to be able to make a recent copy to tape by using the backupcopy jobs as a source....

Whats the workaround? Does it change the behaviour if i make the secondary repo (where the copy job points to) the source for the tapejob? I dont want to use the primairy repo as a source because i have a specific window for using the bandwith from primairy to secondary repo.

Is there a chance this will be fixed in a future release?

[Dima P.]

Hello AJ83,

Unfortunately, there is no workaround for that due to the nature of current copy job implementation (continuous schedule with periodic sync intervals). However, we will provide a way to address this issue in next major version. Cheers!

[DerOest]

Hello there,

just wanted to say that we're facing this "issue", too.
Tape runs weekly on saturday, but instead of copying the friday evening backup, it copies thursday evening.

Here's the thing: GFS Copy starts saturday at 00:xx and finishes by 01:xx including all merges
The GFS Copy is set to "run 1 times daily", so after finishing at 01:xx, it should release the GFS and finish for the day.
That way, Tape could pick it up.

On the other hand, at least with ReFS, the tape job could simply synthesize a full from the "not yet unlocked" file and use that...


I mean i understand those issues from a programming side. But this is a backup solution for backup admins.
If a backup admin wants a weekly tape on saturday,it is expected to copy exactly that and not a backup from ~2 days ago!


Is there a vague timeframe for "next major version"?

[Dima P.]

DerOest,

Here's the thing: GFS Copy starts saturday at 00:xx and finishes by 01:xx including all merges
The GFS Copy is set to "run 1 times daily", so after finishing at 01:xx, it should release the GFS and finish for the day.
That way, Tape could pick it up.

To clarify, are you saying that this scenario is not working? GFS is configured on the backup copy job level? Thanks!

[DerOest]

Hi Dima,

currently it's not working as expected (from a backup admin viewpoint), but from the post above i figure thats expected Veeam-behaviour?

Hi Manuel. This behavior is expected. The last point of backup copy job is not processed by tape jobs. UG:

That article says:

If the source job is backup copy job, keep in mind that the last restore point of the backup copy job stays active until the next restore point is created. The tape job does not copy such active points, because they may be updated. For this reason, the backup chain on tape will be always one restore point shorter than on disk.

But this behaviour could be programmed smarter:
Our GFS are "run once daily", yet they keep running after doing their work, therefor keeping the files locked.
I would expect the GFS to stop once it did it "run once daily" and unlock the file, so the Tape Job could pick it up.
(Or even have the tape job synthesize a full off of that still locked file! Should be possible on ReFS, right?)



To further clarify:
- Primary Backup
-> GFS
-> GFS-to-Tape

On Saturday morning the GFS-Job copies the Friday evening primary backup:
22.06.2019 00:20:39 :: Copying restore point 21.06.2019 18:12:12 from backup repository S3260-REFS-Repository
...
22.06.2019 02:04:09 :: Processing finished at 22.06.2019 02:04:09
23.06.2019 00:20:09 :: Job finished at 22.06.2019 02:36:50 <-- see above - "run once" finished, but the job is only terminated the next day!


Then this happens with the Tape-Job:

22.06.2019 02:30:31 :: Building source backup files list started at 22.06.2019 02:30:31
22.06.2019 02:30:32 :: Timed out trying to open backup file xxxx.vm-747D2019-06-22T002000_A8D4.vib
22.06.2019 02:30:32 :: No restore point for 22.06.2019 is available for virtual full backup, using previous restore point for 21.06.2019

-> using previous restore point for 21.06.2019
Which is the GFS Copy that finished on friday moring, which includes the thursday evening backup

=> Saturday-Tape-Job picks up the Thursday evening backup instead of friday


But i would expect it to pick the latest backup point no matter what. I want friday evening on my weekly tapes, Veeam should deal better with locking the GFS-files somehow.

[Dima P.]

Can you please confirm that you still see this behavior after applying the fix mentioned in this thread - I suspect that GFS restore point was not selected due to that issue with the restore point detection (as GFS full restore point should not be locked by the backup copy once it's being created). Thank you in advance!

[DerOest]

Hi Dima,

thank you very much for your help, just to further clarify (because i have the hotfix installed, yet still see this behaviour):

This is expected (from Veeam, but not backup admins!) and explained in the Helpcenter: https://helpcenter.veeam.com/docs/backu ... tml?ver=95

If the source job is backup copy job, keep in mind that the last restore point of the backup copy job stays active until the next restore point is created. The tape job does not copy such active points , because they may be updated. For this reason, the backup chain on tape will be always one restore point shorter than on disk.

[Dima P.]

DerOest,

Thanks for the clarification. We will discuss this thread with RnD folks. Cheers!