It was investigated and FLR had a problem with this path
Code: Select all
Code: Select all
lrwxrwxrwx 1 root root 1 May 5 2014 3.2.10 -> .
drwxr-xr-x 2 root root 4096 May 5 2014 bin
lrwxrwxrwx 1 root root 1 May 5 2014 default -> .
drwxr-xr-x 2 root root 4096 May 5 2014 init
lrwxrwxrwx 1 root root 1 May 5 2014 Modules -> .
drwxr-xr-x 3 root root 4096 Mar 6 2014 share
The only workaround was to follow http://www.veeam.com/kb1459
The support wanted to close the case but I wanted more investigation, since we use symlinks regularly on linux VMs.
This is the last answer from support in 5th of August 2015:
So it seems to be impossible to use FLR when symlinks are present. This is an old problem I encountered many times in other backup products, but up to date I do know only veeam that still cannot handle symlinks. I hope this will be resolved fast, but be informed that FLR will not work for you in that case. I did not test with junctions/mklink on Windows but I guess it will be similar.I have done some research regarding FLR. Current realization of FLR for Linux is focused towards user friendly interface. Once you mount the file system, FLR enumerates all the files in that system to display them in the GUI. Because of this enumeration complicated files with deep nested structure such as git repositories are hard to enumerate, resulting in FLR failure.
I am afraid with current realization the best way to restore such files would be instant recovery.
Veeam version 9 which is about to release is bringing new features for file restore, which might meet your needs for file level restore.
To be clear about the support: I was quite satisfied with the support analyzing the problem and helping me very fast. Now it's a either a bug to be fixed by the developers or something to be officially documented that veeams does not support.