FLR can see some files and not others

[atg]

I have a case open on this but was looking to see if the community had any ideas also.
During FLR, the GUI can see some files and directories but for others when I click on a directory, no files are there ( even though they are on the actual machine ).
When I do an instant recovery, I can see these files but course that takes more time to execute.
Has anyone had this issue?

I thought maybe it was permissions issue but the same problem exists for two directories that are root root as well as mysql mysql.
And some of other the directories that are root root I can see.

I am pretty sure when we do a FLR in the GUI it is looking at what is stored on the repo. I really can't think of why this is occuring.
My case number is 04266115.

Thanks,
David

[soncscy]

Hey David,

By chance, are these directories like loop devices or some externally mounted device? Basically anything that isn't just sitting as data on a VMDK? From what I've come to learn with Veeam, the file level restores literally just access VMDK disks through the vdk driver (if I get it right) and parse the contents that way. If you have some device that is only mountable/readable via some OS mechanism (e.g. iscsi, loop devices), the file level restores will not see this since the OS isn't active at that time to be able to mount the devices.

Basically, any external device mounted will do something "like" this.

[tsightler]

My guess, is, because you say it works when you perform an instant restore, that these folders are actually separate mount points which are, for whatever reason, not being mounted automatically during the FLR process. Can you verify if these are separate mounts in the production system?

The Veeam FLR process just starts a Linux helper machine and mounts the disk images, these are literally the same disk images and same method used for Instant Restore, so it really shouldn't be possible for files to be missing if all the files are on the same disk, but there can be cases where mount points aren't properly parsed and mounted, or perhaps a mount point using a filesystem that not currently supported or a newer version that what is supported by the FLR helper appliance.

If it's just a matter that the FLR UI couldn't figure out the proper mount points then the files you are looking for may simply be in disk nodes show under root rather than in their "proper" location. For example, in my lab I have an Oracle server where the Oracle home directory is mounted under /u01 on the production system. If I start the Linux FLR and browse to the /u01 directory from the root, it will be empty. However, in addition to the root (/) node, there is also another node, sda1, and if I expand this node, it's all the files that should normally be under /u01, but the FLR process just didn't have enough information to know that it should be mounted under /u01.