Veritas NetBackup™ Logging Reference Guide
- Using logs
- About logs
- About UNIX system logs
- About log retention in NetBackup
- About limiting the size of unified and legacy logs
- About unified logging
- Gathering unified logs for NetBackup
- Types of unified logging messages
- File name format for unified logging
- Originator IDs for the entities that use unified logging
- About changing the location of unified log files
- About rolling over unified log files
- About recycling unified log files
- About using the vxlogview command to view unified logs
- About query strings used with the vxlogview command
- Examples of using vxlogview to view unified logs
- Examples of using vxlogmgr to manage unified logs
- Examples of using vxlogcfg to configure unified logs
- About legacy logging
- UNIX client processes that use legacy logging
- PC client processes that use legacy logging
- File name format for legacy logging
- Directory names for legacy debug logs for servers
- Directory names for legacy debug logs for media and device management
- How to control the amount of information written to legacy logging files
- About limiting the size and the retention of legacy logs
- Configuring the legacy log rotation
- About global logging levels
- Setting retention limits for logs on clients
- Logging options with the Windows Event Viewer
- Troubleshooting error messages in the NetBackup Administration Console
- Backup process and logging
- Media and device processes and logging
- Restore process and logging
- Advanced Backup and Restore Features
- Storage logging
- NetBackup Deduplication logging
- OpenStorage Technology (OST) logging
- Storage lifecycle policy (SLP) and Auto Image Replication (A.I.R.) logging
- Snapshot technologies
- Locating logs
- acsssi logging
- bpbackup logging
- bpbkar logging
- bpbrm logging
- bpcd logging
- bpcompatd logging
- bpdbm logging
- bpjobd logging
- bprd logging
- bprestore logging
- bptm logging
- daemon logging
- ltid logging
- nbemm logging
- nbjm logging
- nbpem logging
- nbproxy logging
- nbrb logging
- NetBackup web services logging
- NetBackup web server certificate logging
- PBX logging
- reqlib logging
- robots logging
- tar logging
- txxd and txxcd logging
- vnetd logging
- Java-based administration console logging
- About the Java-based administration console logging
- Java-based administration console logging process flow
- Setting up a secure channel between the Java-based administration console and bpjava-*
- Setting up a secure channel between the Java-based administration console and either nbsl or nbvault
- Java-based administration console logging configuration on NetBackup servers and clients
- Java-based remote administration console logging on a Windows computer where NetBackup is not installed
- Configuring and gathering logs when troubleshooting Java GUI issues
- Undo logging
Synthetic backups
The typical NetBackup backup process accesses the client to create a backup. A synthetic backup is a backup image created without using the client. Instead, a synthetic backup process creates a full or a cumulative incremental image by using previously created backup images called component images.
Note:
Synthetic archives do not exist.
For example, an existing full image and subsequent differential incremental images can be synthesized to create a new full image. The previous full image and the incrementals are the component images. The new synthetic full image behaves like a backup that is created through the traditional process. The new synthetic full image is a backup of the client that is as current as the last incremental. The synthetic image is created by copying the most current version of each file from the most recent component image that contains the file. A synthetic backup must be created in a policy with the option selected. This option enables the synthetic backup to exclude the files that have been deleted from the client file system from appearing in the synthetic backup.
Like a traditional backup, nbpem initiates a synthetic backup. It submits a request to nbjm to start the synthetic backup process and nbjm then starts bpsynth, which executes on the master server. It controls the creation of the synthetic backup image and the reading of the files that are needed from the component images. If directory bpsynth exists in the debug log directory, additional debug log messages are written to a log file in that directory.
bpsynth makes a synthetic image in several phases:
Table:
Phase | Description |
|---|---|
1 - Prepare catalog information and extents | In phase 1, bpsynth makes a synthetic backup request to the database manager, bpdbm. It uses the entries and the TIR information from the catalogs of the component images to build the catalog for the new synthetic image. It also builds the extents to be copied from the component images to the synthetic image. The bpdbm service returns the list of extents to bpsynth. (An extent is the starting block number and the number of contiguous blocks within a specific component image.) A set of extents is typically copied from each component image onto the new synthetic image. The following figure shows how phase 1 operates: |
2 - Obtain resources | In phase 2, bpsynth obtains write resources (storage unit, drive, and media) for the new image. It also reserves all the read media containing component images and obtains the drive for the first media to be read. When the component images reside on BasicDisk, no resource reservation is done. |
3 - Copy data | In phase 3, bpsynth starts the writer bptm (for tape and disk) on the media server to write the new synthetic image. It also starts a reader bptm (tape) or bpdm (disk) process for each component image on a media server that can access the component image. The reader process reads all extents for the component image. The following figure shows how phase 3 operates: Note that bpsynth only starts the parent bptm (writer) and bpdm (reader) process on the media server. The parent in turn starts a child process. The parent and child communicate by means of buffers in shared memory. The bpsynth process sends the extents (starting block and count) for each component image to the corresponding child bptm or bpdm reader process. The parent bptm or bpdm reader process reads the data from the appropriate media into the shared buffers. The child bptm or bpdm reader process sends the data in the shared buffers to the child bptm writer process over a socket. The child bptm writer process writes the data into the shared buffers. The parent bptm writer process copies the data from the shared buffers to the media and notifies bpsynth when the synthetic image is complete. |
4 - Validate the image | In phase 4, the bpsynth process validates the image. The new image is now visible to NetBackup and can be used like any other full or cumulative incremental backup. Synthetic backup requires that true image restore (TIR) with move detection be selected for each component image, and that the component images are synthetic images. |