It was investigated and FLR had a problem with this path
- Code: Select all
The path is not that long, but those folders contains symlinks which refers to the parent directory, the real path is below:
- Code: Select all
Then, the folder is composed by the following tree structure:
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:
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.
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.
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.