How the VERITAS NetBackup (tm) client process handles named pipes (also known as FIFO files)

How the VERITAS NetBackup (tm) client process handles named pipes (also known as FIFO files)

  • Article ID:100023315
  • Last Published:
  • Product(s):NetBackup


How the VERITAS NetBackup (tm) client process handles named pipes (also known as FIFO files)


A named pipe is a special type of device file that can have a script or executable binary writing information into the pipe.
When running cat, more, dd, or any other type of utility on this type of file, that utility will read whatever is being written into the pipe..
For NetBackup releases before, NetBackup's client backup process, bpbkar, operates the same way when accessing this type of file . When it scans the file, the file descriptor is opened and read via standard system calls, such as open() and read().
If a process has already opened the other end, bpbkar will read and backup whatever the other process is writing to the pipe, until the other process is done. If no other process is writing to the pipe, bpbkar waits. What eventually gets written to the storage unit is what the third-party process is writing to the pipe, not the named pipe itself.

Similarly, when you restore this named pipe, you won't get the named pipe, but rather whatever the output of that named pipe was when it was backed up. If the intent was to recreate the named pipe itself, this must be done manually

Note: Use the raw (-r) option to list or restore the backup images for the pipe. That option allows the NetBackup client restore process, tar, to write the previously saved image into the pipe from which it can then be read by a third-party process.  If no process is reading from the pipe, tar waits.

In NetBackup –, the behavior was changed. NetBackup began to backup and restore the file for the named pipe, and did not read from or write to the pipe.  This allowed NetBackup to protect the named pipe file, and avoid hanging until timeout when accessing a pipe that had no third-party process writing to (backup) or reading from (restore) the file.

In NetBackup and later, both behaviours are supported. By default, NetBackup will only backup and restore the named pipe itself. In order for bpbkar to read the data from the named pipe, BACKUP_FIFO_FILES = 1 must be added to the bp.conf file on the client host. The same setting also allows tar to restore/write the backup image to the named pipe.
The NetBackup pre- behavior regarding named pipes is useful if, you need an ad-hoc solution for backing up a hot or running database. Since most commercial databases have freeze, dump, and resume command-line utilities, some administrators have set up named pipes, then scripted solution that halt or quiesce the database, run its dump command to send a snapshot of the database to a device or file such as a named pipe and then resume the database after the completion of the dump. Using a named pipe allows the backup image to go directly between the database and NetBackup without having to be spooled to an extra/spare disk volume.

There are a couple of caveats with this solution. One of which is that the backup of the named pipe file must be completed within the CLIENT_READ_TIMEOUT bp.conf setting on the NetBackup media server. Otherwise, NetBackup will abort the backup with a non-zero status code (typically 13 or 41 ). So, unless the third-party process writing to the pipe in question exits within that timeout period closing its end of the pipe,  NetBackup will fail the backup job so that server resources can be allocated to other jobs.
The same is true for restores, except that the job will fail with status 2800. In either case, the client processes will continue waiting on the pipe until terminated

If the goal is to back up the script or executable that is responsible for writing to the named pipe, then just point the Backup Selection (files list) at the program file, not the pipe itself.  The only way to avoid backing up named pipes, while having the contents of others pipes read, is by using an exclude list or avoiding the files altogether in the files list.

In most instances, it's easier to back up (and restore) by using bpstart_notify and bpend_notify scripts to start up and shut down any databases on the client and then reading the database files directly from the file system. Or, better yet, the database extension products available for NetBackup do the same job (and it does that job much better) as opposed to a custom-scripted solution.


Was this content helpful?