Skip to content

Storage keeps growing

The database or the server's disk fills up faster than expected. The cause is almost always a mix of retention settings, an overly chatty check or enabled log collection — rarely a real leak.

1. Look before you act

Admin → System → Resources → "Storage" sub-tab is the central place for everything around disk and DB usage:

  • Usage — how much of the partition is used (warning from 85 %), total database size, growth per day after compression (and raw before), write-ahead log, backups
  • Data class table — per data class size, compression state, row count, oldest data
  • "Where the space goes" — Docker breakdown (images, containers, volumes, build cache) including backups and map images
  • "Largest data producers" — which checks wrote the most in the last 24 hours

Details: Resources.

2. Identify the biggest data producer

Before touching retention, look at "Largest data producers" — often a single check is the cause: too short an interval, a check that writes many values at once (e.g. an SNMP walk with many sensors), or a heavy metadata payload. The fix is usually simpler than shorter retention: raise the interval of that check.

3. Logs as a common driver

Log collection via the agent (files, journald, Windows event log) can add noticeably to storage at high log rates — far more than plain metric checks. Check:

  • Is log collection running on hosts where it isn't needed?
  • Does the log retention (default: compress after 3 days, keep 30 days) fit your volume? The daily count per device, source and level is kept indefinitely even after the full text has expired.
  • Does a source collect needlessly chatty levels? journald sources have a minimum level (new sources start at warning).

Details: Logs.

4. Check and adjust retention

Under Admin → System → Resources → Storage, retention is grouped by kind of data:

Kind of data Data classes Default
Events — something happened at a point in time Status changes, audit log, sent notifications, delivery journal, anomaly events kept indefinitely (status changes compressed after 7 days)
Metric series — continuously measured numbers Metrics (detail) compress after 3 days, keep 90 days
Raw material — only useful while fresh Logs (monitored systems) compress after 3 days, keep 30 days
Diagnostic events compress after 7 days, keep 90 days
Agent and collector heartbeats compress after 3 days, keep 90 days

Limits: compress between 1 and 60 days, retain between 7 and 3650 days — or 0 for unlimited.

Three suggestions fill the fields with one click — nothing is saved until "Save & apply", so you see every number first:

Suggestion Metrics Logs Diagnostic events, heartbeats Events
Frugal 30 days 7 days 30 days 730 days
Standard 90 days 30 days 90 days unlimited
Archive 365 days 90 days 365 days unlimited

Saving takes effect immediately and permanently — data that has been deleted cannot be brought back. If you enter a limit for events, the page warns right there: events cannot be restored and make up only a small part of the database. The biggest lever is almost always metrics and logs.

Long-term history is kept anyway

Even when the detailed metrics are deleted after their retention, the condensed values remain: 5-minute values 14 days, hourly values 395 days, daily values indefinitely. The check history automatically switches to these values for older periods; the status colours come from the status history. When an agent or collector was down stays visible even after the heartbeats have expired.

Status history on very large installations

Since v1.900.0 the status history is stored compressed. The conversion runs automatically at start — except on very large installations, because it briefly locks the table. There Vesana reports in the diagnostic log with the command for a maintenance window.

5. "Clean up now"

The "Clean up now" button applies retention and compression immediately instead of waiting for the next scheduled run (every 6 hours). If uncompressed data is waiting, the page shows how much. The result is shown afterwards, e.g. "Last run: 12 chunk(s) compressed, 4 removed by retention".

6. Compression doesn't seem to be working

If the page says "Compression isn't working …", older data lies uncompressed and takes many times the space. Often the maintenance run simply hasn't happened yet (up to 6 hours delay), or freshly written chunks are naturally still uncompressed (compression only applies after the configured period, e.g. 3 days). Run "Clean up now"; if the message stays afterwards, a support bundle helps. Recompression errors appear in the diagnostic log (timescale_recompress_failed).

7. Disk space from Docker itself

Not all growth comes from the database — old, unused Docker images and build cache pile up over time. The updater removes old Vesana images itself on every update. The "Where the space goes" panel shows the rest; docker image prune or docker builder prune (manually, outside the GUI) cleans up further, but not while an update is running. No docker volume prune — the volumes hold the database and backups.

Checklist

  1. Open Resources → Storage, look at usage + growth/day
  2. Check the largest data producers — is a single check responsible?
  3. Is log collection sensibly limited?
  4. Does retention per kind of data match what you actually need?
  5. Use "Clean up now" instead of waiting for the next 6-hour run
  6. Include Docker leftovers (images/build cache)

Next