guest file restore v.slow to open

[ejenner]

Hi guys,

Probably been seen before.

My most frequently requested restore location takes about 40 minutes to open the restore dialogue for a guest files restore. i.e. from when I select the restore point and press the 'finish' button it takes about 40 minutes to present me with a list of the restorable files.

It's a Windows Agent backup. Quite large. 35 restore points.

It seems to be a problem which gets worse as time passes. I've not reported it up to now as I felt some delay to open such a large backup was acceptable.. but as time moves on it is getting worse and 40 minutes is a bit excessive. Imagine if I got the wrong restore point and had to open a different restore point!

I'm sure there's a simple explanation.

[DGrinev]

Hi,

Can you provide a bit more details about the environment?
I.e. how far the agent from the repository, network parameters such as bandwidth, the backup file size, etc.

Thanks!

[foggy]

We're mostly interested in the servers (Veeam B&R backup server, console, repository/mount server) placement in relation to each other and where do you initiate the restore process? Also, does the actual restore takes considerable time or is performed decently?

[ejenner]

The restore process completes at a reasonable speed. All other restore operations are reasonably quick to initialize (i.e. some are slower.. but not to the point where you'd think there was anything wrong)

B&R server is a DL380 G9 with 64GB. Repository and mount server is the same but with more RAM, 96GB.

I think the point of note here is that this job works differently to others when we attempt to restore. The fileserver actually has a few backups. This one we're discussing is by far the biggest... but others are also large but you can set up a restore in well under 5 minutes... compared to 40 minutes for this one.

[foggy]

You didn't answer regarding servers location - the reason I'm asking is that for the purpose of browsing files during FLR the backup is mounted to the server from where the restore is initiated (either backup server itself or Veeam B&R console). If it is located remotely to the repository, this might cause the delay.

[Mgamerz]

I've found that it heavily depends on the amount of files in the original filesystem. Since Veeam is 'mounting' the backup to the filesystem, it is creating a bunch of file pointers to the backup file. On my client systems I can mount a backup typically in less than a minute, with some of the ones with bigger data sets in a couple minutes. My fileserver, which has tens of millions of files, it takes almost 40 minutes to mount a backup.

The backup chain length to the last full also has an impact too. Once my restores actually start (which can take quite some time) they cruise along pretty fast.

[foggy]

Yes, those are also factors that affect FLR performance along with some other - e.g. compression, storage optimization settings (block size). However, the sub-optimal relative position of the involved servers is what typically causes issues, so the first thing to check.

[ejenner]

Sorry, I didn't mention network or distances because we've got a very good backbone between sites.

I think what Mgamerz has said is most likely the explanation. Here's the properties for the folder in question:

[HannesK]

do you do "defragment and compact full" from time to time? With 10TB servers I have seen improvements from 45min to 2min.

[Egor Yakovlev]

It is not that much about files count, but rather total volume size. I can mount 27M(26,803,432) files server backup for File Level Restore operations under 2 minutes. It is just 100GB in size, though.
40 minutes session initialization looks quite long to me, so I would also check:
- if antivirus exceptions are set, especially for for C:\VeeamFLR
- if FLR Session logs are clear of errors \ timeouts \ retries (C:\Program Data\Veeam\Backup\FLRSessions\Windows\)
/Cheers!

[ejenner]

It's only this job affected. Other restore jobs perform as expected. So perhaps a "defragment and compact full" would be a good idea for getting things back on track.

[ejenner]

do you do "defragment and compact full" from time to time? With 10TB servers I have seen improvements from 45min to 2min.

This problem was resolved using the scheduled "defragment and compact full" option recommended by HannesK.