< Using backupsGetting startedTroubleshooting >
Common pitfalls
There are several common mistakes that can make IPHost function inefficiently, utilize too much resources or otherwise causing various problems. When using IPHost, try to avoid the below scenarios:
- Running network discovery on all the ports and/or for large networks, since
- such a scanning utilizes much system resources and can slow down system for significant amount of time
- if security software is installed within network, such port scanning can be mistaken for attempts to gain unauthorized access and/or look for vulnerabilities.
Instead, scan only for certain ports/services, to find certain services to monitor (such as mail servers, Web servers etc). In case you absolutely need scanning network for new devices periodically, use as few ports to probe as possible.
- Running IPHost installation with many active monitors on busy systems: depending on amount of active monitors and polling frequency, IPHost can demand much resources. If a busy system is used (the one where disk I/O, network traffic, RAM, CPU are actively using by other applications), both IPHost and other resource-intensive applications can show degraded efficiency and slow down system significantly.
Instead, create a virtual machine (or use relatively idle Window system), install IPHost and test it for real. Monitor RAM, disk and network usage to estimate optimal system requirements. One of most optimal ways to run IPHost is using virtual machine (since resource limits can be easily adjusted for VM).
- Using large monitoring data retention period: open “Settings > Monitoring” and pay attention to “Store monitoring data for…” field. Common mistake is to set huge data retention interval (such as several years) for a busy monitoring setup. That will result in creating huge monitoring database (such as tens of gigabytes), that in turn will increase disk I/O and CPU resources required to do database operations.
Instead, set that value to reasonable amount, such as 60-90 days; use automated backups creation feature to create and store monitoring database – save those backups elsewhere in case you could need older monitoring data. You can easily access monitoring data directly from database, thus you do not need to try keeping it for long periods of time.
- Keeping database backups on the same disk where monitoring database is located:
- set “Backup to” target folder to another disk drive (or network share)
- set “Keep last backups” value to at least 7
- make an additional copy of the “Backup to” folder, since IPHost gradually removes older backups, to follow “Keep last backups” restriction; if you would need older backups later, you would want to keep them elsewhere
- pin valuable backups (listed on “Available backups” tab) to prevent them from automated erasing; pinned backups do not count towards “Keep last backups” limit
- set “Generate backup at” (local time) to optimal time interval (such as outside of business hours), to avoid additional load when computer is in use, and/or to properly synchronize with backup services that save the generated backup copies
- Not making backups before significant monitoring setup change: to err is human; when making monitoring setup changes, it’s too simple to make mistakes (such as deleting multiple monitors, or changing an inherited parameter system wide). In case you didn’t save monitoring setup state first, you would have to spend much time fixing the changes.
Instead, prior to changing monitoring setup, click “Settings > DB Maintenance” and click “Generate DB Backup Now”; after the backup is complete, click “Available backups” tab and “Pin” the latest backup, to avoid its loss. If you make a mistake, you can return to the same settings page and use “Restore” button to re-create the monitoring setup state.
By default, IPHost sets up database maintenance (click “Settings > DB Maintenance”) to keep 3 copies of monitoring database in exactly the same folder where monitoring database itself is located. If this isn’t changed, no backup files are ever copied elsewhere, then in case of disk drive failure you risk losing entire IPHost monitoring setup.
Instead,
< Using backupsGetting startedTroubleshooting >
