At the beginning of the backup, the avtar process loads into memory two cache
files from the var directory (this directory is found in the Avamar installation
path).
The first of the cache files is the file cache (f_cache.dat). The file cache stores a
20-byte SHA-1 hash of the file attributes, and is used to quickly identify which files
have previously been backed up to the Avamar server. The file cache is one of the
main reasons subsequent Avamar backups (that is, those that occur after the
initial backup) are generally very fast. Typically, when backing up file servers, the
file cache screens out approximately 98 percent of the files. When backing up
databases, however, the file cache is not effective since all the files in a database
appear to be modified every day.
The second cache is the hash cache (p_cache.dat). The hash cache stores the
hashes of the chunks and composites that have been sent to the Avamar server.
The hash cache is used to quickly identify which chunks or composites have
previously been backed up to the Avamar server. The hash cache is very important
when backing up databases.

Avamar chunks the files and create a hash value and stores the data in the format of chunks. It does not rely on NTFS change journal toe check if the file is modified or not. It uses it own algorithm which checks the hash value

Avamar walks the entire file system of the defined dataset and examines the file metadata characteristics each time a backup is initiated.

By default the client doesn't use or alter the archive bit in Windows. There are flags to override the behavior but we don't encourage their use and I've never come across any situation where it's been necessary or desirable to do so.

Your EMC sales rep would be a good person to approach to ask for some slides which go into detail about how the client process goes through the 'chunk, hash, compress' operations.

Hope that helps.