Error nbjm (pid=9600) NBU status: 2107, EMM status: Requested media server does not have credentials
Mar4,202112:20:43PM-beginDuplicate Mar4,202112:20:43PM-requestingresourceLCM_Silver.BoDataNBU-stu Mar4,202112:20:43PM-grantedresourceLCM_Silver.BoDataNBU-stu Mar4,202112:20:43PM-startedprocessRUNCMD(pid=3564) Mar4,202112:20:43PM-endedprocess0(pid=3564) Mar4,202112:20:43PM-requestingresourceSilver.BoDataNBU-stu Mar4,202112:20:43PM-requestingresource@aaabf Mar4,202112:20:43PM-reservingresource@aaabf Mar4,202112:20:43PM-Errornbjm(pid=9600)NBUstatus:2107,EMMstatus:Requestedmediaserverdoesnothavecredentialsorisnotconfiguredforthestorageserver Mar4,202112:20:43PM-Errornbjm(pid=9600)NBUstatus:2107,EMMstatus:Requestedmediaserverdoesnothavecredentialsorisnotconfiguredforthestorageserver Mar4,202112:20:43PM-Errornbjm(pid=9600)NBUstatus:2107,EMMstatus:Requestedmediaserverdoesnothavecredentialsorisnotconfiguredforthestorageserver Mar4,202112:20:44PM-endDuplicate;elapsedtime0:00:01 Requestedmediaserverdoesnothavecredentialsorisnotconfiguredforthestorageserver (2107) I checked the credentials that it was added on two servers (master + media server) as image The storage servers has been configured as image. How to solve this problem?
Cloud Catalyst - How it works
Hi Guys, We tried to initially full backup the flat files from on-premise to cloud and the slp process is backup going to MSDP then duplicate to AWS s3 with cloud catalyst appliance. Im confuse because the raw size of files is 9 GB then after it backup to MSDP and duplicate to AWS s3 with cloud catalyst the size is the same. How the MSDP and catalyst works if we full backup again the same set of files?
EMM_DATA.db - huge size can't be reduced
Dear All, I recently got stuck with an issue where the size of my EMM_DATA.db has grown enormously and I can't find a way to reduce it at all. As a short description of my environment (LAB), I have 2 NBU master servers participating in AIR scenario where the first one (which is the source for AIR) has 3 separate MSDP based media servers connected to it. The second master server also has MSDP pool plus a tape library for offloading purposes. I'm replicating all backed up images between my two NBU master domains regularly as backup images gets produced by the clients. The EMM_DATA.db file on the source master server somehow managed to grow to the enourmous size of 8.9GB while on the target master server it is not larger than 30MB. Although the infrastructure works well enough and I have no major failure out of this DB size except maybe for the increased size of the catalog backups, I wanted to optimize the DB to a somewhat normal size. After trying to validate, reorganize and rebuild the DB section as per the tech. articles via the regular "nbdb_admin" and "nbdb_unload" commands nothing really has changed to the DB size therefore I started digging a bit further. I noticed one particular discrepancy through the NBDBAdmin utility which shown me visually that the EMM_DATA portion is indicating "-1 bytes" for both "Free DBspace" and "Total DBspace" metrics. Also the size of the DB is indicated to be as 4096MB while in reality it's twice as big which makes me think that there is some kind of a corruption throughout NBDB or perhaps just the EMM_DATA portion although all the validation activities I did via CLI indicated that there are no errors at all. Reorganizing the DB via CLI indicated very few fragments and it also didn't indicate any errors. The rebuild command didn't give me any output but just returned to command prompt, however I noticed slight modification to the NBDB log files (got truncated almost immediately) so I assume that it didn't fail but it was doing it's job. On the second master server everything works absolutely fine and the sizes are definitely in order. Even though there is no relationship with this I would like to mention that all backup images in the catalogs for both master servers are exactly the same including the granularity factor for some of the backups where I use this feature (in my case Active Directory). Strangely enough when I tried to do the run the "Reorganize All" command through the GUI utility it returned back "Operation Failed" status message. The result was the same also for the "Rebuild" command. On the contrary "Validation" went through and didn't indicate any issues. My environment is based on Windows Server 2019 + NetBackup v8.2 for all NBU servers. One of my very old catalog backups that I could dig out (from exactly two years ago) clearly indicates that the EMM_DATA.db file at the time being was a little less than 30MB. If I remember right my servers were running NBU v8.1 binaries at the time being which I have upgraded to v8.1.1, v8.1.2 up till the current v8.2 through the years. I suppose this could be some sort of a bug with any of the intermediate or latest binaries, but right now I'm clueless on how this issue can be solved. I would appreciate any thoughts from experts around and I hope to find a solution to this pesky little problem. Cheers
