SUMMARY
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
ISSUE
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.
RESOLUTION
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.
TASKS
If you believe the files to be in the backup dataset, but you are unable to access it, use WinSCP or other SCP application to access the unitrends appliance directly, logging in using the OS root user, and browse our internal file system.
Browse to the path /backups/_flr (may be /_Stateless/backups/_flr on some UB appliances)
In this path you will find folders for active FLR objects. You may browse the volume map directly from this interface, and you can follow the path structure here behind the scenes. out internal root user may be able to access files that are not visible or not accessible via SMB or iSCSI as the current user levereged from the remote system. Using an SCP application, these files can be copied to your station.
Also be sure to review the original client system. if there are shortcuts, soft links, or junctions to other volumes in your client system, you will have to browse to their TRUE path, not the path the user typically locates those objects in. This can be common on Windows systems when dealing with some home folder path structures as well as redirected user containers in Windows Client OS.