Looking to improve my restore rates- a couple of questions

[aeccles]

I've been doing some restore testing and I would like to improve the restore rates if possible.


#1 ) If I enable "Decompress backup data blocks before storing" on my target repository, will this typically improve the restore rate?

#2 ) Assuming the hardware I backup from and restore to is identical, should my restore rates be similar to my backup rates? Currently, my restore rate is about 30% slower than my backup rate. The hardware is a little different so I'm wondering if this is primarily a result of the difference in hardware or the additional load required to work with incrementals

#3) Is there anyway to get the "load" information on restore jobs? I'd like to see the Source / Proxy / Network / Target values to see if anything stands out.

Thanks!

[foggy]

#1 ) If I enable "Decompress backup data blocks before storing" on my target repository, will this typically improve the restore rate?

With this option enabled, Veeam B&R will not have to perform decompression of backup files on restore, however this operation will be performed during backup. You can disable compression completely, though (keeping space/bandwidth issues in mind).

#2 ) Assuming the hardware I backup from and restore to is identical, should my restore rates be similar to my backup rates? Currently, my restore rate is about 30% slower than my backup rate. The hardware is a little different so I'm wondering if this is primarily a result of the difference in hardware or the additional load required to work with incrementals

I would not compare backup and restore times in general, there are too many factors that make this comparison more like an "apples to oranges" one (different amount of read/write operations required, data transfer is performed via different protocols/interfaces, VSS freeze, etc.).

Btw, could you please describe your setup in a bit more details? Source/target/proxies, transport modes used for backup and restore tasks? Probably we could give you a couple of advises on how to improve your restore times.

#3) Is there anyway to get the "load" information on restore jobs? I'd like to see the Source / Proxy / Network / Target values to see if anything stands out.

Currently bottleneck stats are not available for restore tasks.

[aeccles]

With this option enabled, Veeam B&R will not have to perform decompression of backup files on restore, however this operation will be performed during backup. You can disable compression completely, though (keeping space/bandwidth issues in mind).

OK, this is for a backup copy job. Is there anything different or special about decompressing on those? Does the original backup job have to be decompressed as well?

I would not compare backup and restore times in general, there are too many factors that make this comparison more like an "apples to oranges" one (different amount of read/write operations required, data transfer is performed via different protocols/interfaces, VSS freeze, etc.).

Btw, could you please describe your setup in a bit more details? Source/target/proxies, transport modes used for backup and restore tasks? Probably we could give you a couple of advises on how to improve your restore times.

OK, thanks. I'll follow up on this portion in a few weeks. We're currently making some changes that we know will improve things (switching from NBD to SAN mode), increasing the RAM in the server performing the restore, etc.

Currently bottleneck stats are not available for restore tasks.

OK, thanks

[veremin]

We're currently making some changes that we know will improve things (switching from NBD to SAN mode)

Be aware that it's not possible to use Direct SAN mode during restore. However, what you can do in is to add virtual proxy and use a Hot Add proxy for restoration activity. Chances are, the current rates would be improved. Thanks.

[Vitaliy S.]

OK, this is for a backup copy job. Is there anything different or special about decompressing on those? Does the original backup job have to be decompressed as well?

Nothing different in terms of compression algorithms between these jobs. No, it should not.

[foggy]

By default, backup copy job keeps the original backup job compression level for its backup files, but you can set any other if you need, as well as configure decompression on its target repository.