KB301910 PS Warning & Results

Question

Hi All, 
 I am running the PS script to check my recovery points and saw the following (in yellow) warning- 
 WARN 2019-08-14T08:33:27 Performance.Replay.Core.Client.LocalMountMana Execute Action DELETE https://MY SERVER HERE:8006/apprecovery/api/core/mounts e9-80f2-40a8f01fc3b3%257d~|~ took 00:01:02.8944452, which is too long 
 Also they are not very clear about results and log checking for the script. I think I found and fixed this issue on my own with help from here just after I upgraded but I'm checking anyway but they could be a little clearer about reading results. 
 Thanks.

Tim Seymour · Answer

The issue is not just with OS volumes. The issue can occur on any volume on the system. It is most common on the OS volume, but not exclusive to it. 
 The issue is that if the change log file is greater than 1 MB in size when the upgrade occurs, anything over 1 MB is dropped. So we basically drop some of the tracked changes in the conversion to the new format. So if you have a data volume with lots of change on it resulting in a log file greater than 1 MB when you performed the agent upgrade, then some of the change on that volume was lost. This means the next recovery point contains incomplete data. That means part of the file system within the recovery point is corrupted. If you then mount that recovery point and run chkdsk on it, it will show up as corrupted. 
 When dealing with Rapid Recovery backups, there are two file systems. One is the proprietary format that RR uses to store the data and create mount points. The other is the actual NTFS (or any other file system) that exists within the mounted recovery point. It is possible for the recovery point file system to be complete and functional (meaning we can mount a recovery point) but the NTFS file system within the mount point to be damaged. This issue is an example of just that. Hence running a chkdsk of the file system within a recovery point is a very simple and complete method for identifying issues with the data. If chkdsk passes on the mounted recovery point, then the file system checks out as complete and the backup is complete. 
 The temp mounts are being mounted in the directory where the script lives. That's the default behavior. If you look at the available parameters within the header of the script, you can see there is a -mountPointsBasePath option where you can point the mounts to a different location. So if you have an OS drive on your core server with very little space, you could point the mounts to a secondary location that has more space. 
 Deleting mount points means exactly the same thing as dismounting them. There is no difference in the function. It's semantics.