When performing FLR, there can be anomalies that make it appear files you expect to be in the file-system may not be visible. This article describes those conditions
When attempting file recovery of a VM, you are able to connect to a share or iSCSI connection to browse the recovered file system, but you find that some files or directories are not present.
The underlying issue is that the presented share and the user connecting to that share may have different permission expectations vs the original live file system. Share structures often cannot convey some aspects of filesystems, or, the user accessing that share might not have the same NTFS permission objects which might hide some data from view.
There are several possible causes for this behavior. The most common are:
- The user performing the restore does not have permission to the share to access those files
- Even if "show hidden files" is set, some files may still be invisible when accessed via SMB where they would be visible if locally browsing the directory structure. It may be necessary to use iSCSI connection to the restore point (which requires connection from a system that is not the original system backed up) to see such files.
- The files that "appear" present in that original system's path are in fact not actually in that path, and may be softlinks to the original file in some other path (common inside user profile folders or appdata folders in windows) When recovering from FLR the file will only be displayed/found in it's true directory path. This is most common when a folder on one volume references a file in a different volume. Soft-links in this type of shared recovery are restricted to the original volume only and cannot traverse across volumes.
- when accessing a Linux iSCSI FLR, it should be noted not all fileviewers are created equal. We have had success with diskinternals fileviewer where some others have not been able to see all files.
- the data you are seeking may not have been present at the point in time the backup of that system was initiated. You may need to locate older recovery points, or, it may be possible the file may not yet have been created in the current recovery point.
It's important to understand, the VM image is a block disk image. We do not protect files in a VM, only blocks. If the block map was rehydrated and presented, and is otherwise browseable, then the recovery is successful. Files could only be missing if the disk metadata itself were corrupt, and checks are made to ensure that is not the case. If there was damage to the filesystem records, the FLR would never have been successful to browse as we would be unable to mount the volume at all. The files are either not in the expected path, have permission differences that need to be overcome, or did not exist at the time of backup.