Backup to Tape Job - Selecting Restore Points

[mongie]

Just wondering how restore points are selected when doing a backup to tape job.

I want to run the job each month, and take the latest VBK and write it to tape.

From my initial attempt, it seemed to write every full backup for each backup job in the backup repository.

Also... I use a dedupe appliance for my backup storage, so I use no compression, and I need to use hardware compression on the tape drive when I write my backups... is there any way to tell if this is actually happening? I tick the box, but the data processed and transfered in the veeam tape job window is the same, so it doesn't appear that any reduction is taking place.

[tfloor]

For forward incrementals : For a monthly tape backup, you can recreate your existing jobs, so i starts with only 1 full in the repository and then B&R knows which vbk's are already backupped or not. (don't select process incrementals in the media pool options).

Or you can create a seperate backup job with reverse incrementals, so that there is always only 1 vbk. And schedule that one once a month. (this will not process vbr to tape).

[veremin]

For now, there is no verification mechanism that can say whether hardware compression has been used or not. Providing that a tape device is capable of performing compression and you see that the files are not, actually, compressed, then, something might be wrong with the way VB&R instructs a tape appliance. So, I’d suggest opening a ticket with our support team and letting them investigate the causes of this behavior.

Thanks.

[mongie]

Tristan,

Are you saying that assuming I don't process incrementals, the backup to tape job will write any full backups in the backup chain to tape?

I think I can work with that for now, but it would be nice to be able to tick a box that says "only write the latest VBK to tape".

[veremin]

Are you saying that assuming I don't process incrementals, the backup to tape job will write any full backups in the backup chain to tape?

Hi, Alex.

Yep, in case of forward incremental backup mode, the tape job that is specified not to process incrementals will skip .vib files and copy only .vbk ones. In case of reversed incremental method, .vrb files are skipped by default regardless of incremental processing settings.

Thanks.

[mongie]

Can I suggest that not being able to limit to one VBK per "job" per tape job is quite a limitation.

A full backup of each of my regular jobs is ~ 30TB.

If I run a backup and there are two fulls, i'm going to be using a lot of tapes...

Does this work off the archive bit? or something like that?

Is there any way that I can mark older VBK's in the folders as "written" so that they aren't written to tape again?

[sbbots]

Just wondering how restore points are selected when doing a backup to tape job.
I want to run the job each month, and take the latest VBK and write it to tape.
From my initial attempt, it seemed to write every full backup for each backup job in the backup repository.

This is exactly the problem I ran into. I had to create a second repository and second backup job (to tape) just for monthly tape backups; Set to reverse incremental with 1 restore point. It is completely separate from the primary backups.

Seems like a good feature would be to setup regular incremental backups and in the same job be able to schedule a periodic tape backup that only takes the last full backup (as you said). As of now I have to run 2 separate jobs to accomplish this and I always have 1 extra full backup that is unnecessary (taking up precious space).

[tfloor]

This is exactly the problem I ran into. I had to create a second repository and second backup job (to tape) just for monthly tape backups; Set to reverse incremental with 1 restore point. It is completely separate from the primary backups.

Seems like a good feature would be to setup regular incremental backups and in the same job be able to schedule a periodic tape backup that only takes the last full backup (as you said). As of now I have to run 2 separate jobs to accomplish this and I always have 1 extra full backup that is unnecessary (taking up precious space).

Yep Good idea.
I'm on the same boat.

[veremin]

Hi, guys,

this feature request has been also discussed in the adjacent thread. And there a couple of workaround mentioned there, including usage of hardlinks; so, it might be worth taking a look.

Also, please be aware that there is a recognition mechanism implemented within one “backup to tape” job. That being said, the backup to tape job won’t copy all the .vbk files each time; instead, after initial run it will know what .vbks have been already copied and will copy only the new ones. Of course, it applies mostly to forward incremental mode, since, with reversed incremental one, there is always a new .vbk file after each backup cycle.

Thanks.

[mongie]

It still would be good to have as a feature...

[sbbots]

I will wait until it is a feature rather than use workarounds. Let me clarify what I want it to do:

Regular backup-to-disk:
Incremental - Mon, Tue, Wed, Thu
Synthetic full - Fri

Bi-monthly files-to-tape:
Copy most recent VBK from the same repository to tape - every 1st and 3rd Sat of each month

The object of this is to use only one backup repository, rather then having to use three (one for dailys, two for tape backups). I should be able to schedule the files-to-tape job(s) separately and it simply goes to the repository with all of my daily backups and grabs the most recent VBK. Also, keep in mind that this is a files-to-tape job, NOT a backups-to-tape, so the tape job is simply grabbing a Windows file specified as the most recent VBK.

Veeam gets this implemented and it would be perfect for those of us administering many remote sites.

[veremin]

Ok, I’ve got your point.

However, assuming this feature were implemented in “files to tape” job, instead of “backup to tape ”one, you would inevitably loose VM tracking functionality. That being said, you wouldn’t know on which tape medias particular VMs reside on, what medias would be required in order to restore certain VM, etc.

Thanks.

[sbbots]

However, assuming this feature were implemented in “files to tape” job, instead of “backup to tape ”one, you would inevitably loose VM tracking functionality. That being said, you wouldn’t know on which tape medias particular VMs reside on, what medias would be required in order to restore certain VM, etc.

Maybe now you understand why the Standard version is so handicapped regarding tape functionality. For a small company on a budget the cost difference for support each year is important; 6 hosts = Essentials Standard $4920 versus Essentials Enterprise $9000. That is over 80% more expensive to get backups-to-tape and restore point tracking.

That being said, for those of us "little guys" on a budget who use Standard you can go into your tape media pool and choose properties of any tape to see what files are on it. That is essentially your restore point tracking (well, along with good labels on the tapes). A simple option to "only copy most recent VBK" from the folder specified in the files-to-tape job would prevent us from having to create a second repository and second backup job. I could create one files-to-tape job that goes to my primary repository and copies only the most recent VBK. I save space on my NAS, I have a full backup on tape to take offsite and life is good.

[veremin]

I also believe that with the ability to change “source” settings of file to tape job in automatic fashion (PowerShell), the said task will become much easier. Anyway, thanks for the feedback; much appreciated. Thanks.