file level restore from 10tb disk not working

[SmokinJoe]

Hi All,

I am using server 2019 and Backup and replication 11.0.0.837 P20210525 with SQL Express.

When I try to restore a single file from a 12tb drive F: it never shows up, only C and E. When I restore the whole server the disk is there and I can get my file.

Thanks,
Joe

[rennerstefan]

Hi joe,

Sorry to hear. It’s something I’d also recommend our support to have a look.
did you already open a ticket and can you share the ticket ID here?

Thanks

[SmokinJoe]

Case 05311836

[rennerstefan]

Hi Joe,

thanks for sharing the case ID.
I see that it is already closed.
If the issue still exists please re-open the case and upload the log files.
support needs to have a look.

Thanks

[SmokinJoe]

Hi Rennerstefan,

I have another case to restore files and I have upgraded to 11.0.1.1261 P20220302 and have the same issue. Could it be I need SQL Server and not the lesser SQL Express?

I will re-open the ticket.

Thanks,
Joe

[david.domask]

Hey Joe,

SQL edition has no direct relevance to the File Level Restore (FLR) process, as the disks are mounted live during FLR and then read.

Support case is best so we can see what happens during the mounting; a few of the most common causes are:

- Spanned disks that did not get backed up with Application Aware Processing (spanning disks in VM is usually not a great idea as is)
- Issue with Mount Server (switching to another mount server is a very simple and "cheap" test if you have another to try with)
- Volume is backed by a non-snapshottable disk, so it was not backed up (e.g., in-guest iscsi disks or RDMs)
- Non-standard filesystem in use for Windows (e.g., EXT4, HFS+ or APFS)

There are many more reasons; that it showed during the entire VM restore makes me think there is a special set up for F: volume, so you will want to include details on the volume from Disk Manager on the production machine and the backup logs for this machine just to check if there were issues with the backup process itself.

[SmokinJoe]

I figured it out.

I was running a virtual VEEAM server with 12gb of RAM, I tried to bump it up to 36 gb and had similar issues. Once at 96gb of RAM I have a working restore! So the restore process when doing a
Restore/VMware vSphere.../Restore from Backup/Guest files restore/Microsoft Windows.../pick my "job name"/pick my 1 of 21 restore points/Next/Next/Browse

Yay! I have a 12tb volume to browse and get my users files!

This is what Process explorer showed, I think I was running out of disk swap area and the app was exiting.

Thanks,
Joe

[david.domask]

Interesting! Thanks for sharing. To be honest, I actually think that's a bit high for the RAM amount (It should not need nearly that much) so indeed swapping might be part of the equation. I would wager you can lower that drastically.

If you've got the space for it and the chain is a Forever Forward or Reverse Incremental, you might try a Compact Full and then test again with lower RAM. That might help.

[SmokinJoe]

Well I think if I had 500 gb on c: drive and swap was set to "managed by OS" it would have taken a LONG time but it might have worked with 15gb of RAM.

I am only doing 21 days, Incremental(recommended), "defrag and compact full backup file weekly" on Friday. I have a GFS tape job as a secondary target that does daily every day and weekly on Sunday.

Case 05311836

[david.domask]

Hi SmokinJoe,

Thanks for sharing the case, but regrettably, without logs on the case, it's very difficult to assess what was happening on the system during the mounts. I'm glad you found a workaround and if it's suitable for you, there's of course no harm in using it, but if you're willing to revisit it in the future, I'd ask you open a new case, reproduce the issue noting the VM in question and date/time of the test, then export logs from the VBR Server (https://veeam.com/kb1832, use the 3rd radio option and select the VBR server itself)

But if you're content with the workaround, then of course no need to take up more of your time.

[SmokinJoe]

Hi David,

I will update the logs on that case. I would rather not have a 500gb c: drive or 100gb of ram to restore a file.

Thanks,
Joe

[david.domask]

Thank you! Let's see what we can find. Looks like the original case was auto-closed by the CRM due to no updates (I'm assuming this is when you got your workaround in place), so if possible, please open a new case with the above details. Feel free to PM me the case so I can check on it.

[SmokinJoe]

Well the plot thickens, I added 150gb of disk space to drive C: and I get a failure, 100gb of RAM and at least I can browse to restore an individual file.