Can you be more specific on which log files?

I ask because there are a few "log files" which are heavily used in the process of the client-side deduplication that should not be removed. These are the files loaded into memory at the start of the backup.

There is a flag that can be set to limit the retention of the "not-as-important" log files on the client, which is:

--loglifetime=##

Where ## is the number of DAYS.

Best,

Steve

Hi Steve,

These are mainly the same log files which are available on the activity. I am also taking database backups, so there are logs created for DB backups and log backups also.

Additionally there are many .alg files which are created.

The flag which you mentioned, does it need to be added in avtar.cmd file in the client server ?

Are you talking about P_cache and F_ cache files ,even this will allocate more space on the client side.. if this are the files you can delete the files. but a problem for this the next backup which will initiate after deleting it will take long time for completion as this files are related to deduplication on client side and deleting this will not effect the backups but time consuming will be a lot .. best practice is as per the standards allocate 1/8th of memory size for this files .. 

the p_cache and f_cache do take considerable amount of space but I know these are important, so I am not deleting them.

the log files I am referring to are the job logs which are also visible on the activity in Avamar by double-clicking on the job.

The issue here is all log files since the start of the first backup are present on the client server in /usr/openv/avamar/var/clientlogs and I want to limit these to say 7-10 days after which they should expire or avamar should delete them from the server

Correct. Putting the flag above in the cmd file in the client's var directory should do the trick.

Let us know how it goes!

Best,

Steve

Steve,

What is considered "not as important" log files, where do these log files reside ?

Thanks

There are few things I find strange here:

• The logs should be small, maybe a few MB if that, are they very large and taking up a lot of space or is the client just very tight on space? Maybe there are some debug or verbose options enabled? How big are these logs files exactly?

• By default we should only keep the logs for 14 days, then avagent should remove them automatically. In "/usr/local/avamar/var/avagent.log" you should see lines like this everyday which indicates the logs are being cleaned up:

          2014-06-27 07:16:43 avagent Info <8517>: Starting log file maintenance in "C:\Program Files\avs\var" and "C:\Program Files\avs\var\clientlogs"

• Please also note that removing the logs from the client side will also mean they will not be available in the Avamar GUI, as the Avamar GUI recovers the logs directly from the client (they are not recovered on the Avamar server).

As discussed later in this thread you can add in the "--loglifetime=##" flag to avagent.cmd and restart the avagent service, however I because the logs are small I would not see the point of reducing from 14 days to 7 days. Please also note that having 14 days worth of logs may be useful for troubleshooting purposes.

Rather than reducing the amount of logs being kept I would work on understanding the root cause of why the logs are taking up so much space by answering some of the questions above. Once the size has been reduced or the default retention is working as expected, the issue should be solved and we will still keep our 14 days worth of logs.

Thanks

Adam

Hello Adam,

The client is configured for SAP DB backups plus archival logs, so a lot of .log files and .alg files were getting created on daily basis. Majority of the space is occupied by cache.dat files.I expected one p_cache file and f_cache file which will get updated but there it has created multiple files.  any reasons why ?

I was not aware of the minimum 14 days retention of logs, so asked if we can set up the expiry for a set no. of days. The loglifetime flag works perfectly. The issue was the filesystem was filled up and client wanted to clean up space. Since I cannot delete the cache files, freeing up space from logs was one option although less. I have asked them to extend the size of the file system.

$ du -sh clientlogs

1.8G    clientlogs

These cache files haven't been updated for over 20 days now and are still present.

                    Size          Date                                             name

You are creating multiple cache files because I believe cacheprefixes are being used or maybe because of the way the SAP DB backups are being run, more details on this are available in the Avamar 7.0 Best Practice Guide page 56.

I am unsure why you have some cache files that are no longer being used, they can likely be removed as after every backup, even if there are no changes the cache files are updated, unless there is a specific dataset / group that has not run since June 21st.

You can check the datasets, to see if cacheprefix has been added in and you should see some datasets with cache prefix "ABC_5" etc. Maybe the datasets using the cache prefix "ABC_8_", "ABC_7_", "ABC_6_" and "ABC_10_" no longer exist or have been removed by the customer and that is why those cache files are not being used. If that is the case they can be removed.

Another option would be to relocate the cache files to another file system  where there is more run, this is discussed in "Resolution A of the KB (note you are not using the "paging file cache" here so the rest of the KB is irrelevant) Mitigating the potential impact of the size of the paging file cache.

Either way It would make much more sense to work on reducing the space used by the caches rather than reducing the amount of logs that are kept. Hopefully some of the above points will help.

Regards,

Adam