Recently my mailbox restores seem to complete the restore of a mailbox on the exchange end but they are still running for days after in the NBU admin console. The thing is I cannot be sure if it was an actual full successful restore as I cannot view the entire size of the mailbox i am restoring to compare it to the size of what was restored, I simply wait 24 hours and if the MB size has not increased I have to take a it as finished.
An example would be a 1GB mailbox restore from disk running for 120 hours....
I am just wondering if anyone has come across this issue before and if so, any ideas?
Do you have client-side logs in the ncfgre and BEDS folders? Do you have a bprd log from the master server? If not, can you get them? (I'd like bprd at level 5 if you could.) These should give you some sense of whether the restore completed and the issue is only in coordinating the exit.
Are you starting the restore from a GUI or with bprestore? Are you starting it from the master server or the client?
How much mail are you restoring? Are you restoring selected folders and messages, or an entire mailbox?
What is your master server NetBackup version? What about the client?
I believe we turned off most of the logging before as the log files were taking up way too much space (cmd to check with putty?)
I always run the restore through the GUI whether it be the NBU admin console on my computer or Backup, Archive and Restore - NetBackup on one of the master servers, rarely restore on the client.
I cannot tell you the size of how much mail i am restoring as there is no easy way to see this, I can only tell you, in one such case, it was under 1GB and it was an entire mailbox.
Master server NBU Version: 7.7.2
Client NBU Version: 7.7.2
For restoring whole mailboxes, have you considered restoring the database to an RDB and harvesting the mail with Exchange tools? GRT - recreating each item one by one - seems like an inefficient way to accomplish your goal. It also seems to me to be unusual to need to do this with any frequency.
However, NetBackup shouldn't leave you wondering about job completion. Do you suppose you could turn on the logging for just one time? What's needed to paint a picture is bprd on the master, bpbrm on the media server, and ncfgre on the client. For the bprd log, you can grep for any pid that includes "restorefiles." In the bpbrm log, grep for the pid that executes nbgre.exe. Please provide those entire pids. Bprd will contain two such pids for each Exchange restore.
For this particular mailbox restore it will be attached to a current users mailbox for them to peruse so I am not sure your suggested way would work? Also, I do not have exchange server access but have nver needed it before.
I have tried narrowing down the restore by drilling down to just one image, it was faster but again, the job kept running in NBU endlessely.
I will have a new blank mailbox created and test on my own account with a restore with logs turned on. I do most work through the GUI so what would be the easiest way to turn on the logging of what you have requested there?
For bprd log: Host properties, master servers, <server>, Logging, BPRD logging level = 5
For bpbrm log: Host properties, media servers, <server>, Logging, BPBRM logging level = 5
(Both can be done together if your master and media servers are the same.)
You do NOT need to restart services after making these changes.
For nblbc log, you need to set logging for the DAG node (mailbox server) where the restore will run. The easiest way is via the BAR GUI on the client, because you directly choose the server to log onto. On the File menu, select NetBackup Client Properties. On the Troubleshooting tab, set both logging levels to their maxima (2 and 5).
If you can't run the BAR GUI on the client, choose Actions, Configure Client from the NetBackup Console menu, and give the DAG node name as the client.). Then set Logging in the general section to 5 and check the Enable robust logging option, and also in the Windows Client section, Client Setting screen, set Additional Logging Levels, General level to 2.
After this, if you want to turn down logging for some VxUL processes, you can do so by OID. Nbgre is OID 352. I haven't done this much, so I hesitate to give detailed steps. I've not contemplated whether it would work to set only the OID 352 level to 5 without turning up the two general logging levels as described in the previous paragraph.