Very slow restore of Vsphere VM (Full Restore) from Tape

[mcdaniels]

Hello,

we have switched to Veeam Backup to tape. (from Arcserve Backup).

Backing up files is running really fast -> about 300 MB / sec (Filebackup and VMWARE Backup).

We now try to restore a 30GB VM directly to the ESXI Host. To be honest, I was shocked, looking at the data transfer rate.
It is running at 800kb/sec and tell me that the restore (of the VM) is ready in about 7 hours!

When thinking, that we have to restore 4TB in a worst case scenario, I am feeling pretty lost. I mean, how long will this take, if the datarates are also that slow.

Specs
We use one LTO8 drive
Monday: Full Backup
rest of the weekdays: incrementals
The backupdrive is directly attached to the server where Veeam is running on

Backupdetails
Backup is done via mediasets starting new mediaset on Monday
The testrestore we do is from yesterday
Veeam needed all tapes from monday till yesterday do start the restore
We used "Restore directly from tape" and NOT "Restore through a staging backup repository"

Old Backupsoftware
As said above, we used Arcserve Backup before on this machine. The software itself is not uninstalled till now, but all services of Arcserve Backup are stopped and disabled. We do not want to remove Arcserve completly until Veeam B&R works as expected.

Veeam Version
Build: 11.0.1.1261
Edition: Enterprise Plus


What might be wrong here?

Thanks!

[PetrM]

Hello,

It's difficult to say what might be wrong without debug logs analysis because what you describe sounds like a technical issue. The best action plan would be to open a support case and ask our engineers to find out the root cause of this performance problem. You may share a support case ID over here for our reference.

Thanks!

[mcdaniels]

Hi,
yeah thanks. We opened a case.
ID 06083027

We just tried: Tape to Disc (Transferrate: 180-200MB/Sec) and then
via VeeamZIP (from disc) to Full Restore ESXI Host (500MB/Sec)

So it had to be an issue with the direct restore from tape to ESXI Host.

All other transfers are fast and in fact partly very fast.

[PetrM]

Hello,

Did you try to select an appropriate proxy server at this step of the wizard ("pick proxy to use") ? My guess is that the slowest operation is data writing, maybe a proxy from another location, site or network segment is used. For example, you can specify a VM on the target ESXi host to act as a restore proxy, I think it will perform better in HotAdd mode.

Thanks!

[MartinO]

If you have the tape capacity to do it, we would always do a full backup to tape every day. That way you're not reliant on a chain of tapes to be able to get your VM back. Performance should improve as well as it can read the entire VM sequentially.

[mcdaniels]

I am on this problem with support now. Support told me that the files on the tape are very fragmented. We use a Backupjob with 4 VMs in it. I now should try to backup a single vm to tape and see whether it is faster or not.

We are using a 2 proxys.

[david.domask]

Hi @mcdaniels,

I'll check on the case, but looks like it may be expected in some situations. Please see the note on this section of the User Guide: https://helpcenter.veeam.com/docs/backu ... astructure

In general, staging to repository first improves the speeds a lot as there is less seeking on the tapes required, but I get this isn't always feasible.

[mcdaniels]

Hello,
I now tried to backup one single VM to disc and then to tape. After that I restored the disc from tape directly to our ESXI.

Doing this was much faster (up to 500MB/sec).

So my conclusion is, that we have 2 options:

Do single backupjobs to tape for each VM and then
do the tapebackup

OR

use a staging device (e.g. the backuprepo) to restore from tape to that repo and then from the repo to the ESXI.

[david.domask]

Glad to hear that we're on the right track. I also can mention a third option: single jobs for your most critical machines done without parallel processing. That should result in pretty decent speeds for your most critical machines, and the rest can have a larger SLA period for restore.