Backup to Tape jobs and compression

[Dark-Sider]

Hey guys,

in our (not too big) backup infrastructure I have like 5 Backup-Jobs that backup let's say 50 VMs to a local disk based storage. The backups are replicated to a 2nd location. Also we recently added a TapeLibrary of even more protection.

From what I understand the backup to tape jobs restructure the backups when written to tape. They read the forever forward incremental jobs and create some sort of synthetic full on tape to then add the increments to a different media set.

I'm running our first backup to tape job that includes all our backup-to-disk-jobs. the combined size of all backups on disk is like 50TB, including all VBKs and VIBs. However it has already written >60TB to tape.

I did not enable hardware compression for the tape job, as the "to disk" jobs are already compressed. However due to the fact, that they are recombined to a synthetic full to tape, maybe they get decompressed and not recompressed? Any ideas about that?

regards,
Dark-Sider

[HannesK]

Hello,
your understanding is correct and hardware compression should be "off".

on disk is like 50TB, including all VBKs and VIBs. However it has already written >60TB to tape.

what is the Veeam support case number with more details (and logs) on this?

Thanks,
Hannes

[Dark-Sider]

Hi,

As the job completed normally (but consumed more tapes than anticipated) I did not (yet) open a support case, as the question to the answer might have been as simple as: turn on compression for the tape job as the data is not recompressed.

I can open a support a case on this.

regards,
Dark-Sider

[pegyK11]

I can open a support a case on this too

[veremin]

As the job completed normally (but consumed more tapes than anticipated) I did not (yet) open a support case, as the question to the answer might have been as simple as: turn on compression for the tape job as the data is not recompressed.

Since it's an initial job run there should not be any synthesized full created on tapes. Aren't you using dedupe appliance or ReFS (XFS) storage as primary repository? If not, then it makes sense to open a case with our support team and check why the same data occupies less space on repository than it does on tapes.

I can open a support a case on this too.

If you experience the same issue, then kindly do so.

Thanks!

[Dark-Sider]

Hi,

I just opened a case #05376716

I don't understand why there shouldn't be a synthesized full on tape? The underlying backup jobs are in use for quite some time now. The addition of the tape library was only recently. From what I understand the virtual full backup mechanic should apply https://helpcenter.veeam.com/docs/backu ... ml?ver=110

The backup repository is a local ReFS storage. If I do a file to tape for the VBKs and VIBs they consume the same amount of space on tape as they do on disk. If I do a backup to tape job it seems a bit inflated.

Edit: Oh FFS - I think I know what happened. I was just looking what backups were written to tape, and I now see that veeam backed up the initial Full backup (the one from the forever forward incremental job) all the increments and it also created an additional Full Backup on Saturday per that virtual backup rule. I probably need to check "keep only one full backup" within the job then?

regards,
Dark-Sider

[Dima P.]

Hey Dark-Sider,

From what I understand the backup to tape jobs restructure the backups when written to tape. They read the forever forward incremental jobs and create some sort of synthetic full on tape to then add the increments to a different media set.

The backup to tape in the question is pointed to regular media pool or GFS media pool?

I probably need to check "keep only one full backup" within the job then?

For non-GFS media pools / non-GFS tape jobs the first run will tape out all the backups from disk unless you check the box to process the back chain starting from the latest full backup.