Can a Windows Primary Server use directly an OST Storage Server? A Media Server is not required nor recommended for that purpose?
I'm asking because I learned the hard way that MSDP is not supported in a Primary Server when it's Windows (https://www.veritas.com/support/en_US/article.100037977), so I was wondering that if the dedup processing is done in the storage, then it would be ok.
The article you mention is a recommendation only to not use a master/primary server as MSDP server due to performance considerartions. For large environments I would never suggest combining the two functions on one server (there are upgrade considerations when combining the functions).
There is nothing stopping you deploying a master/media combined server and this is often the most suitable for a small environment (where the cost of multiple servers is not justified (or beter spent having a second server at another location to provide for two copies on two sites).
For OST implementation typically the deduplication is done by the storage server target, so the performance hit on the master server is lower.
What I'd suggest is to review the latest Performance and tuning guide for more information. It can be found here: https://www.veritas.com/support/en_US/doc/21414900-146141073-0/v19525319-146141073
Thanks for your reply. My experience with MSDP on a Windows Primary Server was documented in the Veritas support case 181009-001066. This domain has a 12TB FETB and full backups every weekend go to a 32TB MSDP, which are all later duplicated through SLP to a tape library with 4 drives.
Apparently the tuning guide qualifies this platform as a Medium environment, but I'm not clear if that means we should keep only one NetBackup Server. Should we separate the Primary and Media Server roles into separate servers? We couldn't do this before, but recently we upgraded into capacity licensing and I'm pretty sure we now have a NetBackup Enterprise Server because I can see the "Media Server" item in the Hosts Properties section of the Java Console.
Also, from what I inferred from the tuning guide, in a perfect world the Primary Server should be always virtualized and the physical servers should focus on providing backup repositories. Our client will prefer that the backup server is outside of the virtualized world and if a separate server is required for MSDP then they will consider an OST storage.
Sorry for changing the topic.
Firstly, on sizing and combining the two functions - the FETB is not the only measure to use - you need to look at the number of jobs per day and whether combining it all on one server will cope with the load. There are good reasons to separate them, but it is not always necessary (and the guides are just that - general information that needs to be weighed with your specific requirements). You should also consider the recovery objective and whether the single server can provide the necessary performance.
There are advantages and disadvantages of virtualising the master - and the particular environment shoulld determine the appropriate action.
A disavantage of the master being virtual and your VMware farm fails, how do you recover? If your environment is large enough that you have two sites and can afford SRM or similar for DR, then this disadvantage is diminshed.
The advnatage of a virtual master is that it allows the server to be resized easily and relocated as required (if the environment permits it).
While third party OST storage may be an alternative - I would have thought that the cost of this (I'm thinking Data Domain or HP StoreOnce) would far outweight the cost of a second server and storage. In addition, you lose the ability to perform deduplication (with NetBackup) at the client, so all the data will need to traverse the network at least to the media server and possibly to the OST storage server (depends on the availability of OST plugin and capability).
The ability of NetBackup with MSDP to perform client side deduplication can reduce the load placed on the MSDP storage server (thus making the combined master/media more possible).