RedHat Linux netback master/media server. Netbackup 8.2 thinking of upgrading to v188.8.131.52
We use the windows desktop Admin Console GUI to maintain our policies etc.
We store the catalog DR packages on a network storage location.
The linux netbackup master/media server has access to this network area storage location and the catalog policy backup jobs always finish successfully. In the catalog policy under the disaster recovery tab the UNC location is listed but no Logon and password is inputted in the specified boxes. So how can i determine who is successfully writing the DR package files to the network storage location? Is it root account on the linux master/media server? or where could i find this from. what part of netbackup environment writes these dr package files?
We also have a windows environment which has a service account for netbackup and this is the account and passwd that I see in the catalog policy under the disaster recovery tab.
Reason Im asking because new with v9.1 they want you to create a service account (both linux or wins). This service account is non-root account in linux. So they say this will run some of the netbackup daemons and that veritas recommends not using root. So Im thinking if I create thisBC non root service account for a linux netbackup 184.108.40.206 upgrade and add this new netbackup service account to a non root group in linux that since we store our DR catalog packages on a network storage area that I may need to create same service account in active directory and give it access to the network location.
Any help or thought etc would be appreciated..
In 8.2 on Linux the catalog DR and DR_pkg files will be written by process running as the root user (simple enough to verify by looking at the files created). Although I am curious about your comment that you have specified a UNC path in the DR which I hadn't thought possible with Linux. Is the DR path really specified as \\NAS\path\to\DR\Files ?
That said, examine the file catdrinfo in the catalog policy directory (/usr/openv/netbackup/db/class/<catalog_policy>), it will provide the additional details such as the username and password used for the DR UNC path (if specified). This is what it looks like if you specify a UNC
and when a standard Linux path is specified.
In 9.1.x, the DR files will be written by a process running as the service account user you provide, so you will need to take this into account for the location provided (it will need write permission). Although if you are using a UNC with a specific user/password, then this change may not be required.
In my test lab I mount a share from a NAS device via NFS to write the DR packages (they were owned by root pre 9.1 and now in 9.1+ they are owned by the service account used).
Hey David - so I misspoke when I said UNC path.. We are using standard Linux path.
So when I putty into the into the linux master/media server Im sudo su to obtain the root prompt.
Initially via my windows desktop went or our Disaster_Recovery directory and tried to see under security who wrote the file but tells me i dont have access which I thought was odd. On the linux side when I go to the Disater_Recovery directory and do a "ls -la" root is the owner of the files.
So back to the 9.1.x the new service account - per your statement - In my test lab I mount a share from a NAS device via NFS to write the DR packages (they were owned by root pre 9.1 and now in 9.1+ they are owned by the service account used). So I wouldnt have to create the same service account in AD.
Thanks for all your HELP
The service account under Linux doesn't need to be in AD (and it is probably better if it isn't - to avoid an external dependency for NetBackup on AD).
What you will need to do is ensure that the new service account has write access to that Disaster_Recovery directory. I'm now guessing the location is NFS mounted from the filer, and as such you should be able to use standard Linux commands to provide the required access to the directory.
Also remember it is recommended to create a new service account for this and not use the existing service account that run Web Management services.