Backups and updates

Keeping events

SIEMLite keeps events for two years by default. Change it on the System page (Keep events: 30 days, 90 days, 1 year, 2 years or any number of days up to ten years); it takes effect at once. Once a day, events older than that are deleted, whole days at a time, and making the period shorter deletes them straight away (after asking). Before the page sets it, -retention-days (SIEMLITE_RETENTION_DAYS) does.

Each event is stored under its own date, even when it arrives late, such as a batch of old logs sent at once. An event dated before the retention period is refused, since it would be deleted straight away. When 50 or more events more than 30 days old arrive from one source in one go (a burst ends after a quiet minute, or after ten minutes), SIEMLite records it in the audit log and the built-in rule Mass ingestion of late logs raises a High alert naming the source, how many events, and the dates they cover. The events themselves keep their own severity. Old logs loaded in bulk on purpose raise it too: close the alert once you know why.

Backups

On the System page, choose Create backup now, or set automatic backups to run every 6 hours, every day or every week, keeping the newest 1-365. A backup is a compressed copy of everything (every day's events, users, sources, parsers, rules, alerts and settings), made while SIEMLite keeps running and logging.

• Restore: SIEMLite checks the backup, saves the current database as a "Before a restore" backup, restarts, and comes back with the backup in place, usually within seconds. To undo, restore the "Before a restore" backup. Backups from older versions are upgraded as they open; backups from newer versions are refused. Version 0.7 and earlier can't restore backups made by 0.8 or later.
• Download a backup to keep a copy off the server, and Upload one (a .tar.gz, a .db.gz from before version 0.8, or a .db file) to move SIEMLite to a new server or recover after losing the old one. Uploads are checked before they're accepted.
• Old automatic backups are removed as new ones are made. Manual, uploaded and "Before a restore" backups are only removed when you delete them.
• Backups are kept in <db folder>/backups (/data/backups with Docker, inside the same volume as the database), or wherever -backup-dir points. Keep copies somewhere else too: download them, or point -backup-dir at other storage.

From the command line (works while the server runs; a restore is applied at the next start):

./siemlite backups create
./siemlite backups list
./siemlite backups restore -name siemlite-20261003-211924-manual.tar.gz

Updates

The System page shows the version you're running and checks GitHub for a newer release (at most every six hours, or when you choose Check now). When one is out, Update and restart downloads the build for your platform, checks it against the release's SHA256SUMS, swaps it in for the running program and restarts, usually within seconds. Nothing changes if the download or check fails. Updates are recorded in the audit log. Make a backup first if you might want to go back: a newer version can upgrade the database in ways older versions can't read. Pass -update-check=false (or SIEMLITE_UPDATE_CHECK=false) to stop SIEMLite contacting GitHub at all.

Everyone is signed out when SIEMLite changes version, however it was updated (the button, docker compose pull, a new binary, or going back to an older one), so people sign in again on the new version. Restarting the same version keeps sessions. The audit log records it ("SIEMLite changed from v0.25 to v0.26: everyone was signed out"), and the person who used Update and restart is told why when the sign-in page comes back.

• A plain program is replaced in place. The button appears when SIEMLite can write to its own folder. A systemd service installed with siemlite install can't, by design: update it with sudo ./siemlite install.
• Docker can't replace the program inside the image, so the update is saved in the data volume (/data/bin) and the image's program hands over to it each time it starts. It survives restarts and docker compose up -d. When you later rebuild or pull an image that is as new, the saved copy is removed automatically. If a saved update doesn't come up after two starts, it is removed and the image's own version runs, so a bad update can't stop the container from starting. This needs no access to the Docker socket. docker compose exec siemlite siemlite ... commands (and siemlite version) still run the image's own version until the image is rebuilt or pulled.
• If SIEMLite can't write where it needs to, the card says so and suggests ./update.sh (see Run with Docker).