Home » Arsip untuk 7/1/07 - 8/1/07
Netbackup Tuning Parameters

Netbackup Tuning Parameters

Here is some information on undocumented features for setting the Network Buffer Size, Data Buffer Size, and Number of Data Buffers used by NetBackup (tm) on UNIX platforms.

TCP/IP Network Buffer Size.

/usr/openv/netbackup/NET_BUFFER_SZ is a file containing a number indicating the TCP/IP socket buffer size that should be used for data transfers between the NetBackup media server and its clients. If the file does not exist, the default value used is 32032 bytes.

The default value can be changed by creating the file /usr/openv/netbackup/NET_BUFFER_SZ on the NetBackup media server and client systems.

The /usr/openv/netbackup/NET_BUFFER_SZ file is a text file containing a single line specifying the value of the Network Buffer Size in bytes in decimal format.

For example, a Network Buffer Size of 64KB could be configured and checked like this:

# echo "65536" > /usr/openv/netbackup/NET_BUFFER_SZ
# cat /usr/openv/netbackup/NET_BUFFER_SZ
65536
#

Specifying a larger value in the NET_BUFFER_SZ file may improve the performance of backups and restores. It is recommended that if NET_BUFFER_SZ is used, the same value should be set on all the NetBackup media servers and clients.

Data Buffer Size and Number of Data Buffers.

The NetBackup media server uses shared memory to buffer data between the network and the tape drive (or between the disk and the tape drive if the NetBackup media server and client are the same system). By default, NetBackup uses a default value of 8 x 32KB shared memory buffers for non-multiplexed backups and 4 x 64KB for a multiplexed backup.

These buffers can be configured by creating the files /usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS and /usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS on the NetBackup media server. These parameters are meant exclusively for media servers, and should not be used on a pure master server or client.

The SIZE_DATA_BUFFERS file should contain a single line specifying the data buffer size in bytes in decimal format.
The NUMBER_DATA_BUFFERS file should contain a single line specifying the number of data buffers in decimal format.

The value in the SIZE_DATA_BUFFERS file has to be a multiple of 1024B.
It is common to increase SIZE_DATA_BUFFERS to 256KB and NUMBER_DATA_BUFFERS to 16.

IMPORTANT: Because the data buffer size equals the tape I/O size, the value specified in SIZE_DATA_BUFFERS must not exceed the maximum tape I/O size supported by the tape drive or operating system. This is usually 256 KB or 128 KB.


In order to configure NetBackup to use 16 x 256 KB data buffers, specify 262144 (256 x 1024) in SIZE_DATA_BUFFERS and 16 in NUMBER_DATA_BUFFERS:

# echo "262144" > /usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS
# echo "16" > /usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS
# cat /usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS
262144
# cat /usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS
16
#

Care should be taken when changing these values. For example, increasing the tape buffer size can cause some backups to run slower and there have been cases where there have been restore problems.


IMPORTANT: After making any changes, it is vitally important to verify that the following tests can be completed successfully:

1. Run a backup
2. Restore data from the new backup created in step 1
3. Restore data from a backup created prior to the changes to SIZE_DATA_BUFFERS and NUMBER_DATA_BUFFERS

taken from : http://seer.support.veritas.com/docs/183702.htm

Status Code 191 -- (NetBackup Error 191: no images were successfully processed)

Error 191 raised when relocation of images to tape or duplication processes is get trouble. For Example when the duplication is going in progress and suddenly socket on media server is failed (status code 24 --socket write failed) the status of this job is going to be 191.

If a duplication fails with any error code, the parent "__DSSU_POLICY" relocation job always returns a Status 0 (successful) in NetBackup 5.x. Since the parent job receives a Status 0, and not a Status 134, the job is never retried. Duplications from a tape or disk storage unit also need to be retried manually if an error is encountered.
The bpduplicate command does not contain any method to retry failed duplication jobs. This is normal behavior for NetBackup. Any failed duplication jobs from tape, disk, or a DSSU will need to be retried manually in order to complete successfully.
So, my suggest when this status code occurs, the first thing to do is clarifying what is the first error happened that caused this job to be 191 status code, and solve this problem first, after this problem OK, then retry manually relocation job, because the bpduplicate command does not contain any method to retry failed duplication jobs.

Reference : http://seer.support.veritas.com/docs/279718.htm
status code 41 -- network connection time out

status code 41 -- network connection time out

This morning, when I open an 'Activity Monitor' Netbackup java console, I found that one of media server in our backup domain is failed. I 've just known, if this media server has replaced by a new one. Formerly no problems with this media server, everything is going well. This media server is a production, there is an oracle database with archive mode.

First, I try to escalate to know what was going wrong?
On 'Host properties' java console, I found if this media server had "status code 41 -- network connection time out". The server did not receive any information from the client/master for too long a period of time. This can occur when a network connection is broken during a backup or restore. This can also occur when a NetBackup timeout is exceeded. In my case the problems occur, before the backup schedule run. And I try to test the port binding from master to this media server, and the result is failed.

The second, when the problem is on Network problem, I try to localize the main core problem by comparing the parameters in bp.conf, /etc/hosts with others media server, and found if nothing strange. And I tried to check the network services on this media server, and again I found nothing strange. But ... Finally I found if the /etc/nsswitch.conf is not available yet and unfortunately if this (new) media server is not listed on DNS.
I add /etc/nsswitch.conf and define if the system must read the file on /etc/hosts first before DNS. After it added, the problem is solved. And archiving an archive log is normally run.

Some reference is taken from http://seer.entsupport.symantec.com/docs/278422.htm.
Back To Top