Slow file level restores from dedupe appliance

[cookiejc]

Hi, we have some large file servers which have Veeam backups stored on a dedupe appliance (NetApp Altavault). Mounting the backup for file level restores takes between 1-2 hours. Veeam support have previously advised that this is due to the time it takes to scan the entire backup file set. I noticed the following in the Svc.VeeamMount.log:

Source.DisableFullBlockRead = false

I was hoping this implied there's a way to set this value to "true" and stop the full block read prior to performing a restore?

[PTide]

Hi,

Please provide some details about your setup. What are the job settings, is encryption enabled? Do you have "Decompress backup data blocks before storing" check box selected in the repository settings?

Thanks

[csinetops]

That is odd. Are the backup sets sitting in local cache or are they out in the cloud and need to pull back down? I also have a AltaVault and just tested my biggest VM on there @ 3.8TB. A cached backup doing Windows FLR came up in under 5 minutes. I have dedupe and compression turned off and let the AltaVault handle that.

[foggy]

Elaborating on this, you could try to enable partial block reading (which is basically a default setting) via registry, provided backups are not encrypted and compression is not enabled.

[cookiejc]

Hi, thanks for your replies.

Compression, dedupe and encryption is turned off in the jobs as the Altavault does that. The "decompress backup data blocks before storing" setting is unticked in the repositories (as per the NetApp best practice they gave us)

These backups are still stored in cache as we haven't had to evict any data yet

These file servers are about 20TB each which doesn't help

foggy can you point me towards that registry setting?

thanks again

[foggy]

Try setting the DisableFullBlockRead value to 3 on the Veeam B&R server and restart the Veeam Backup Service.

[cookiejc]

Foggy, can you advise where that registry value is, or needs to be created?

[foggy]

The standard Veeam B&R hive is HKLM\SOFTWARE\Veeam\Veeam Backup and Replication. And the value type is DWORD.

[cookiejc]

I have looked in there and that key does not exist... does it need to be created to enforce this setting?

[foggy]

Correct, you need to create it.

[cookiejc]

Thanks I've now implemented this change and can see it has taken effect in the log but so far it looks like mount times are still slow. The log has got to this point and just stops... I expect it to take about an hour from this point:

Code: Select all

Source.DisableFullBlockRead = true\n  (EString) Processing.Part[0].Type = DynGroup\n  (EString) Processing.Part[0].GptDiskObjectPath = DynGroup-b2528697-0783-4072-8efd-95674944f8fb\n  (EString) Processing.Part[1].Type = OracleAsm\n  (EString) Processing.Part[2].Type = DiskIds\n}\n'

Any more ideas?

[foggy]

Actually partial block read doesn't affect mount process, it is effective during actual restore. While mount itself requires random reads from guest OS MFT and expected to be slow for large volumes with large amount of files and fragmented MFT, especially on a dedupe device.

[rreed]

What is your block size (job settings, Advanced, Storage, Storage Optimization)? In v8 we found cranking that up to Local Target 16+TB (largest block size) made a massive improvement on restores from a dedupe device. Compression off but inline dedupe on (you're only moving around the dedupe but the end device still finds some to do). I think they've made some improvements in v9 but we never went back to turn that down to confirm - it's always been working so we continue to leave well enough alone for now.

[foggy]

The block size doesn't really matter if blocks can be read partially.