Please enter search query.
Search <product_name> all support & community content...
Article: 100016170
Last Published: 2023-03-17
Ratings: 1 0
Product(s): NetBackup & Alta Data Protection
Problem
Does the touch file "NOSHM" really disable the use of shared memory during backup and restore operations?
Solution
The
NOSHM file does not affect the use of shared memory, only which processes utilize it directly.
In the following discussion, the process is the same for a all storage unit types (tape, DSU, DSSU, OST, and NDMP remote), all client types (Standard, Windows, DB2, Oracle, etc) where the backup images passes through the media server host. The discussion applies to restore as well as a backup. In the case of a restore, the data flow is from the storage device to the client restore process.
The NOSHM file causes a local backup/restore to a local client run in the same manner a backup/restore to a remote client. A local operation is one where the client is also the media server. A remote operation is where the data must travel across a network connection via a Transmission Control Protocol (TCP) socket between the client host and the media server host.
A local backup has a client process which reads the data to be backed up and writes the data directly into the shared memory data buffers. The bptm process then reads the data from the shared memory data buffers and writes the data to the storage unit.
A remote backup is one where the client process writes to a TCP socket instead of the shared memory data buffers. A bptm child process on the media server reads from the TCP socket at the other end of the connection and then writes the data into the shared memory data buffers. A bptm parent process then reads the data from the shared memory data buffers and writes the data to tape.
In the following discussion, the process is the same for a all storage unit types (tape, DSU, DSSU, OST, and NDMP remote), all client types (Standard, Windows, DB2, Oracle, etc) where the backup images passes through the media server host. The discussion applies to restore as well as a backup. In the case of a restore, the data flow is from the storage device to the client restore process.
The NOSHM file causes a local backup/restore to a local client run in the same manner a backup/restore to a remote client. A local operation is one where the client is also the media server. A remote operation is where the data must travel across a network connection via a Transmission Control Protocol (TCP) socket between the client host and the media server host.
A local backup has a client process which reads the data to be backed up and writes the data directly into the shared memory data buffers. The bptm process then reads the data from the shared memory data buffers and writes the data to the storage unit.
A remote backup is one where the client process writes to a TCP socket instead of the shared memory data buffers. A bptm child process on the media server reads from the TCP socket at the other end of the connection and then writes the data into the shared memory data buffers. A bptm parent process then reads the data from the shared memory data buffers and writes the data to tape.
For a restore operation, the direction of the data path changes. The bptm parent process reads from the storage unit and fills the shared memory data buffers. Then either bptm child (remote operation) or the local client process read the shared memory data buffers.
The NOSHM file forces the creation of a bptm child process during a local operation even when the client and media server are the same host. However, in both a local and a remote operations, shared memory will still be used to buffer the data between client process and storage unit.
The touch file is only valid when applied to a system where the backup client host is also the storage unit host for that backup.
The location of the file is either <install_path>\veritas\netbackup\ for Windows, or /usr/openv/netbackup/ for UNIX.
The touch file name is NOSHM without a filename extension, so be sure to not use a default extension (.txt) on Windows.
Each time an operation is started, NetBackup (tm) checks for the existence of this file, so no services or daemons need to be restarted when adding or removing this file.
Note: The use of the
NOSHM file also does not change the number of TCP connections. The bpbrm process always creates the same connections to bpcd to start the client process whether that process is local or remote. The NAME (and COMM) connections between bpbrm and client are utilized exactly the same. The DATA/NEW_DATA connection is created exactly the same. Without NOSHM, it would be held and unused by both bptm parent and the local client. With NOSHM in existence, it is used for the transfer of the backup image between bptm child and the client; increasing the traffic across the loopback network interface.
Was this content helpful?
Translated Content
Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.