Use two different database files for config and history

[marvinruder]

⚠️ Please verify that this feature request has NOT been suggested before.

• I checked and didn't find similar feature request

🏷️ Feature Request Type

Other

🔖 Feature description

I would like to be able to store the configuration of Uptime Kuma and the history data in two different database files. Ideally, the history database can be thrown away at any time (while Uptime Kuma is not running) without causing any problems.

✔️ Solution

A database file in /app/data/config/kuma.config.db (with -shm, -wat etc.) containing all of Uptime Kuma’s configuration, and a database file in /app/data/history/kuma.history.db (with -shm, -wat etc.) containing all of Uptime Kuma’s saved history information, the latter of which can be safely discarded of whenever Uptime Kuma is not running, and is silently recreated if missing at the next startup.

❓ Alternatives

For backups of the Uptime Kuma configuration, I considered

• Making use of the deprecated config JSON export (which is 1. deprecated and may not export all information relevant for recreating my Uptime Kuma instance and 2. must be done manually after every configuration change)
• Backing up the current database, which leaves me with unneccesarily large incremental backups.

📝 Additional Context

Currently, all information, including history, appears to be stored in the /app/data/kuma.db database. I would like to include the configuration information in my server’s incremental backups, so that after restoring the server from a backup, Uptime Kuma continues to work without any additional effort. The history information in the same database however

• is quite large compared to the configuration (several 100 MBs), and
• changes constantly while the configuration changes rarely,
  so I end up with either large incremental backups every day or no backup of my configuration at all.

The proposed solution can be used to bind the docker container’s /app/data/config to some folder in my home directory, which is backed up regularly, while the docker container’s /app/data/history would be bound to some unimportant directory like /var/cache that is excluded from backups.

[otbutz]

I strongly support this. Moving to a time series database like InfluxDB could be the next big step.

[vercas]

Right now, Uptime Kuma hammers my disks so badly, it literally cannot perform its own checks because it has to wait for its database to finish its operations.
With over 100 checks (at least half of which are at the minimum interval), this stalls Uptime Kuma for as much as 10 minutes sometimes.
Being able to leave the config on my spinning rust (which has redundancy and regular backups) and having the history on a separate SSD (or even just in memory) would be incredibly helpful.

[otbutz]

I'd go even further and use a sqlite database per monitor.

[cypa]

that's obvious
config should load first and fast to the browser page

[zwimer]

This would also be really useful for anyone who backs up their configs with .git or some other version control software

[CommanderStorm]

No, for that you would use a git-ops based notification system instead.
See gatus for example.

[zwimer]

No, for that you would use a git-ops based notification system instead. See gatus for example.

If this is in response to my comment, I might have been misunderstood. I meant by splitting data/history from the config, you could backup the settings of UptimeKuma without backing up any data it's pings/requests/tests aggregate by running. I.e. you could backup the settings of the app (like dark mode, light mode, which hosts to ping, etc.) without any of the data it produces. Unless I misunderstand, gatus is for an entirely different purpose than version control so I am assuming I was unclear before.