Reverse Incremental Backup on tape

[zipman]

Perhaps it's only my fault, but I cannot understand how synthesized backups on tape works (even after reading the docs I found).
All my clients make daily reverse incremental backups on NAS repository (with 30 and 60 recovery point depending on the job), and every Sunday they save the last full backups of the week on tape for off-site archiving & DR. Everything went smooth with version 7. One of them recently upgraded to v8 and the things with tape are going wrong...
With v7 I made a tape job, scheduled every Sunday and without the option to process incrementals; the job took the vbk for every specified backup job and copied it on the tape. Tape space usage was barely the sum of the vbks and the time consumed was the time needed to transfer the data on the tapes. Everything worked as desired and as expected.
With v8 the "synthesized backup saga" begun. The tape job option are exactly the same as the old v7 job (I made an upgrade in-place), but it doesn't work as expected anymore. When the job starts It makes synthesized backup of all the reverse incrementals (and I cannot absolutely understand why it should consider vrbs when I specified to not consider incrementals) and this takes an incredible amount of time, about 40% of the total time of the job (it makes 30 to 60 unnecessary synthesized backups for every job, one for every vrb) and that causes the backup not to finish in the allowed backup window. In addition the space usage on tape is considerably higher than before (40% to 80% more than before) and it causes problems with media export for the backup operator (3 tapes on v7, 4-5 tapes on v8 and only 3 export bay).
Can someone explain this odd behaviour? Is there a method to make B&R act in the desired way (as in v7) where only the last full backup is copied on tape? I could workaround this problem creating a file copy job and saving only the vbks, but this implies the impossibility to directly restore from tape (and, frankly, this is also the reason because some of my clients bought the enterprise version instead of standard, so its important for me to make the things work as expected).
Thanks in Advance
Flavio

[Hevros]

Hi,

I have a similar issue, we run reverse incremental and we copy the vbk to tape every day, since the v8 upgrade I get a spam of synthesising a vbk from vrb messages then it fails with "Failed to detect backup files to copy to tape from Exchange P1 backup job"
we have the process incremental option off, why is it synthesising a vbk when we have a vbk?

[veremin]

Hi, guys, have you seen this KB article already? Thanks.

[roms]

Yes, after the hotfix assignment copies the desired VBK file on the tape, but does not overwrite, and adds a new full to the existing previous. On the tape there is no free space task requires insert another tape:

12/11/2014 12:18:53 AM :: Tape Week2 is full
12/11/2014 12:18:56 AM :: Tape currently in drive can not be used for backup
12/11/2014 12:18:56 AM :: Insert a valid tape into the library, oldest retained tape:

But in the Media Pool Retention selected "Do not protect data (Cyclically overwrite tapes as required)

This is an obvious bug

[Dima P.]

Rachman,

Try to change the media set creation option in the Media Pool> Media Set> Create new media set for every backup session and let me know how it goes?

[roms]

Dmitry,
Yes, selecting "Create new media set for every backup session" overwrites the tape.
Thanks

[veremin]

Tape overwrite period is controlled by both retention and mediaset creation settings. So, once you changed the latter to the correct values, everything started to work as expected. Anyway, glad to hear that you're up and running now. Thanks.

[Hevros]

Hi, guys, have you seen this KB article already? Thanks.

yes I saw that KB but is says jobs may fail with the error: MediaPool not found (id: 00000000-0000-0000-0000-000000000000).

that is not my issue, but when I logged a call with support they also pointed me to this KB so it obviously fixes more than that specific error.
either way is worked. and my issue is resolved.

One question, as this KB is just a replacement DLL file. how will this work with future patches. is this new DLL included in patch 1 or will we need to re-apply this fix after patching?

[Dima P.]

One question, as this KB is just a replacement DLL file. how will this work with future patches. is this new DLL included in patch 1 or will we need to re-apply this fix after patching?

All public hotfixes are included into upcoming patches, so there is nothing to worry about.

[zipman]

OK, thanks Dmitry. KB1949 worked fine with one of my clients (for another one I have another case opened and I'll wait for that to resolve)

But I have another question. One of my clients had the problem described in KB1967 when reusing tape from Backup Exex. Even the 1967 fix replaces the same DLL of 1949 (Veeam.backup.core.dll), but are the fix mutually exclusive or does one contain the other? Unfortunately in the poperties of the DLL there aren't correct build version informations, and the assumption that the higher KB number includes the lower ones is proved false, at least in this case.

I'd suggest to set the file version of the DLL to something different from 8.0.0.0 (that is really unmeaninful); usually the build number is a good practice and allows to recognize the correct sequence of the patches.
Thanks
Flavio

[foggy]

I do believe that those fixes are pinpoint and are implemented to address specific issues (described in the corresponding articles) only. So if you replace DLL that fixes some issue with the one that fixes another issue, you start experience the first issue again. You can contact technical support and ask if they are able to provide some kind of cumulative fix that would address both issues. Thanks.