Backups on LMS 3.01

[dmistry21]

Hello

We're experiencing quite 'demanding' space requirements from our backups.  Within the dbbackup.log sometimes the backup fails due to insufficient space on the disk.  Currently the space required is stating 60gb.  Does this sound quite excessive ?

Looking at what its trying to backup the big files are the syslog.db files but there is a 17gb file which is named filebackup.tar, does anyone know what this is and can it be removed/excluded from the backup ?

Many Thanks

[yjdabear]

There're multiple copies of filebackup.tar in the backup, one for each app you have installed. For example:

./cmf/filebackup.tar

./rmeng/filebackup.tar

./campus/filebackup.tar

I highly doubt you could get away with deleting any of the filebackup.tar from the backup. What you can do is to specify which app's filebackup.tar this 17gb one is, then there could be some pertinent feedback on how to reduce the size of the app's output (and thereby the size of the backup as well).

[dmistry21]

Hi

Thanks for the response.  The filebackup.tar isthe one from ./rmeng/filebackup.tar.

Are there ways that this can be trimmed ?  Also are there ways that the syslogfirst, syslogsecond and syslogthird database files can be reduced ?

Many Thanks

[yjdabear]

Sure, if syslogfirst, syslogsecond and syslogthird are the main culprits, you can get a DBSpaceReclaimer.class that TAC can walk you through to clean them up. In fact, you went through this exercise before: https://supportforums.cisco.com/thread/175690

I had extensive syslog msg filters configured, so maybe that's why I never had size problems with those syslog data stores. IIRC, the only time I ran into an unacceptably large LMS backup, it was because I forgot to configure any purge policy on "change audit". RME keeps track of every "change" of managed devices, so that grew very large very quickly. So you might want to check on that too.

[dmistry21]

Thanks for the response.

I remember going through the exercise of using DBSpaceReclaimer.class with TAC but we couldn't get it to recl;aim the space and the only solution at the time was to re-initialize the database which would've meant we would lose all inventory data, syslog backups and configurations.  To be honest these databases never exceed 10gb each so it seems like the purge policy is working correctly.  Our change audit policy is set to purge changes older than 365 days which I believe is working although e-mail notification is not configured yet.

So is there a way of managing the data that goes to the filebackup.tar from RME ?