Avamar: Avamar client: What has to change before avtar considers a file to have been modified?

When an Avamar client performs a file system backup, it examines all the Avamar files within the scope of the workorder's dataset.
It determines which files have changed so that those files can be processed.

This process is well documented in the workflow in the attached file "avtarprocess.pdf".

This article discusses "what has to change before avtar considers a file to have been modified".

This matters when;

• Investigating a backup with a higher or lower number of changed files than is typical.
• Where files are large and would take a relatively long time to process when they are detected as modified.

What has to change before avtar considers a file to have been modified?

Attributes considered by avtar;

• The file name. 
• The file's size. 
• The file's mtime (modification time).
• The file's path.
• The file's offline or online status.
• The file's fstype  (FAT32 vs NTFS).

Attributes NOT considered by avtar

• The file's owner.
• The file's group.
• UNIX Access Control Lists (ACL).
• The file's atime (access time).
• The file's ctime (inode/file change time) - As discussed in Engineering Esczilla 7618 #C13.

During backup, while avtar is scanning the file system, it reads (that is "stats") all the metadata. It can then populate an entire DIRELEM (directory element) except for the SHA-1 hash of the file's content.

The file-cache is the mechanism to obtain this "missing 20 bytes" for files that have been previously backed-up and are unchanged.

If the file-cache returns the SHA-1 hash of the file's content, avtar has everything that it needs to fully populate the DIRELEM. 

The file does not need to be opened and read.

Note 1: The input to the file cache is not all the metadata.

• This avoids rescanning files whose content has not changed.
• Included in the decision: Full path, size, mtime. offline or online status, fstype (FAT32 vs NTFS, and so on).
• Not included in the decision: owner, group, UNIX ACLs and so forth

Note 2: Although not all the metadata is used in the file-cache lookup, all metadata is stored in the DIRELEM in every backup.

• Any metadata changes yield a new DIRELEM which is stored on the Avamar Server.
• This assures that we capture ALL metadata changes, even when the file content does not change.

KB Articles related to this topic:-

• Avamar: How to use the client logs to identify which files are new or changed since the previous backup.
• Avamar - How to interpret avtar backup log status lines.
• Avamar: What happens when avtar reads a file during the file scan phase.
• Avamar backup runs slow due to third-party software modifying metadata for unchanged files.
• Avamar - Poor backup performance for Avamar client running Sophos anti-virus.