Avamar: What happens when avtar reads a file during the file scan phase

What happens when Avamar scans files during a backup?

During an Avamar backup, avtar scans the entire file system that is specified within the source dataset. It checks each file to learn if it was modified since the previous backup.   

For more information about how avtar detects if a file has been modified, see Avamar client - What has to change before avtar considers a file to have been modified?

Avtar walks all directories, even if the modified time of the directories themselves has not changed. This is because lower-level subdirectories may have changed.

For each non-directory file, avtar gathers its metadata. This metadata is the 'stat' information about the file.
On a Windows NTFS or ReFS file system with security descriptors, avtar also gathers the security descriptor.
This is because that information can change without the "file modify time" changing.
 
The entire path of an object is combined with stat-like metadata to perform a file cache lookup.

On a file cache read hit, the content hash, or location for Data Domain backups, is returned.

This allows the file to be backed up without opening it. There is no need, since it never changed since the last time it was backed up.

On a file cache read miss, the file is opened and the content is read, chunked, compressed, and hashed. Then the hash cache (or DDBoost for Data Domain) is used to avoid sending content to the Avamar server.
 
A hash is produced based on the information that is returned from a stat-like operation.

Example in Linux:

stat testtest.gz
  File: `testtest.gz'
  Size: 29              Blocks: 8          IO Block: 4096   regular file
Device: 803h/2051d      Inode: 2149406915  Links: 1
Access: (0600/-rw-------)  Uid: (  500/   admin)   Gid: (  500/   admin)
Access: 2014-12-30 07:51:14.335261000 +0000
Modify: 2014-12-30 07:51:14.335261000 +0000
Change: 2014-12-30 07:51:18.443265606 +0000

When assessing whether the file has changed, avtar considers the modify and change times but NOT the Access time.

This is a quick operation and explains why Avamar backups with few changed files and a low change rate, are so fast.

If the calculated hash differs from what is in the client's file cache, the file is considered to have changed. A changed file must be fully processed, and the new chunks must be sent to the Avamar server.

Related articles:

• Avamar: Backup performance behavior and theory.
• Avamar: How to use the client logs to identify which files are new or changed since the previous backup.
• Avamar: Troubleshooting slow backup performance.
• Avamar client - What has to change before avtar considers a file to have been modified?