Veeam Tape job is marking double the size of a vm

[Foni_Shawn]

Hi all,

I encountered a very strange issue with the "Veeam backup and replication V8". Today I found a failed tape job and when checking i noticed that the disk jobs and tape jobs overlapped, thus the tape job failed.Then I started troubleshooting and discovered that the tape job took a lot longer than usual to finish because a specific vm had the size/read/transferred markings double than the actual size that really is present. I checked previous tape jobs from the report and they all matched the actual size, but this one doesn't. I checked the the actual vm and the size of 1.3TB marked by the tape job is not even possible because considering all the free space + used space it barely crosses the 1TB mark.

I would like to know if some of you encountered this strange issue and if possible what do you suggest to do ?

Thanks in advance,

Shawn.

[Foni_Shawn]

Current Config

We have a veeam daily save to disk backups, then we have a tape job which is set to backup the Veeam full backup files from the disk to the tape media.

When checking the source for the tape backup from one of the VMs' VBK file, it is around 700GB, but when seen from the tape job the data transferred in the log is shown to be 1.3 TB, this is exactly the size of the VMs datastore (overall size, not used or available).

If the vbk is only around 700GB, why is 1.3TB being transferred for this vbk? all other VM's Vbks in the tape job are being transferred normally with the right amounts of data.

Regards,

[iisics]

Dear all,

I am facing the exactly the same problem, from document, it shows that when I add the job by choosing "latest",
it will only backup the latest restore point to tape, but don't know why,
it sometimes backup two objects and sometimes backup only one object.

Support, can you explain? Please advise.

And also, it makes the backup to tape never finish!

Regards,

Ronald Ng

[veremin]

Guys, May I ask you to open tickets with our support team and provide case numbers here, so that, we can take a look at them and investigate the said issue closely? Thanks.

[iisics]

Guys, May I ask you to open tickets with our support team and provide case numbers here, so that, we can take a look at them and investigate the said issue closely? Thanks.

Created and support told me to recreate the tape backup job after finished the backup to DD, but the result still backup two synthetic full files to tape and makes most of the tape backup job unable to company within the backup windows. Anyway to go?

If any scripts can isolate the VBK from DD, please let me know.


And also, can I install OST plugin to the Veeam Server and let third party backup to tape application able to read the data from DD? Please advise.

[Dima P.]

Hi guys,
Quick question: are you both up to date with VBR Update 2?

iisics,

And also, can I install OST plugin to the Veeam Server and let third party backup to tape application able to read the data from DD? Please advise.

Unfortunately I can’t say anything about third party tool behavior. The only thing I can advise is to test such setup in the lab before putting in into production.

[iisics]

Yes, of course patch2.

[mattdwyerva]

Did you ever get this fixed?

This just started to happen to me (support case 01126083) using patch 3 (8.0.0.2084). Active full is 750 GB. Running forever incremental to disk daily with following tape backup that is SUPPOSEDLY syn full backup. Active full and 6 VIBs is maybe 850 GB, so this syn full at about 1500 is ludicrous and requires two LT0-5 tapes. Makes no sense to me

[veremin]

Can you clarify the following: is it one virtual full backup that occupies 1.5 TB or has a backup server decided to archive two full backups to tape, instead of one?

[mattdwyerva]

One syn full backup that is twice as big as it should be.

Tape job is defined to transfer full backup to tape from the ffi disk backup.

Worked fine for a week or so with no changes. This week it is twice the size for no reason. I can do a file copy to tape if syn full function does not work reliably, I guess.

I interrupted the prior tape backup - could that confuse vbr somehow?

[veremin]

Had a chat with QA team and they told me that they were not aware of this issue. Unfortunately, the OP didn't provide his support ticket number, so that, we can't follow the case and check the resolution, if any was found.

So, the only suggestion I have is to keep working with support engineer and let him find the root cause of the experienced behaviour.

Thanks.

[mattdwyerva]

FIXED. Here is what I learned last night.....

I started to wonder if my interrupting a tape backup (which features dire warnings by VBR) was the problem. So, I let it use two tapes to finish a tape backup yesterday (11/18), and then examined the tape properties. It had two correctly sized vbks on the tape, one from the 10th (which was the oldest VBK in the FFI disk repository directory), and one from the 18th. We then inserted a blank tape for the 19th, and the same tape backup job only used one tape, which has one VBK on it (labeled as being for the 19th).

Pretty sure that interrupting the tape backup was the cause of my headaches here.

[veremin]

Not sure whether I got that. Are you saying that job interruption resulted in two .vbks being archived or in one doubled in size.vbk ?

[alanbolte]

Could this be the issue instead?

Data Retention

When a forever incremental backup chain is the source, you can set any retention for tapes. However, keep in mind that the tape job must always have the original full backup in the tape archive. When the original full backup is removed from the catalog (for example, when the retention allows overwriting the tape), the tape job will re-backup the source full from disk. If the virtual full is scheduled on this day, the tape job will write the full from disk and the virtual full within one backup set.

[mattdwyerva]

Aha, Alan, you are correct! Bizarre logic - I have no idea why you would do that unless you don't trust your syn fulls? Why not just go with the defined retention period?

[mattdwyerva]

Not sure whether I got that. Are you saying that job interruption resulted in two .vbks being archived or in one doubled in size.vbk ?

Two - exactly as Alan notes in his post. So, interrupting the backup was irrelevant, but erasing the original tape was the relevant issue.

[veremin]

So, it turned that there were two .vbks archived to tapes. Not one, as you told me originally.

Can you clarify the following: is it one virtual full backup that occupies 1.5 TB or has a backup server decided to archive two full backups to tape, instead of one?

One syn full backup that is twice as big as it should be.

The described behaviour is expected. If the .vbk is still present on disk, but got removed from tapes, VB&R will try to copy it anew. Therefore, it's recommended to have tape retention longer than the disk one.

Anyway, ability to copy always the latest full backup will be added in version 9, if that's what you're looking for.

Thanks.

[mattdwyerva]

Yes, my prior post was not correct.

Does the VBR log report that it is copying two VBKs? I thought it simply said one was being processed, but perhaps I misread it?

[veremin]

Processed - might be, as currently such thing as tape parallel processing doesn't exist. However, in the beginning of backup to tape job session there should be mention that the job is about to archive two files. Thanks.

[mattdwyerva]

Job Tools - > Report pulls up the Veeam Session Report in browser. In upper right corner of large header box, it says "2 of 2 backups processed" every day regardless of activity including the first day. It then says "Success: 1" and lists file size (sometimes 749 and sometimes 1.5 TB). I suggest one more box that says "# of Files" (or have an optional "full details" selection that would include list of files and sizes copied to tape).

OTOH, right clicking Libraries->Media->Online and choosing properties illustrates exactly what is on the tape (and I should have done that previously), which is a very nice feature.