Forever forward and synthesizing full to tape

[veremin]

Anyway, as mentioned above, the additional full backup will be copied only once, and, starting from that moment, only virtual full backup will be created. If those backups are located on different mediums, after initial backup to tape cycle you can even erase the tape containing the original full backup. Thanks.

[balocco]

Hi everybody,

hope you can help me understand and address my problem.
I have some backup jobs in forever incremental mode, daily schedule, 21 restore points.
I need a full backup to tape EVERYDAY, so I configured the tape job (I have a standalone LTO6 drive) in order to use Virtual Synthesized Full Backup (both FULL and INCREMENTAL checked in the Media Pool section of the tape job settings). First I created only one tape job and I configured it to create a full backup from monday to tuesday (saturday and sunday are non working days). The first week is ok, but starting from the second week, the job writes to tape 2 .vbk for every backup job. That's not ok because a single tape is not enough to contain all the data.
So I created a tape job for each week day, and every tape job create a Virtual Synthesized Full Backup for the day before: same problem... (look at the attached picture...)
Mediaset retention is 6 days (I use just 5 tapes, of for each day from monday to friday), after a week I want to overwrite the tape.



I just want that the last full is synthesized to tape, but seems that Veeam synthesized the last one and the vbk of one week before...

Thank you for helping me.

[Shestakov]

Hi Fabio, the behavior of having 2 copies of .vbk when using tape synthesized full is known and was described in the thread above.
Please review and ask questions if you have any. Thanks!

[balocco]

Hi Fabio, the behavior of having 2 copies of .vbk when using tape synthesized full is known and was described in the thread above.
Please review and ask questions if you have any. Thanks!

Hi Shestakov, really sorry for my mistake. Since English is not my language, I think I didn't get the meaning of the thread. Thank you.

[Shestakov]

No worries, Fabio
It happens even with native speakers.

[Treeeman]

There are also two .vbk files at Tape if execute manually a active full Backup combinded with Forward Incremental Forever Backup Jobs.
Sometimes i execute manually a Active Full to reduce storage Size of my .vbk. In this case i need more Space on Tape.
I still think it would be nice and helpful to be able to configure the syntetic full on Tape only to offload the latest restore point. No matter if this is a real active full or Syntetic Full Restore Point. Thanks.

[Dima P.]

Hi Treeeman,

offload the latest restore point

We have the similar request (place backup files to tape staring from the latest full)discussed in the separate thread – please wait for the next major release

[push3r]

There are also two .vbk files at Tape if execute manually a active full Backup combinded with Forward Incremental Forever Backup Jobs.
Sometimes i execute manually a Active Full to reduce storage Size of my .vbk. In this case i need more Space on Tape.
I still think it would be nice and helpful to be able to configure the syntetic full on Tape only to offload the latest restore point. No matter if this is a real active full or Syntetic Full Restore Point. Thanks.

Same issues here. I need to execute Active Full once a month (thus having two VBKs always) for Windows 2012 R2 deduplication best practice. However, this ends up messing with the Backup to Tape job with synthesized Full which puts 3 VBKs on tapes ( 2 from Active Full and 1 from Synthesized Vib). This is not gonna fly. I don't care about the older VBKs on tape.

Please add new feature so that on tape, store ONE VBK on tape, period! On that VBK file, use the latest VBK and the VIBs within that chain. And this should be allow for any Backup Job types.

[push3r]

You can make this really easy to understand by having the following options in the UI for the Backup to Tape Job.

1) Copy all files (vbk and vib) withing the Backup Job or Backup Copy Job
2) Copy all vbk files only.
3) Copy latest vbk only.
4) Copy latest vbk and inject vib from that chain.

[veremin]

All of listed options are already there. The fourth one might result in additional .vbk being copied. But, as Dmitry's mentioned, it has been already requested in the adjacent thread.

[krogerss]

I am currently using the forever forward incremental method Mon - Fri and the backups are copied to tape after the source job completes. Also, it is set to create a virtual synthetic full on tape on Fridays. My most recent backup on Tuesday ran and the tape job copied a the normal vib file, but it also copied a vbk that it said was "New." This particular vbk had already been copied to tape a about 3 weeks ago. The tape it was copied to is still offsite and has not been erased, nor has it expired yet. Any ideas why this would randomly occur? It's not the first time it's happened. Thanks.

[nielsengelen]

Are you using active full backups maybe?

[Shestakov]

Hello krogerss,
Do I understand correctly, backups work as expected, but sometimes the "random" 3-weeks old .vbk is copied on the tape?

The topic explains Forever forward backup + synthesizing full to tape behaviour and why VBR need an "additional" .vbk on tapes. Thanks!

[krogerss]

They work as expected for the most part. It just seems like from time to time a tape job will randomly grab other files and copy to tape. I don't understand why my tape job from last night copied a vbk from 6-12-2015 when this was already on tape.

[veremin]

The question is: was it on tape or is it still on tape?

[krogerss]

Its still on tape and not expired. Currently offsite.

[veremin]

And how media pool overwrite and mediaset settings look like?

[krogerss]

Retention is just set for 4 weeks. A new media set is created each day before backups start.

[veremin]

Then, the described behaviour doesn't seem expected. The corresponding backup appears to be still present inside the catalog, so, the fact that it got copied second should be investigated with the support team. Thanks.