Definition of each field in the bpflist command output.

Article: 100016517
Last Published: 2015-04-28
Ratings: 1 0
Product(s): NetBackup & Alta Data Protection

Problem

Definition of each field in the bpflist command output.

Solution

There are several cryptic fields that are listed in the output of the NetBackup bpflist command.

By default, there is a FILES line every 50 lines in the output.

Example:
FILES 8 0 0 1273057676 0 client1 test client1_1273057676 - *NULL* 50 0 unknown unknown 0 0 *NULL*

Description of each field on the FILES line, note that some fields are not used for output:

  1. FILES line tag
  2. Image version
  3. Client type
  4. Start time (not used)
  5. Timestamp of the backup (in 10 digit ctime format)
  6. Schedule type (0=FULL, 1=Diff INCR, 2=User Backup, 3=User Archive, 4=Cumul INCR)
  7. Client host name
  8. Policy name
  9. Backup ID
  10. Peer name (not used)
  11. Software version (not used)
  12. Number of lines in the output following this FILES line, until the next FILES line
  13. Options (not used)
  14. User (not used)
  15. Group (not used)
  16. Raw partition id (not used)
  17. Job ID (not used)
  18. Keyword (not used)

Following the FILES line, there is a line of data for each file/directory in the backup image.

Example:
9 0 9 49 47 1 0 0 35651584 /test/ddd 33188 root other 20 958143374 958143227 959788518

Description of each field on the line:

  1. sequence number in the backup image (starts at 1 - zero means the path is not in the image)
  2. compressed size in bytes (0=not compressed) -- i.e., the client-side software compression option that is controlled by a NetBackup policy attribute.
  3. number of characters in the path name
  4. number of characters in the data line, from the field after the path name to the end of the line
  5. starting block of this file's data in the backup image
  6. in_image flag (0=not in image, 1=in image, 2=TIR data only in image)
  7. raw partition size in bytes (0=not a raw partition)
  8. size of the file in GBytes (only set if the file is bigger than 2 GBytes, otherwise zero - also see Note 3 below)
  9. file system physical device number (encoded major and minor device numbers)
  10. path name (directories end with a /)
  11. file/directory mode bits in decimal (convert to octal - see Note 4 below)
  12. owner
  13. group
  14. real size in bytes (directories are reported as zero bytes)
  15. last access time
  16. last modification time
  17. last inode modification time

Note 1: For an NDMP backup image, there may be an optional 18th field, which holds information that is used by DAR, in an encoded hexadecimal format.

Note 2: This example applies to standard backups. There may be exceptions with AFS file systems due to the differences in mode bit rights.

Note 3: The 8th field on the line is actually a 64-bit field that comprises two sizes: the lower 32 bits are the gigabyte count for the compressed size of the file, the upper 32 bits are the gigabyte count for the uncompressed size of the file, regardless of whether it s a normal or raw partition file.

  • For example, if the value is 193273528330, this is actually 0000000000000000000000000010110100000000000000000000000000001010 as a 64-bit binary. This represents that the post-compression file size is 10 Gigabytes (taken from the lower 32 bits, 10 * 2^30) plus the raw compressed file size (field 2). The uncompressed file size is 45 Gigabytes (taken from the upper 32 bits, 45 * 2^30) plus either the raw partition size (field 7) or the real size (field 14), depending on whether the file is a raw partition file or not.

Note 4: The 11th field on the line is the file/directory mode bits in DECIMAL.  To see the file/directory permission bits more clearly, convert the value into OCTAL or BINARY format.

  • For example, if the value is 33188 decimal, this is actually 100644 in octal, which indicates that it is a regular file (0100000) with permissions rw-r--r-- (0644).
  • A full list of the meanings of all the mode bits can be found on a Solaris system in /usr/include/sys/stat.h, towards the bottom of the file (or in the equivalent header file on other UNIX platforms).

References

Etrack : 2508020

Was this content helpful?