Avamar: Capacity Troubleshooting, Issues, and Questions - All Capacity (Resolution Path)

Capacity can be seen as the data or disk space used on a server by client backup jobs of client data.

Capacity issues can prevent normal server functionality from adding new data, or sometimes allowing old data to be cleaned up and removed.

• Training
• Education
• Questions
• Issues with Garbage Collection (GC) failures
• Operating System (OS) capacity issues
• GSAN capacity issues
• Metadata Capacity issues
• Data Domain (DD) integration capacity issues

Validate that each troubleshooting step below is true for your environment. Each step provides instructions or a link to a document, to eliminate possible causes and take corrective action as necessary. The steps are ordered in the most appropriate sequence to isolate the issue and identify the proper resolution. Do not skip a step. If there are multiple issues occurring in different ways with capacity, they must be addressed in a particular order too.

Although most of the steps only mention Avamar, both "Avamar - NetWorker" and "Avamar - Data Domain" integrations can still produce many of the issues below.

Step 1: Information Collection: Generally to understand Avamar capacity issues, "Paint a Picture" to see the entire issue and situation. Sometimes, one aspect of capacity can impact another, or some might not realize initially that there are multiple issues. There must be a complete understanding of the issue to start troubleshooting.

See Avamar: How to gather information required to troubleshoot capacity issues for information gathering.

Step 2: Education and Training: If a customer is looking for education or understanding on how capacity works, what certain values mean, and so forth, this article can be used. It is still a good idea to understand their issues and "Paint a Picture" because questions or education can often be the result of capacity issues.

See Avamar Capacity General Training - Resolution Path for Education and Training-related capacity issues.

Step 3: High OS Capacity:  From the collected output in Step 1, check the OS Capacity values. OS capacity is limited by the HIGHEST usage value in all partitions, even if others are lower. The highest value is the "limiting factor" and must be reduced.

If the highest usage value of any node partition exceeds 89%, see Avamar OS Capacity (Resolution Path)

Step 4: Garbage Collection Error or Failures: From the collected output, if an Avamar Garbage Collection job outputs error messages, that must be addressed next before remaining types of capacity issues.

For this type of issue, see Avamar - Troubleshooting Garbage Collection (GC) Failures (Resolution Path)

Step 5: High GSAN Capacity:  From the collected output, if there are no OS capacity issues and GC is not showing error messages, then review the GSAN capacity values: 

From status.dpn, a value of 65% means that the grid is full (aka "admin" mode or read-only) and there is no room left for capacity growth.

For these situations, see Avamar GSAN (or User) Capacity (Resolution Path)

Step 6: Metadata Capacity:  When a Data Domain is integrated with Avamar, a new capacity limit is introduced - Metadata Capacity. Metadata Capacity is capacity found on Avamar itself.

With Data Domain integrations, data can be directed and sent to Data Domain to store, but Avamar still contains the backup files' metadata on Avamar. Avamar tracks this capacity of metadata as Metadata Capacity.

After steps 1-5 have been reviewed, and any capacity-related issues addressed, review Metadata Capacity resolution in Avamar Metadata Capacity Resolution Path.

Step 7: High Data Domain Capacity:  When a Data Domain is integrated with Avamar, the Data Domain server itself can fill its capacity.

The following Resolution Path article: assists to determine:

• Which potential issues from Avamar may cause Data Domain capacity to grow or fill up
• Some Data Domain specific issues
• If the Data Domain is full for reasons unrelated to Avamar.

After steps 1-6 have been reviewed, and any capacity-related issues addressed, review Data Domain High Capacity from Avamar Integration Resolution Path

Other Issues: These can still be seen as concerns, or issues having an affect on capacity:

• Replication Source and Target Capacity do not Match: When replicating data with Avamar or any integrated products, there is an expectation that capacity matches on the replication source and replication target grids.

• Management Console Server (MCS) reports the following message:

2012/10/06-21:11:09.75264 {0.4} [manage:3070]  ERROR: <0001> diskinfo::update invalid disk space parameters dev=831 total=1906261MB avail=1675818MB reserved=223410MB maxmb=223978MB newavail=1675818MB reservedoverflow=1 availmboverflow=0 

This is a reporting issue on stripe capacity in the MC User Interface (UI) only vaguely related to the other capacity topics discussed here. There is no detected impact of this other than seeing the message in the UI.

• • • Avamar: Server reports "diskinfo::update invalid disk space parameters" when the value of "reserved" is smaller than "maxmb"
    • Avamar: Server reports "diskinfo::update invalid disk space parameters" due to full data partition

• Capacity Forecast Reports:

• • Avamar Administrator dashboard shows erratic capacity forecast for Data Domain