Folders not 'visible' for granular restore from FlashBackup-Windows policy
This is the current configuration for this backup client.
Backup client: Windows 2008 R2 x64 w/NetBackup 18.104.22.168
NetBackup: NetBackup 22.214.171.124
The backup client has a rather large volume (D:) that is approximately 5.6TB and contains close to 40 million files. We are backing this volume up differently than the OS volume due to it's size and content. We are currently running a full FlashBackup-Windows job monthly, running weekly cumulatives, and daily differentials. In attempting to restore specific files from this backup image, it was noticed that while the size of the job indicates that indeed, the entire volume backed up, selecting certain files for a granular restore is not possible. ***There is a single folder in the root of that volume that contains the vast majority of the 5.6TB of data. Its named "vol" and is not listed as a folder in the FULL FlashBackup-Windows backup image from either the BAR gui on Windows machines, or the Java gui on either Windows or Linux machines. Interestingly enough, it IS listed in the cumulative and differential INCREMENTAL backups however...***
I am attempting to set up a new, temporary client that I can restore the entire raw partition image to just to confirm that the folders are being backed up and that in a DR scenario, we would be able to recover the entire volume, however even if that is the case, granular restores will be rather cumbersome unless we can get this ironed out. Symantec currently IS working on this as I opened a support case when I originally thought that the backup was just somehow missing that folder, but I have updated Symantec Support that it appears the "file mapping" aspect of the FlashBackup-Windows policy is failing in this particular case. I've shared this issue with the community because we're all very good at solving complex issues, and if anyone else runs into this, it would be nice to be able to find the solution without having to jump through the Symantec Support hoops. Once resolved, if resolved, I will certainly update this post.
To try and head off the little stuff, I will confirm that we checked and double-checked that there were no exclusion issues. We re-created the policy from scratch to confirm that there were no policy "corruption" issues that we were running into, and the problem persists. My guess is that it may possible be due to the folder-depth or sheer size that is causing the process to fail, but until I can do the restore test, its all conjecture. I also know that this will be much less painful if the customer were to segment their data somewhat, and that is one of my recommendations but is something to be addressed after this 'restorability' issue is resolved. I also have upgraded the NetBackup client to 126.96.36.199 but as it takes about 18hrs to run this particular backup, I don't know if that has resolved it yet...
I've attached screen-scrapes of the drive size and its folder contents from the Windows client, the full restore as well as the incremental restore views from BAR to help show that the 'vol' folder is not visible or selectable to restore from the full FlashBackup-Windows backup but is in the smaller incrementals.
Hopefully, someone has run across this before and can provide some insight.