dirkbucket
2 Bronze

Avamar - Full Backup Understanding

Jump to solution

I have read that Avamar only does a "Full" backup.  Is this true? 

If Avamar only does full backups why would the same server some days take 15mins to backup and others days it may take 1 hour to backup?

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
ionthegeek
4 Beryllium

Re: Avamar - Full Backup Understanding

Jump to solution

Avamar backups are "incremental forever" but are restorable as though they were run as fulls.

tl;dr: Change rate

I'm assuming you're talking specifically about filesystem backups. Database backups work a bit differently but I can talk about that if you have questions there. I've simplified a bit for clarity.

For filesystem backups, Avamar will "stat" each file and generate a hash of the file attributes. It then looks this hash up in the file cache and if it finds the hash, it will just mark the file as part of the new backup and move on. If the hash is not found in the cache, the file will be re-chunked. The client just marks unmodified chunks as part of the new backup so they don't have to be re-sent. Any modified chunks will be sent to the storage.

Any time difference is normally a result of a higher (or lower) file change rate. 90% or more of the client's performance gain is related to the cache. Since modified files need to be read from the disk in full to determine if any chunks inside the file have changed, having many modified files or large modified files will result in a longer backup time.

One other possibility is that some days there is contention for I/O resources and some days there is not. Backup performance for any individual client is generally limited by the available I/O capacity of the client system.

View solution in original post

0 Kudos
2 Replies
ionthegeek
4 Beryllium

Re: Avamar - Full Backup Understanding

Jump to solution

Avamar backups are "incremental forever" but are restorable as though they were run as fulls.

tl;dr: Change rate

I'm assuming you're talking specifically about filesystem backups. Database backups work a bit differently but I can talk about that if you have questions there. I've simplified a bit for clarity.

For filesystem backups, Avamar will "stat" each file and generate a hash of the file attributes. It then looks this hash up in the file cache and if it finds the hash, it will just mark the file as part of the new backup and move on. If the hash is not found in the cache, the file will be re-chunked. The client just marks unmodified chunks as part of the new backup so they don't have to be re-sent. Any modified chunks will be sent to the storage.

Any time difference is normally a result of a higher (or lower) file change rate. 90% or more of the client's performance gain is related to the cache. Since modified files need to be read from the disk in full to determine if any chunks inside the file have changed, having many modified files or large modified files will result in a longer backup time.

One other possibility is that some days there is contention for I/O resources and some days there is not. Backup performance for any individual client is generally limited by the available I/O capacity of the client system.

View solution in original post

0 Kudos
avamar_exorcist
3 Argentium

Re: Avamar - Full Backup Understanding

Jump to solution

If you have a reliable source of coffee and would like to do some background reading on what Ian discussed, take a look at the following articles

  • 335029 - How to understand Avamar Client backup performance and identify performance bottlenecks
  • 335281 - How to interpret avtar backup log status lines
  • 207915 - How to identify which files took a long time to be processed during an Avamar backup
  • 209351 - What happens when Avamar reads a file during the file scan phase?