Avamar: What happens when avtar reads a file during the file scan phase
Summary: This article describes what happens when avtar reads a file during the file scan phase of an Avamar backup.
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Instructions
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:
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.
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.
Additional Information
Related articles:
Affected Products
AvamarProducts
Avamar, Avamar ClientArticle Properties
Article Number: 000013952
Article Type: How To
Last Modified: 07 Mar 2024
Version: 7
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.