Tuesday, May 25, 2010

Avamar Capacity

Server utilization, as reported in the Server section of the Avamar Administrator GUI can be misleading. According to the Avamar Administrator help, it shows the "Percentage of total available server storage capacity currently used". This percentage is the highest storage space used on any of the nodes. So if one of the nodes shows 43% useage, then server utilization will show 43% also.

A server utilization of 43% leads one to believe that it is 43% of the "Total Capacity". This is not true, and is very misleading. It is actually the percentage of (Total capacity X 65%). Why 65%? Because that is the storage space threshold when Avamar becomes read only, and backups have to be deleted to get total storage below that mark. This threshold might be different in certain situations, and can be verified by running "avmaint config --ava | grep disk" in the SSH console to the Avamar utility node, and checking the diskreadonly="65" parameter.

To check the actual space used by backups, run the following command: status.dpn and look for the column called %Full. This will show you how much actual space is being used on the Avamar nodes. When this percentage starts getting closer to 63%, then it is time to start deleting backups and clear up space on the Avamar.

So there are two types of storage space percentages reported. One is the actual storage space which is found by using the status.dpn command, and one is a "virtual" storage space reported by the GUI. When the virtual storage space gets to 80%, then a warning is sent out saying that the actual space is getting close to the actual 65% and you should start looking into deleting backups to clear up space on the Avamar.

Thursday, May 20, 2010

Commvault Index Cache

The index cache is the directory where index data is located. Index data is a record of all files, folders and objects that are backed up as part of a data protection job (another name for backup). The index cache is very important to maintain as it enables browsing of backed up data. Without the index cache it would impossible to know what files or folders were backed up, and individual file or folder restores are not possible. As part of any backup job, the index data is written in two places: Index cache, and the backup destination. If the index cache is accidently deleted, or the index data goes beyond its retention period, the index data can be restored by reading it from the backup destination. When you click on a backup job and select browse, it will read the index data from the index cache. If it cannot, it will ask for the index cache to be restored from the backup itself. Commvault maintains a record of where the index data is located on the backup media and uses that media to restore it.

The index cache can either be located on a local drive or a network share. If it is located on a network share, it can function as a shared index cache where several media agents can share one index cache. The advantage of this is that instead of putting the index cache on several servers and taking up space, a shared index cache places the index cache in one central location. The rule of thumb when calculating the space required for an index cache is 4% of the entire data the media agent will be used to protect. So if the media agent is used to protect 10 TB of data over a period of 6 months, you would need 409 GB of space.