LMS 3.1 backup

[dmistry21]

Hi

I'm running LMS 3.1 on a Windows platform. I've encountered an issue where the backup is failing due to insufficient disk space according to the dbbackup.log. It is stating that the required space is just over 26gb for the backup. That sounds quite large to me, can this be made smaller by including exclusions to the backup or is this a normal size ?

Also if i remove the last successful backup which is in the following location: C:\backup (about 1 week old), will this write a new backup within this directory or will it look for the previous backup. The current folder is labelled "89" within C:\backup and within backup we have Generations set to "1". I've attached the dbbackup.log for reference.

Many Thanks

[Joe Clarke]

The backup is what it is. You can't change what is backed up. Doing things like configuring config and job purge may help (in RME), but if the size is being taken up by databases, then you will need to allocate more space on your backup volume.

Yes, you can safely remove old backups. However, I recommend you retain multiple revisions of backups just in case. I typically recommend at least three revisions. This means that your backup volume must have at least enough space to hold four backups.

[dmistry21]

Thanks for the response Joe.

It looks like the majority of space is being taken up by files such as:

Syslogfirst.db = 8gb

Syslogsecond.db =4gb

Syslogthird.db = 6gb

As these are database files it looks like extending the backup volume maybe an option we have to consider as I assume these databases are just going to grow larger and shrinking databases is not really an option.

Many Thanks

[Joe Clarke]

Actually, these are data spaces, and not full databases. They can be purged completely using a tool called DBSpaceReclaimer.class. This tool is available from TAC.

[dmistry21]

Hi Joe

I'm still waiting on this tool from our partner. I just wanted to confirm when running the tool it will remove the dataspace (i.e the space where the syslog lives) where there is unused space. Is there any other data that it will remove ?

[Joe Clarke]

The tool only removes the three syslog dataspaces. None of the other RME data will be touched. The net result is that all of the syslog messages in the RME database will be lost.

[dmistry21]

Hi Joe

Thanks for the response. As you mentioned the syslog messages will be lost from the database, does this include logs from within the C:\program files\CSCOpx\logs directory ?

Also you mentioned in the earlier thread about keeping 3-4 revisions of the backup. We backup that server to external media every night, is it best practice to still keep 3-4 revisions in this type of environment as we only have space for 1 at the moment ?

[Joe Clarke]

No, the log files will not be touched by DBSpaceReclaimer.class. If you need to trim log files, you should use the included logrot.pl utility. This tool is documented in the Common Services online help. Just search for logrot.

Yes. If something bad happens, and you back that something bad up, it's best to have multiple revisions so you're more likely to have a known good backup. For example, let's say someone accidentally purges some critical devices from DCR on Friday. The backup runs Friday, Saturday, and Sunday. On Monday, someone notices, but if you don't have enough revisions of backup, you may not be able to recover.

[dmistry21]

Hi Joe

I've tried to run the dbspacereclaimer.class tool and have had a few problems. The following is what's been tried:

a)pdterm RMEDbEngine

b)pdexec RMEDbEngine

c)C:\Program Files\CSCOpx\lib\jre\bin>java -cp c:\tempo;C:\Progra~1\CSCOpx\lib\classpath;c:\Progra~1\CSCOpx\www\classpath;c:\Progra~1\CSCOpx\MDC\Tomcat\webapps\rme\WEB-INF\classes;c:\Progra~1\CSCOpx\MDC\Tomcat\webapps\rme\WEB-INF\lib\log4j.jar DBSpaceReclaimer

This returned with:

RMEDbEngine needs to be restarted before this tool is run.

SyslogSecond.db cannot be deleted.

SyslogThird.db cannot be deleted.

SyslogFirst.db cannot be deleted.

The same was tried but the SyslogAnalyzer and SyslogCollector before but still have the same issue after restarting the dameon manager and RMEDbEngine.

Tried to re-index the rme database and run the DbSpaceReclaimer tool as below:

a. Shut down daemon manager.

b. after the daemon manager is stopped there was no rmeng.log under CSCOpx/databases/rmeng directory.

c. cd to progra~1\CSCOpx\databases

d. Tried to reindex the databases as follow : dbsrv9 -f c:\progra~1\CSCOpx\databases\rmeng\rmeng.db and it was successful.

e. Start the daemon manager, run pdterm SyslogCollector, pdterm SyslogAnalyzer, pdterm/pdexec RMEDbEngine.

f. Retry the DbSpaceReclaimer.class command.

Same message.

4. a. Tried to change the startup for Damon manager service under Control Panel > Admin tools > Services to manual, and then reboot.

b. Start the RME NG Database service manually from Control Panel > Admin tools > Services.

c. Retry the DbSpaceReclaimer.class command.

I've been advised that the next step is to reinitialize the rme database and reclaim the Syslog*.db files. My only issue with this is that this will remove everything from software distribution and config management so all archives will dissapear I believe. I was wondering whether there may be some other steps that could be tried rather than re-initializing the database as this seems a bit final ?

Many Thanks

[Joe Clarke]

There could be a problem with the syslog tables. DBSpaceReclaimer needs to be done. The TAC engineer that provided you with this class can walk you through enabling the debug, and getting the log. There still may be a way to clear the syslog data without purging the RME database.

[dmistry21]

I've noticed since my post on Jul 30 the sizes were:

Syslogfirst.db = 8gb

Syslogsecond.db =4gb

Syslogthird.db = 6gb

They are now:

Syslogfirst.db = 9gb

Syslogsecond.db =9gb

Syslogthird.db = 6gb

If we don't run DBSpaceReclaimer is the consequence the dataspaces will just grow and grow ?

Also in a worst case scenario, if we re-initialized the database, what data would exactly be lost, is it everything in RME ? We have an integration with ACS so I assume that would have to be broken/rebuilt as well.

[Joe Clarke]

Yes, they will continue to grow. If you reinitialize the RME database, you lose inventory, configs, syslogs, software images, and change audit data. Your ACS integration will not be affected.

[dmistry21]

Thanks for the response Joe.

I'm seeking advise via TAC on enabling debug to start the next stage of troubleshooting.

Going forward is there recommended practises on controlling the size of these syslog.db files as they will continue to grow. I imagine using filters and other mechanisms possibly ?

[Joe Clarke]

Correct. The idea is to keep unwanted data from even being added to the RME database. So, define appropriate message filters so that only the interesting messages make it to the DB. Yes, the DB will still grow, but as long as only relevant messages are being added, the growth will happen more slowly.

[dmistry21]

I've been looking again into how the syslog works and have been looking at our current configuration.

I just wanted to confirm that when entries are written to the syslog.log within c:\prog~\CSCOpx\log at what point are they sent to the Syslogfirst.db, Syslogsecond.db, Syslogthird.db ?

Although these are dataspaces I know if we remove the database spaces it will remove all syslog messages but does this include the syslog.log file within c:\prog~\CSCOpx\log. Also using logrot, is this the only way of retrieving old syslog messages (by using multiple archives) or can you retrieve messages from the RME database ?

Many Thanks