Putting forward incremental backup to tape

[US2015]

Hi All,

I am finding a way to put approx 10 TB of backup with 40 GB incremental each day to tape.
As I am using forward incremental as a backup method, my tape backup is failing when veeam merges the previous incremental.

Just wondering is there a way of getting it work without postponing normal backup routine.

Regards,
US2015

[Shestakov]

Hi!
Do you have any synthetic or active full backups scheduled in the source job? If no, you backup-to-tape job has Virtual Full Backups.

The way to simply have Full+incrementals is to point tape job to a simply forward incremental job,
Thanks!

[veremin]

What tape job are you using? Backups to tape or files to tape? Thanks.

[US2015]

Thanks Guys,
Shestakov,
Mine was failing during the merge time even after pointing tape job to forward incremental job.
I'll give it again and see today.
v.Eremin,
I am using backup to tape job.

Thanks Once Again
US2015

[RossFawcett]

Hi!
Do you have any synthetic or active full backups scheduled in the source job? If no, you backup-to-tape job has Virtual Full Backups.

The way to simply have Full+incrementals is to point tape job to a simply forward incremental job,
Thanks!

I've been looking at this today and if I do this I end up with two fulls on tape. The original full at the start of the chain plus a synthetic one. This is a bit frustrating as I simply want to push the current chain + a single full to tape monthly. Reading the documentation implies that after the first one it should be ok, but that means my first run uses double the amount of tape, and again if the job is ever re-created for any reason.

Is there not a way to just dump either the synth + increments only? Or just the original and no synth when using a forever forward source?

[Shestakov]

Ross, to have simple retention on tapes enable full backups on the source job.
More info is in this topic.

[RossFawcett]

Ross, to have simple retention on tapes enable full backups on the source job.
More info is in this topic.

That's all well and good if you have the space to do that. So what you are saying is that basically we have to either significantly increase our backup storage, or move back to a reverse incremental with its rather hefty I/O impact? Not the greatest solution to be honest. All we want to be able to do is pickup the current set and dump it to tape.

I did try pushing just the complete set of files, but when the next job ran whilst the tape was busy it failed, even with VSS enabled which I had hoped would have allowed this to work as it would have been part of the snapshot. But I suspect the amount of block change that rolled through when the incremental was merged in caused it some problems.

Maybe take this on as a feature request?

[Shestakov]

Ross, reverse incremental is not recommended if you want to copy on tapes using this job as a source. Merge operations on tapes are very tricky and require more resources. It`s much easier to have random reads on disk.
Could you specify your goal? Am I correct saying that you want only 1 .vbk on disk and only 1 .vbk on tapes? What about retention on tapes?
Thanks!
EDIT My colleague prompted that you are discussing same issue in the parallel topic.
For those who are interested.

[RossFawcett]

End goal is fairly simple. One VBK on disk with approx 30-35 days retention. And then monthly push that entire set to tape.

The problem is it takes nearly two days at the moment to roll that set to tape due to it's size. And we run backups every day, so there isn't really a weekend opportunity for this as the disk backup is always running as they operate 24/7. We have approx 25TB of usable disk for backups, a full backup of everything runs about 15TB. We don't have the room to maintain two fulls on disk at this stage. We are running LTO5 with an auto loader.

The tape is basically to ensure we meet the business/legal requirements to have an offsite copy and those sets will be retained for an extended retention.

It just seems like a fairly simple ask, pickup this entire set, put it to tape, job done. Nothing complex, no weird retention settings, just blat it out to tape. If you can build a virtual synthetic to tape, surely the ground work is there to be able to support just dumping a full or a full + incremental from that point forward to tape?

[Shestakov]

Thanks for the reply, I see your point.
But since your job is running more than a day and being interrupted by the source job run, the way to go for you is to disable the source job for one day, giving the tape job time to finish. File-to-tape job works just like you said, it copies existing files on the tape. But if the files are being changed, the job stops, which seems logical.
However, your suggestion is clear and we will take it into consideration. Thanks!

[mpjs]

Hi, to backup the entire monthly chain to tape. "Disable" the synthetic full, by scheduling it outside your chain, example. We are in December so set the synthetic full (tape) schedule for January. This way your backup chain will be sent to tape without created a virtual full because it is scheduled to only run in January. If you get to January and don't want synthetic full backup just move it onlto February...sure with some powershell script you can automate as you get to each new month.

[veremin]

The problem Ross experiences is that a backup to tape job runs too long and gets interrupted when a source backup job starts, so, not sure whether the tweaking a virtual backup schedule would allow him to bypass that anyhow. Thanks.

[mpjs]

It sounds like the reason Ross experiences a tape job running long is because the Full + Increments + Virtual Full is being written to tape so in essence a two full backups being written to tape. And from what I gather he just wants the entire change without a Virtual Full. Regards

[veremin]

Based on what he's described in the adjacent, even with one full backup copied (files to tape job) the job failed to finish in the allocated time interval. Thus, my post.

Anyway, I got your idea, thank you sharing; appreciated.Based on what he's described in the adjacent, even with one full backup copied (files to tape job) the job failed to finish in the allocated time interval. Thus, my post.

Anyway, I got your idea, thank you sharing; appreciated.