That could be because I've just updated it and it's awaiting review.
Here's a copy/paste:-
Symptoms
The Avamar system is full or approaching full capacity
Resolution Aside from preventing any new backups, there are two options available. 1) Expand the system by adding new nodes to it please contact your EMC sales representative or EMC partner for details).
2) Reduce the amount of data stored on the system by tuning retention policies.
In order to identify the clients which are contributing the most amount of data change on the Avamar system we use the script 'capacity.sh'.
The script can help us analyze the amount of data added and removed from the system on a daily basis and to understand which clients cause the greatest amount of data change on the system in order to tune retention periods.
To run the script:- =================== a) Login to the utility node as the admin user b) run /usr/local/avamar/bin/capacity.sh
NOTE: In older versions of Avamar, this script is not present on the systme and needs to be manually copied to it. See below for details.
1) Upload capacity.sh to the Avamar utility node using SCP on a Linux command line or with WinSCP on Windows.
2) Place the script in the /home/admin directory.
3) Log in to the Avamar system as the 'admin' user.
4) Change to the directory where you uploaded the script.
5) Copy the script to the /home/admin directory: cp sched.sh /home/admin/ 4) Change the permissions to allow the script to be executed:
chmod 744 /home/admin/capacity.sh 5) Run the script: ./capacity.sh
Understanding the output from the script:
The top part of the script output shows the date, the amount of new data added, the number of backups taken, the amount of data removed by garbage collection and the net change rate on the system (data added minus data removed). This section gives you an idea of what is happening on a day by day basis. You can use this to understand, at a glance, on which days experienced large increases in backup data and how data has been removed in the garbage collection sessions.
It will be very clear if there were an unusual amount (or lack of) backup data or if garbage collection failed to run on a particular day.
The bottom part of the script shows which clients added the most data in the last day. Below we see that 7923mb was added to the system in the last day. We are given a breakdown of this amount by the three clients which most contributed to this new data.
In this case, if we needed to reduce retention periods to lower the amount of data stored on the system we would concentrate on these clients.
Top Three High Change Clients: -------------------------- Total for all clients 7923 mb 100.0% aaaaa.xxxx.emc.com 2381 mb 30.1% bbbbb.xxxx.emc.com 1990 mb 25.1% ccccc.xxxx.emc.com 1282 mb 16.2%
Further information: 1) View the output with courier font for best results. 2) Run ./capacity.sh --help for further options. 3) mb as noted in the script should actually be taken to be'Mb'
To answer your first question, no its not the only client, but we have only one client running backup of exchange, and this is the server getting most new bytes.
Backup of windows filserver have lesse then 0,05% new bytes each day.
Your server is pretty much utilized and might indicate sizing issue in first place. As to growth, this might be an issue with size of hash cache as well. If your hash cache is not big enough (modified) to get all chunks then you will always see some more growth there. But yes, it seems as it is growing for you and current solution might not be in place for you. Is that AVE that you use? You may wish to perform (or support for you) some aggressive garbage collection you to see if you can free up some space. Also, newer version will give you over web prediction on when your server might get into red zone (even now at 90% I would see that as red zone). If this is AVE, do you know if read-only value has been decreased since initial install?
Ok, we can see from this that over the last two days the net data change on the server has been negative. If this trend continues the Avamar storage utilisation should steadily reduce.
If the "Net Change" becomes positive again then you'll need to revisit the retention policies and reduce them some more (or expand the system) .
No need to worry about the client hash cache. It doesn't have any effect on the amount of data sent to the server. It simply reduces the amount of time the client takes to scan the dataset.
No need to worry about the client hash cache. It doesn't have any effect on the amount of data sent to the server. It simply reduces the amount of time the client takes to scan the dataset.
You are right... I mixed up this with something else when posting before... mea culpa.
johhen2
4 Posts
672
0
Posted June 15th, 2009 08:00
Unable to Display Solution
The solution you requested either could not be found or is not available for viewing