Avamar: Backups and sparse files

Issue 1: A backup could run slowly if it includes a sparse file which has been modified:

UNIX and Linux file system support for sparse file detection and management is file-system-dependent.

When a sparse file is modified, Avamar's avtar process reads the file as presented by the file system.  

Avtar performs sticky byte factoring on the entire file. This means, it breaks the file into chunks, compress those chunks, and create a hash of each chunk. For a large file, this may take a significant length of time.

This scenario can be detected by reviewing the avtar status messages in the backup log.  
For further details, see: How to analyse Avamar client backup performance and identify performance bottlenecks.

Issue 2:  Performing a restore of a sparse file may result in the restored file having a different size:

Although avtar does not detect 'sparse files', it detects regions of sparseness within a file and attempt to handle them efficiently.

The logic which handles the detection of sparseness is not 100% deterministic. It relies on a heuristic that looks for large regions of consecutive zeroes. This is described in Engineering Esczilla record 24164.

It is expected that the space or number of blocks consumed by the restored file, may not be identical as for the original file.

One or more of the files backed up by an Avamar client are "sparse files".