Feature Request: disable synthetic option

[namiko78]

I was backing up my vm's to tape from my main backup repository, but one of the large ones (4TB) wasn't finishing before the next nightly backup started and killed the tape job. So I thought, why not backup from my backup copy job repository, maybe that will wait for the tape drive job to finish and not kill it. Well, it did wait, but was backing up twice the amount of data then i expected. After talking with support, it seems it was backing up the base VBK, AND the synthetic file. So i'd get two VBK's as part of my job.

I only want one.

I'm now left with switching my main backups back to reverse incremental, which means i'll have to recreate them as i don't have enough space for the new VBK it's trying to make after the mode switch.
GAH!
Case # 01021731
Please allow a synthetic full disable option for tape jobs that have forward incremental jobs as source.

Thanks

[veremin]

But without virtual full backup how would you deal with .vbk that gets updated constantly (when retention is reached), as well as, corresponding increments (one of which is deleted and one has its references to previous restore point changed)?

[namiko78]

I've read your message 4 times and i don't know what you're talking about. I'm fine with the functionality of the backup copy job, i just don't want two VBK's on my tape media. I thought it was generating a synthetic full and only that, but it's putting that plus the month old VBK (beginning of my chain) on tape.

[veremin]

Without virtual full backup option how would you deal with the oldest restore point in forward forever incremental chain - .vbk file?

After initial cycle, it's then skipped from processing.

But even if it wasn't, how would you handle the fact that once retention is reached the .vbk starts moving forward with subsequent increment being injected into it? Should it be copied each time? What about its previous versions already stored on tapes? Should they be automatically deleted? What about increments already stored on tapes that have references to the previous .vbk version, etc.? Given all the questions, how restore process should look like?

Virtual full backup does address all of the above mentioned cases. Thus, it's mandatory for forward forever incremental backup chains.

I thought it was generating a synthetic full and only that, but it's putting that plus the month old VBK (beginning of my chain) on tape.

Monthly old .vbk should be copied only once. After initial cycle, only one (virtual full backup) file should be created on tapes.

Thanks.

[namiko78]

I thought what I was copying to tape was an independent backup, and the synthetic option was somehow building a more up to take VBK file to be put on tape, by reading the VIB's. You're saying these are linked in some way to previous tape jobs? I'm not sure we're on the same page here, the support tech assigned to this case said she put in a feature request for the exact same thing i've just asked for. If you're telling me i'm wrong to be asking for it, and it's not a needed feature, then this is more confusing then I thought, because your support tech is also confused.

I've retargeted my jobs to my primary backup location, and recreated all the jobs as reverse incremental, which should solve this issue by only backing up the single, up to date, VBK. It's more of a pain thought because now I have to pause my large backup jobs while the tape jobs run, so it does not get stopped by the main job. Another feature request is in order.

Thanks

[RossFawcett]

I think what the OP is getting at is possibly a monthly tape job. I too am running into this issue. I have forever forward incremental on disk which has worked really well, avoids as much I/O as possible whilst giving me on dis 35 points of retention. What I want to do is at the end of every month, push that entire set to tape.

But without virtual full backup how would you deal with .vbk that gets updated constantly (when retention is reached), as well as, corresponding increments (one of which is deleted and one has its references to previous restore point changed)?

In an end of month situation, it just gets written to tape each month. Grab the entire set which consists of the full and all increments forward and dump the lot onto tape. And then next month do the same thing again.

I tried doing this as a pure files to tape but as soon as the regular night job kicked in, it killed the tape job. Really all I want is a monthly tape run to dump the current chain to tape. However with synthetic enabled I end up with two fulls on tape which is chewing through tape capacity.

[veremin]

The files to tape job seems to be the preferable option here, indeed. You said that the source backup job cycle killed the secondary job, but it would have killed even a backups to tape job if you had had one with virtual full backup disabled.

So, it appears to be the matter of tuning the schedule of source job, so that, the primary job doesn't interrupt the secondary one. That might be done either by playing with schedule or using pre-job activity which purpose would be let a source job wait till the files to tape job is finished.

Thanks.

[RossFawcett]

The files to tape job seems to be the preferable option here, indeed. You said that the source backup job cycle killed the secondary job, but it would have killed even a backups to tape job if you had had one with virtual full backup disabled.

So, it appears to be the matter of tuning the schedule of source job, so that, the primary job doesn't interrupt the secondary one. That might be done either by playing with schedule or using pre-job activity which purpose would be let a source job wait till the files to tape job is finished.

Thanks.

Is that in reference to my post? The problem with tuning the schedules is that the tape job alone takes something like 1-2 days.. Having to suspend my disk backup because the tape job is busy doesn't really work either. Surely there has to be a better way? It seems like such a simple thing to do, pickup this set put to tape once a month. As I noted in another post, I had hoped that VSS would have allowed this to occur, it was enabled. E.g. that VSS would take a snap so that the job could continue to write from that, and then the new files/writes occur as normal. Yes there would be some block change to track as the incremental is merged in, but surely this would only be the size of the merge not the entire full image so wouldn't be too big.

[veremin]

Do you run backups on weekends, as well? If not, it might be worth scheduling tape jobs to take place during weekends (a job should have enough time to finish its activities).

Also, are using standalone drive or robotic library? In the latter case, the parallel processing that we're going to introduce in version 9 should allow tape job to speed up its performance dramatically.

Thanks.

[mpjs]

Hi there, for a monthly backup where you want to backup the entire chain and disable the synthetic full to tape (virtual full), my work around was to just schedule the virtual full outside of my backup chain. So what I did was to schedule the virtual full tape to only run in December, the rest of the year (months) in the virtual full is disabled. This will cause a virtual full to only be created in December. When you get to December, just set the virtual full schedule for January, because your chain doesn't contain January dates the virtual full is still disabled. Hopes this makes sense. So the VBK and all VBIs will be backed up to tape when setting up a Backup To Tape job...no need for the file to tape job then! Works well if you want to have a monthly tape with all restore points for the month on tape and assuming a backup copy job or forever forward incremental. Else you will always end up with two VBKs on tape as soon as the retention expires on disk; because the oldest VBK has changed and a new VBK (synthetic) needs to be created at the end of the month. In this scenario I would recommend having an option to disable synthetic full tape jobs, or perhaps the option to configure backup to tape jobs to only backup the latest chain (always) in case you make use of active full backups to break the chain.

[Dima P.]

Else you will always end up with two VBKs on tape as soon as the retention expires on disk

You will get two .vbk's only in case your tape media retention is shorter than disk backup retention.

[alanbolte]

Alternatively, if Jan's disk retention is less than a month and the tape job is running monthly, it would write all data on disk to tape because there's a gap between what's on disk and what's on tape, even if nothing has been erased from tape. He gets the second VBK only if the job is allowed to run the virtual full. Forever-incremental jobs are something of a special case when it comes to backup to tape; there are a number of reasons why old data on disk may be copied to tape, and I'm not sure all of them have been fully documented.

[Dima P.]

I'm not sure all of them have been fully documented

We will start working on these right after v9 is released.

[mpjs]

Thanks

[Shunx239]

We will start working on these right after v9 is released.

It would be a great time to start!

[Dima P.]

Hello Nikolay,

Help Center was updated long ago and contains How-Tos for Machines Backup to Tape and Virtual Full Backup. Kindly take a look and let us know what would you like to add. Thanks!