Restoring a file from the CentOS, partition 8 TB, many files

[ahk]

My support case number was 01951012.
There is a problem with the restoration of a file from CentOS7, which resulted in the updating of Veeam to an open request and a violation of his work.

/dev/mapper/vg_mail-lv_mail 8.0T 7.1T 983G 89% /lv_mail
cd /lv_mail/Domains/FQDN
ls |wc
13748 13748 208406

When you try to open a directory expectation lasts and lasts, there is no result, and I need to choose a specific subdirectory for recovery.

In the course of solving health problems revealed that veeam recorded in the registry branch on the proxy server a huge amount of information. Export branches totaled 500 MB of disk space! Removing branches recover. Case closed. The file is not attached, encouraged developers to write on the forum.

df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/vg_mail-lv_mail 1717983616 281106 1717702510 1% /lv_mail

Is information about each file is written to the registry? Or is it a bug? If you need export branches, specify where to put.

I am waiting for the opening of the catalog for more than half an hour, not even sure there is still work (fully admit that a very slow process) or long ago hung.

[cby]

Not sure if this applicable to your post but might help...

Restoring individual files from a Linux backup via FLR can be a real pain when the file in question is in a directory containing many files. And by many files it's a few hundred rather than thousands as far as Veeam is concerned!

I have often ignored FLR and restored the entire VM to a temp datastore, assigned identical VLAN and IP addressing in the same subnet and copied the target file from restored VM to production VM (in different area naturally). There are of course potential issues with running a copy VM, like background tasks kicking in and mailing supplier orders!

Even when successfully running a file restore it is still often much quicker to restore the entire VM. I found that LVM systems are the slowest when when it comes to restoring via FLR.

[PTide]

Hi,

Not sure if this applicable to your post but might help...

The approach that you've suggested is valid, however a similar one has been already decsribed here, but thanks for the input anyway

While QA team is investigating case #01951012 could you please share the details about your LinuxFLR scenario so we can collect more of data that might be useful?

Thanks

[ahk]

[ID# 01952499] Other OS FLR not working

[cby]

PTide, A bit round the houses using Instant VM recovery -- prefer my solution

[ahk]

PTide, A bit round the houses using Instant VM recovery -- prefer my solution

1. Mine too.
2. There is a suspicion that the problem started after the indexing of files in the server. Prior to that, everything worked smoothly with the same machine with the same characteristics.

[PTide]

A bit round the houses using Instant VM recovery -- prefer my solution

I agree that the workaround from the KB looks somewhat complex, but my point was that Instant Recovery is faster than a simple restore and allows you to perform all of the operations that you've described.