Avamar shows up to ~30% usage even after all backups have been deleted and garbage collected
Summary: An Avamar grid that was previously full is cleaned of data. After, after garbage collection has removed all eligible data, it continues to show ~30% usage.
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.
Symptoms
An Avamar grid has been used for backing up data.
The user carries out the following actions:
After these actions, the "utilization" level drops, but does not fall all the way down to zero as might be expected.
The user carries out the following actions:
- All backups are deleted from the Avamar grid, including backups under the /REPLICATE domain.
- Garbage collection runs repeatedly (over several days). There is no more data left to be garbage collected.
After these actions, the "utilization" level drops, but does not fall all the way down to zero as might be expected.
Cause
The space consumption which the utilization value continues to report is space taken up by Avamar parity overhead.
Parity stripes provide redundancy across nodes and protect against single node failure.
Parity stripes consume space on Avamar. Unlike regular data stripes, once a parity stripe has been created, the Utilization calculation always considers it to be consuming space.
This is so even when a regular stripe contains no backup data.
A parity stripe would still calculate the parity of a stripe that is filled with zeroes.
The fewer nodes in Avamar, the larger the "utilization" level shows when this occurs.
This is similar to the efficiency of RAID 5 disk arrays where space equivalent to one disk is required for XOR parity information. The fewer nodes, the less space is available for the stripes of the parity group.
Parity stripes provide redundancy across nodes and protect against single node failure.
Parity stripes consume space on Avamar. Unlike regular data stripes, once a parity stripe has been created, the Utilization calculation always considers it to be consuming space.
This is so even when a regular stripe contains no backup data.
A parity stripe would still calculate the parity of a stripe that is filled with zeroes.
The fewer nodes in Avamar, the larger the "utilization" level shows when this occurs.
Example:
On an 'empty' three node grid, parity stripes may consume up to ~33% of space.
On an 'empty' four node grid, parity stripes may consume up to ~25% of space.
On an 'empty' three node grid, parity stripes may consume up to ~33% of space.
On an 'empty' four node grid, parity stripes may consume up to ~25% of space.
This is similar to the efficiency of RAID 5 disk arrays where space equivalent to one disk is required for XOR parity information. The fewer nodes, the less space is available for the stripes of the parity group.
Resolution
This is normal and expected behavior. No corrective action is required.
If the grid is once again filled with backup data, the primary stripes are populated and the utilization figure increases.
The rate of increase is slower than when the grid was originally filled with data. This is because the space consumption of the parity stripes is already factored in to the 'utilization' figure.
Parity stripes do not contribute to the increase in 'utilization' as new backups are added to the grid.
If the grid is once again filled with backup data, the primary stripes are populated and the utilization figure increases.
The rate of increase is slower than when the grid was originally filled with data. This is because the space consumption of the parity stripes is already factored in to the 'utilization' figure.
Parity stripes do not contribute to the increase in 'utilization' as new backups are added to the grid.
Affected Products
AvamarProducts
AvamarArticle Properties
Article Number: 000038867
Article Type: Solution
Last Modified: 03 Jun 2024
Version: 6
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.