Virtual Synthesized Full Backup for Tape and performance

[balocco]

Hi,

I changed all my backup jobs from Reverse Incremental to Forever Incremental (I created new backup jobs for Forever Incremental, so there are new backup chains on repository).
For company policies, I need a full backup on tape every night. Everything went well with Full backup to tape. But when processing incremental backup, Virtual Synthesized Full Backup for tape took a very long time.
To clarify:

- 1,5TB (full backup) to tape took about 5h.
- 1,5TB (Virtual Synthesized Full Backup) to tape, after 9 hours, is still at 30%, even if the reported processing rate is the same of full backup (80 MB/s)

Is it normal?

My configuration:
Veeam B&R v8 with patch01
Single Drive LTO6 SAS

Every suggestion will be appreciated.
Thank you.

[balocco]

Hi,

I want to refresh this topic.
After 12h, the Virtual Synthesized Full Backup tape job asked me to insert a new tape, because the first one was full (2,3TB)
That's impossible, the full backup of all VMs is about 1,5 TB...

Thank you

[McClane]

I also observed a much slower tape performance after switching to virt. synth. full backups at all customers I changed. I seems that the overall harddrive load is higher then with just the VBK.

The second problem seems to be a bug. Sometimes Veeam detects changes in the original VBK file in the chain and puts it onto tape, too. I have a case open for this and got a hotfix under 00732038.

[balocco]

The second problem seems to be a bug. Sometimes Veeam detects changes in the original VBK file in the chain and puts it onto tape, too. I have a case open for this and got a hotfix under 00732038.

Hi McClane, could you update this topic when your case will be closed? Thank you.

[Dima P.]

Hello guys,
I wonder if you have an enabled compression/encryption under the tape job settings. Also, if you use tape drive or library directly attached to the backup server, it’s worth testing the new data exchange mechanism - check the Performance enhancements part. In addition, I will consult with QA regarding the behavior you described.

[balocco]

Hello guys,
I wonder if you have an enabled compression/encryption under the tape job settings. Also, if you use tape drive or library directly attached to the backup server, it’s worth testing the new data exchange mechanism - check the Performance enhancements part. In addition, I will consult with QA regarding the behavior you described.

Hi Dmitry, thanks for your answer. Compression and encryption are both disabled (I never check compression with Veeam backup files, and I don't need encryption).
I'll make some tests with the new data exchange mechanism.

Even if I wrote "performance" on the topic title, that's not a real performance problem (I understood it only when I had already written the topic). The job took so much time because of the amount of data to be written to the tape. Data written on the tape were much bigger than a whole full backup and I think this is the real issue.

[veremin]

Once the tape job session was finished, was there only one .vbk file (that was bigger than a full backup) on tapes or there were other files as well? Thanks.

[balocco]

Once the tape job session was finished, was there only one .vbk file (that was bigger than a full backup) on tapes or there were other files as well? Thanks.

Hi Vladimir, I'm not able to answer. I stopped the job because it tooked 12 hours to write the first tape (2,4 TB) and only 2 of 7 of the linked backup jobs were processed.
I could try with a new temporary job with only 1 linked job to the tape job and crate a Virtual Synthesized Full Backup.

Anyway, before the job started, there were only 1 .vbk file and several .vib files for each backup jobs (forever incremental job)

[veremin]

Anyway, before the job started, there were only 1 .vbk file and several .vib files for each backup jobs (forever incremental job)

All those .vbks occupied less than 2.3 TB, right? Thanks.

[balocco]

All those .vbks occupied less than 2.3 TB, right? Thanks.

Yes, all .vbks are about 1,5 TB

[veremin]

Got it. The given situation looks unexpected. So, feel free to open a ticket with our support team in case the problem reoccurs. Thanks.