File system backup job is successful, but bpbkar reports "sparse" files.

UNIX client file system backup is successful with Exit Status 0, but the bpbkar log shows delays processing sparse files and messages such as:

02:16:45 [551654] <2> bpbkar process_file: INF - /dir1/dir2/file.dbs is sparse: stat.st_size = 2097160192, stat.st_blocks * 512 = 2095312896
02:23:02 [551654] <2> bpbkar process_file: INF - /dir1/dir2/file.dbs is now size 2094918265
02:26:01 [551654] <4> bpbkar PrintFile: /dir1/dir2/file.dbs

 

Generally speaking, these are informational messages indicating that a "sparse" file has been encountered. The VERITAS NetBackup (tm) bpbkar client process considers a file  "sparse" when the file size is larger than the physical block space allocated by the file system to store the file. This implies at least one of the records in the file is a "hole" or record of zeros. The file system optimizes storage of sparse files by keeping track of records containing all zeros and does not allocate physical blocks for these records of zeros. Thus records of zeros appear as "holes" in the file. The file size includes the zeros, but the file system has not allocated physical blocks to store the records of zeros. The UNIX client bpbkar process performs special processing when it encounters one of these files for backup. Similar special processing occurs in the UNIX client tar process to restore one of these files.

This special processing associated with handling a sparse file may require more time on backup and restore than a regular file of the same size. Sparse files are commonly associated with database products. If a database product is present, the user may want to consider using a NetBackup database agent to back up the database and its sparse files.
 

If there are issues backing up the sparse file (e.g. high CPU usage) a workaround may be to exclude the file by adding the file name to the file on the client called /usr/openv/netbackup/exclude_list.