cancel
Showing results for 
Search instead for 
Did you mean: 

Netbackup Media server question

drj003
Level 3

Hi,

We have two separate netbackup environments that are backing up to tape.  We'll most likely be consolidating these two environments (possible because of network speed upgrade).  After consolidating it into 1 netbackup environment, we'll be backing the data up to a NAS device first and then offloading to tape.  The NAS will not be directly connected to the media server(s), but just directly connected to the network.  How will this change the need for media servers?  Will the data still flow through the Media server and then to the NAS, or straight from the clients to the NAS?

What is your recommendation for the number of Media servers for an environment that backs up to a NAS?  The environment has roughly 370 servers.

 

Thanks for the help.

1 ACCEPTED SOLUTION

Accepted Solutions

mph999
Level 6
Employee Accredited

1.  Please be aware that to merge to separate NBU environments requires a Symantec Partner as this can only be done via consulting services.  It's not particularly easy to do, and is outside the scope of technical support.

2.  If you are presenting the disk storage over the network, as a guess, are you planning on using NFS to present this storage to the media servers.

If you are - don't - NFS has  quite a large overhead especially as you go down a number of directories.  This is nothing to do with NBU, it is how NFS works, but will limit the overall performance.

When I get calls regardiong performance issues - it is not uncommon to find the disk storage is presented via NFS.  

I actually had one of these a few months back - I suggested they didn't build the system with NFS presented disk, they did anyway and I got a call within a week of it going live saying the performance was poor - nothing we could do, it's not NBU causing the slowness ...

Of course, you may not be planning on using NFS, so you can ignore this bit if that is the case.

In NBU, storage is 'attached' to media servers - clients out on the network, always send their data via the media server (unless SAN client, but you don't have this, and even then you still need a media server).

This is an outstanding technote :

 http://www.symantec.com/docs/HOWTO56078

It covers everything you need to know to estimate the number of media servers (see step 12) though you will need to work through all the steps.

The number of media servers comes down to how much data the 'media server' can accept and push out to the stoage in time period x.  If the server is powerful enough and has 'massive' io capabilities, you could probably do it with one, but then, I have no idea of how much data your clients have, and , what % of this changes each day.

One useful tip - (I presume here you run Fulls once a week and incremnetals the other days) - it is certainly worth doing the fulls for groups of clients on differnet days , to spread the load over the week, as opposed to all the fulls on Fridays as many people do.

You are starting the right way - by asking quiestions.

To work through the technote making the calculatons etc .. will probably take days, or even weeks - this MUST be done, do not take shortcuts on system design.

Any backup environment (using any software) will fail if not designed correctly, and with these type of failures there is not much the vendor can do and you have a lifetime of problems and failures.

In my experience (and I do this all day, every day ) I would say that >50% of the systems I see have design 'faults', or are now running features (for exaple SLP) that they were not originally designed to use.

Finally consider these two points :

(1)

I believe (and many of my BacklIne colleages agree) - that  a backup environemnt should never run 20 odd hours a day - there is no time for maintainence for a start, and if you have any isues then even a small problem bcome major, as you have no capacity for downtime.

(2)

Considering % success rates of the backups for all clients.

On 'average' sites that run multiple backup environments have a higher success rate of backups.  One big reason is any down time doesn't wipe out 100% of your backups. 

 

Hope this helps,

Martin (Senior Symatec NBU Engineer)

 

 

 

 

 

 

View solution in original post

2 REPLIES 2

mph999
Level 6
Employee Accredited

1.  Please be aware that to merge to separate NBU environments requires a Symantec Partner as this can only be done via consulting services.  It's not particularly easy to do, and is outside the scope of technical support.

2.  If you are presenting the disk storage over the network, as a guess, are you planning on using NFS to present this storage to the media servers.

If you are - don't - NFS has  quite a large overhead especially as you go down a number of directories.  This is nothing to do with NBU, it is how NFS works, but will limit the overall performance.

When I get calls regardiong performance issues - it is not uncommon to find the disk storage is presented via NFS.  

I actually had one of these a few months back - I suggested they didn't build the system with NFS presented disk, they did anyway and I got a call within a week of it going live saying the performance was poor - nothing we could do, it's not NBU causing the slowness ...

Of course, you may not be planning on using NFS, so you can ignore this bit if that is the case.

In NBU, storage is 'attached' to media servers - clients out on the network, always send their data via the media server (unless SAN client, but you don't have this, and even then you still need a media server).

This is an outstanding technote :

 http://www.symantec.com/docs/HOWTO56078

It covers everything you need to know to estimate the number of media servers (see step 12) though you will need to work through all the steps.

The number of media servers comes down to how much data the 'media server' can accept and push out to the stoage in time period x.  If the server is powerful enough and has 'massive' io capabilities, you could probably do it with one, but then, I have no idea of how much data your clients have, and , what % of this changes each day.

One useful tip - (I presume here you run Fulls once a week and incremnetals the other days) - it is certainly worth doing the fulls for groups of clients on differnet days , to spread the load over the week, as opposed to all the fulls on Fridays as many people do.

You are starting the right way - by asking quiestions.

To work through the technote making the calculatons etc .. will probably take days, or even weeks - this MUST be done, do not take shortcuts on system design.

Any backup environment (using any software) will fail if not designed correctly, and with these type of failures there is not much the vendor can do and you have a lifetime of problems and failures.

In my experience (and I do this all day, every day ) I would say that >50% of the systems I see have design 'faults', or are now running features (for exaple SLP) that they were not originally designed to use.

Finally consider these two points :

(1)

I believe (and many of my BacklIne colleages agree) - that  a backup environemnt should never run 20 odd hours a day - there is no time for maintainence for a start, and if you have any isues then even a small problem bcome major, as you have no capacity for downtime.

(2)

Considering % success rates of the backups for all clients.

On 'average' sites that run multiple backup environments have a higher success rate of backups.  One big reason is any down time doesn't wipe out 100% of your backups. 

 

Hope this helps,

Martin (Senior Symatec NBU Engineer)

 

 

 

 

 

 

drj003
Level 3

Hi Martin,

 

Thanks for the reply..  it was very informative.

 

I have the luxury of leaving my old environment in tact.  Our retention periods are only 6 months.  So, I could add all of the systems to the new environment, and if I need data from the old system, I can reinstall the old client and do the restore from the old system. 

 

I will make sure not to use an NFS share for the backup space.

 

Those guidelines are exactly what I neede.

 

Thanks again!