Need information on Implemention VADP based backups - NBU 7.6.0.1
Solaris cannot be used as a VADP backup host.
You need a 'supported' version of physical Windows, or RHEL, or SUSE EL server - or a VM of one of these - to act as a backup host. And you need licensing.
If you only have a handful (and I literally mean a handful - like five or less) of VMs to backup, then you may get away with a VM based backup host - but it all depends on so so many variables that we have no visibility of. If they are 'big' VMs then... well... you may want to reconsider using a VM as a backup host.
I once had (years ago) a VCB (pre VADP) environment based on iSCSI, and we just couldn't figure out why it wasn't performant - point to point IO LAN tests were all ok etc... - so we simply changed to FC SAN - and I kid you not, all NetBackup servers, all LUNs, all ESX servers, all OS, all clients, all versions... all exactly the same - all we changed was the presentation from iSCSI to FC - and it flew... the difference was incredible - just goes to show the impact that poor LAN switching configuration can have.
Anyway, I added the above just as example of how sometimes, poor performance has absolutely nothing whatsoever to do with NetBackup. A great many of us really do have wonderful backups with NetBackup and VADP - but then the underlying infrastructure is there to support us.
.
What are your constraints? Budget? Time? Size and throughput?
I'm sorry to say this... but there are no guideliness that can be put down in words. It all depends upon your requirements and your infrastructure.
My advice... tell the boss that you are going to try and do it as cheaply and as quickly and as easily as possible - but... But... BUT... he/she may need to invest if the VM approach does not scale. And, if you build slowly, you will very clearly see the point at which it all breaks down. At which point you can take a half step backwards and still have a somewhat functioning VADP environment... whilst you discuss budget and a more technical solution.
Since you have Capacity License, you can choose any supported OS as backup/access host.
Best to make this backup host a Media Server with SAN access to datastores. (SAN transport)
Physical is always better than VM used as backup host (hotadd transport).Some documentation that you can go through to prepare and plan:
Nuts and Bolts in NetBackup for VMware
Transport methods and TCP ports
(Netbackup) VMWare Backup over SAN
VMware Transport Modes: Best practices and troubleshooting
http://www.symantec.com/docs/TECH183072Presenting the VMWare datastores to a VMware Access Host for NetBackup
http://www.symantec.com/docs/TECH159522Statement of Support for NetBackup 7.x in a Virtual Environment:
http://www.symantec.com/docs/TECH127089what is appropriate way to convert RDM luns.
That is a question for your VMware Admin...
As far as NBU and RDMs are concerned - you will need to install NBU Client in these VMs and take normal OS-level backup.
To get back to the rest of your questions:
As per symantec, supported OS for 7.6.0.1 are.....
Have another look at table 11 of http://www.symantec.com/docs/TECH127089 :
I see Linux (RHEL) 5.9 mentioned in most 7.6.0.x columns.
But best to go with RHEL 6.x to ensure future support.Is it enough to have one dedicated physical media sever as backup access host?
This will depend on number of ESX hosts, number and size of VMs and number of datastores in your environment, as well as resources (memory, cpu, tape or disk storage) on the media server.
If you read through 'Resource Limits' section in NBU for VMware manual, you will see that none of these resources should be overloaded.
So, you then need to look at the amount of data that need to be pushed through in a backup window and decide if a single server can handle the load.
Not really something that can be answered in a forum discussion....By mapping we mean... for the LUNs that are used as VMFS Datastore Volumes which you have already presented to the ESXi hosts, also present these same LUNs to the NetBackup 'VM Backup Host(s)'.
So, if you have 20 LUNs all of which are VMFS Datastore volumes all presented to say 4 ESXi hosts, then present the same LUNs, using the same methods (from the storage array) to the NetBackup VM Backup Hosts - i.e. imagine that the NetBackup VM Backup Hosts are the same as an ESXi host, and you'll be ok.
No one can tell you what the maximums are for your environment. It all depends upon your infrastructure. Someone must have had a 'storage plan' when the ESXi hosts were built, so simply extend this storage plan to include some additional 'servers', i.e. the NetBackup Servers (or Enterprise Clients) acting as VM Backup Hosts.
You only need to map the LUNs which contain, or will contain, or may contain (after VM Storage vMotion) guest VMs which require VM style/level backups. So, if you have 20 LUNs presented to the ESXi hosts, but only 10 of these LUNs will ever contain VMs which require backup, then only present these 10 LUNs to the VM Backup Host(s).
Do you have multiple VMware clusters - and/or several hundreds of LUNs - and/or thousands of VMs?
If so, then you really really need to do some very detailed planning indeed, and quite detailed calculations... otherwise... it could get messy.
.
Assuming that the environment is not large - and that the total number of LUNs (in total from all storage arrays) is, say for example, less than 120, and say you have 3 or 4 storage arrays, then...
...the LUN count should not really be an issue, because most HBAs and HBA drivers and OS based SCSI drivers will support up to 126 (sometimes 254, sometimes more) LUNs on HBA ports, but what will matter is how you blanace:
LUNs <-> Storage Array Front End ports <-> SAN zoning <-> Server (ESXi + NetBackup) HBA ports <-> Backup Policies.
...so, if you carefully balance the LUNs (data) vs. how they are used (by backup policies) then you should be ok. What you may want to avoid is, at one time, trying to take multiple VM backups through one HBA port on one backup server. My suggestion is to build a spreadsheet of at least the five columns of the above (and I think it likely that you may end up adding more columns), in an attempt to capture the view of how the environment will be used. i.e. try to get a feeling for how well balanced it is.
That's a fair sized environment. Can I suggest that you think carefully about balancing LUNs across media servers - and thus VMs across backup policies/STUs/SLPs.
The OS SCL for RHEL indicates that RHEL 6.1 should be ok:
https://symwisedownload.symantec.com/resources/sites/SYMWISE/content/live/SOLUTIONS/76000/TECH76648/en_US/nbu_76_scl.html?__gda__=1430935481_88871dd466f21bd6f1ded3fd4f5f01cb#operating_systems-red_hat_enterprise_linux
...but why RHEL 6.1 and not a later revision? Won't a later revision of RHEL6.x be more stable, and more secure?
I think your environment is sufficiently large enough to warrant using SAN transport. If you only had a few VMs to backup, then NBD LAN transport could well be used, but with 42 ESXi hosts and 1000+ VMs, surely one would want the backup 'load' to be off-host and not flow through the ESXi hosts. Remember, with SAN transport the backup traffic will be direct from storage array to the VM backup hosts. However, with NBD, the backup traffic has to flow through the ESXi hosts, so you'll be using two servers (ESXi + Media servers) plus an additional hop on the LAN. IMO, I wouldn't do NBD/LAN on an environment of this size. So, to answer your question, then... yes, I do think that NBD/LAN transport could lead to performance issues simply because of the volume of data to backup.
You already have 42 SAN attached ESXi hosts. And a VM backup hosts is essentially the same as an ESXi host - in so far as that it reads (backups) and writes (restores) to VMFS data store LUNs via SAN, and so you should have a sufficiently mature SAN infrastructure that you can leverage - for the additional of five more servers (i.e. the RHEL NetBackup Media Servers).
One should also consider the future, and the fact that the environment is likely to grow - and so, your planning is not just about today - and ideally one should think at least two years ahead. With a SAN based VADP infrastructure, and a well designed storage plan - you should be able to build a platform and storage + backup mdel that will easily grow with you.
Re RDMs... you should still be able to backup the parts of VMs that have VMDKs using VADP, and just use NetBackup Client inside the VMs to take the RDM LUN content only.
What percentage of data is on RDM LUNs? 40%, 80%, 95%?
Will the media servers be using MSDP dedupe?
HTH.
