Knowledge Base

Knowlegebase articles

Welcome to SysOrb knowledge base. Her you will find detailed explanation on questions regarding SysOrb. The list is under continues development and new articles will be added. You can follow the links below or enter a "key word" to search all of the articles.

How to backup SysOrb database

The SysOrb database is located in three files; main.odb, main.odbj, main.tsdb. They are the ones you need to backup. They contain all the configuration of the checks to be monitored on each machine, and all historical data from these checks.

It is very important that the copies are made in a fashion, that ensures you get a consistent view of the contents of the three files as they were at one single point in time. Otherwise the copies may be inconsistent, and SysOrb may not be able to use them.

The simplest way to ensure a consistent backup is to stop the SysOrb server before starting the backup and then start it again once backup is complete. The downside to this approach is that it leaves you without monitoring while running the backup which is often not desirable nor acceptable.

A much better approach is to create a snapshot of the volume containing the database files and then backup the files from the snapshot. This ensures that all 3 files are backed up at the exact same point in time, thus resolving any problems that may otherwise occur with the files being inconsistent while at the same time leaving your monitoring active the entire time.

How to configure and use point-in-time snapshots on your system is beyond the scope of this article, but Windows has this functionality available as "Volume shadow copy", on Solaris you can use the snapshot feature of ZFS and on Linux you can use "LVM snapshot" provided that you are using LVM (Logical Volume Manager). You should check the documentation of your backup program, to see how to invoke that functionality.
This is the recommended way of backing up SysOrb. It will give you a consistent backup of all node/check configuration and historical data.

One more thing to be aware of is that, due to the way the SysOrb uses its database journal file (the .odbj file), the modification timestamp for the journal file is not updated (on Linux and Windows - this is not a problem on Solaris). This causes some backup applications to skip the file since they believe it to be unchanged, leaving your backup with an ancient journal file that does not match the most recently backed up .odb file.
There are two ways around this problem: 1) Configure your backup application to always back up the database journal even if it believes it to be unchanged. 2) use a program (such as "touch" on UNIX) to update the timestamp of the journal file just before the backup application processes the file.