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.
- Agent crashes
- Automatic rescan of all nodes in a domain
- Bandwidth consumption estimate
- Basic database tuning
- Can I customize the reports in SysOrb?
- Disabling specific checks
- Does SysOrb support SNMP traps?
- Explanation of the score keeper strategy.
- How does HTTP Netcheck work in SysOrb?
- How to automatically update alert group on all nodes to “As domain”
- How to backup SysOrb database
- How to change time interval value of agent_checkin_delay
- How to move the SysOrb server to a new server
- How to quickly set downtime on an agent
- I cannot get all of the "performance counters/cache" entries to appear in SysOrb what should I do?
- Migrating MIB information from one SysOrb installation to another
- Migrating the configuration of a Windows SysOrb server from 32 to 64 bits
- No empty blocks in meta database.
- Script to get a list of nodes which have no AlertGroup
- SysOrb agent is not checking in to the Sysorb server
- SysOrb agent stops checking in from a windows server with very long system uptime
- SysOrb server shuts down unexpectedly
- System uptime no longer updates on windows
- Unable to monitor hardware (fans, disks, temperatures etc.) on Windows
- Upgrading SysOrb on Windows
- Uploading a SysOrb database to Evalesco
- What does KiB and MiB mean?
- What is IPMI ?
- Windows agent late for check-in every hour
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.
