Backup Speed (Kb Per Second: 8076)

[flavor4real]

I did get a KB Per Second of 6994 in one job and another 5863 before and after modifying the values (below), I have
the speed is 11490, Backup to Disk, LTO-4 ... but after 10 minutes the speed drops again down to 7742Kb per Second.

131072 > SIZE_DATA_BUFFERS
128  > NUMBER_DATA_BUFFERS
128 > NUMBER_DATA_BUFFERS_RESTORE
 

What else can i do?

[MCron]

When doing speed testing you should be using a static set of data.  Is this a network backup or direct from disk?  For tuning it is best to use a direct to tape on the server.  Also, due to buffering on the LTO4's and what not, I also make sure that I am backing up at least 1G of data.  Just create some large files, and then compress them.

Also, what OS are you working with here?  How much memory is on the machine?  Kernel tuning done (if needed)?  Depending on these values, you may be well under buffered.

-Mark

[flavor4real]

Its network backup from one server to another server in our server room. I backed up around 22GB direct to disk. the OS is server 2003. The Master Server has 35GB RAM and we use 1Gig network cards ...

If I look at the Starting Time and the End Time of the job and the KB written, I get that the 22GB of data got backed up in close to 60 minutes

[MCron]

If you have not read the NetBackup tuning guide, I would suggest that you do so.  I forgot last time, but are you putting these buffer setting on the media server?

My suggestion is to do the tape drive tuning on the media server first, then move on to network tuning with NET_BUFFER_SZ on the client and the media server.  In tuning, you are working to eliminate variables, or at least control them, so that you can do a proper statistical control matrix.

-Mark

[flavor4real]

im reading the NetBackup tuning guide since yesterday but it's a bit confusing. I'm still reading it ;)

[Scott_Chapman]

You would be better testing those backups with larger files on a non-system disk.  I usually use like a 7gig file on a disk that doesn't share spindles with the system disks.  This will show you what the environment will do much better than pulling backups from an already "busy" system disk.

If you're including the C: drive in this backup then you're getting a lot of files, but you're also contending with what the client is doing on the system disk when you are running your backup.

Also don't forget to set the "Communications buffer size" in Host Prop-->clients-->client-->windows client-->client settings.  You will need to ensure this is done on the media server doing the backups as well, but I'm not sure where to set that since i run Solaris servers not windows ones.

hope this helps

[flavor4real]

I've set all varialbes on the media server and clients. the result I get is 14957Kb/second, which is around 876MB/minute ... Just out of curiosuity, is that a good value when I backup to LTO-4's

[Nicolai]

I would expect to see a LTO4 drive in the range from 80 to 120MB/sec.

LTO4 have adapting write speed in the range 40-120MB/sec to avoid the so called shoe-shining effect. HP have a free tool called LTT (Library and Tape Tools). Try running the performance test and tell us how many MB/sec you are seeing.

http://h18000.www1.hp.com/products/storageworks/ltt/index.html

[flavor4real]

I've edit all i can do and can figure out what slowes the backup process down. .. i don't know what do do ..

[Ira_Brock]

If there a bunch of smaller files, Netbackup will slow down a lot. We have been on NBU for years and that is actually one of the better ethernet speeds we have seen. If using Windows and copper .. it just is not that fast. If you use the SAN, you will be amazed of the speeds you get.

[flavor4real]

There is one error I see coming up which is

8/13/2010 3:03:40 PM - Error bpbrm(pid=6540) BMRERR: Received BMR error: The driver for HP NC382i DP Virtual Bus Device is not compatible with Windows PE. You may need to create a driver package that is Windows PE compatible to restore this system using Bare Metal Restore. (1)

Could the driver issue be the problem? Remember a HP tech came out and setup the complete system (befire I've started here)

[mandar_khanolka]

Looks like the backup policy has BMR option enabled.
If BMR is enabled in policy, first job gets triggered is BMR configuration backup. It would fail if the windows client has some driver configuration problem. Like shown above.
You may want to check if this driver has been setup properly on your client machine.
You may want to disable Bare Metal Restore flag from the backup policy in case you do not intend to protect your client machine from complete disaster recovery.

[flavor4real]

hmm. I thought it might be a good idea to have BMR, esp. the environment I'm in. I will look at the driver configuration. thx for ur help

[Andy_Welburn]

I'm presuming here (but maybe I shouldn't?) that you know that BMR is more than just a 'tick in a box' in the Policy - may require additional software and servers to implement it successfully throughout your environment.?

Veritas NetBackup (tm) 6.5 Bare Metal Restore Administrator's Guide
http://seer.entsupport.symantec.com/docs/290231.htm

[mandar_khanolka]

flavor4real: In case you want to protect your clients from DR using BMR; I would recommend opening a service request with Symantec for this BMR backup failure (related to the specific driver). Please provide, 1. bmrsavecfg log with debug level 6 in nblog.conf ( created at the client side) 2. bmr master server log with debug level 6 in nblog.conf (created at the NBU/BMR master server machine) Thanks. -Mandar