Increase Prometheus data retention

Set --storage.tsdb.retention.time=90d to request 90 days of local history. A size policy can delete older blocks sooner, so longer time retention only helps when there is enough storage. Increasing retention cannot recover data already deleted.

Set time and size limits

prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/prometheus \
  --storage.tsdb.retention.time=90d \
  --storage.tsdb.retention.size=100GB

Apply these settings to the existing process definition and restart through its service or deployment controller. Never run two servers against the same TSDB directory. The documented default is 15 days when neither time nor size retention is specified; size retention is disabled by default.

With both limits set, the earlier constraint wins. The example does not promise 90 days inside 100GB. Expired data is removed in blocks during background cleanup, so neither setting is a strict instantaneous disk quota.

Use the configuration layer that owns your deployment:

Check the exact chart version's values and Operator API. Helm keys are not interchangeable between charts, and a controller may overwrite manual edits to generated Pods.

Estimate capacity, then measure it

A rough estimate for compressed samples is:

bytes per day ≈ active series × bytes per sample × 86400 / scrape interval

At 500,000 continuously active series, two bytes per sample, and a 15-second interval, this is 5.76 billion bytes per day: about 5.76 decimal GB, or 5.36 GiB. Ninety days is about 518.4 decimal GB before allowing for other storage costs.

This is a planning estimate, not a measured capacity guarantee. Series churn, labels and indexes, histogram representation, WAL, head chunks, and compaction affect usage. Prometheus size units such as GB use powers of two; do not silently mix them with decimal estimates.

Monitor disk free space, ingestion volume, and prometheus_tsdb_head_series. Keep headroom: only persistent blocks are deleted for retention, and the WAL/head and concurrent compaction can still consume space. The storage documentation recommends keeping the retention-size target at no more than roughly 80–85% of allocated disk.

Plan longer history and backups

Local TSDB can retain months of data with adequate capacity; it is not inherently limited to a short hot-data window. Longer queries still have to read and process more data. For a larger retention or availability requirement, evaluate Thanos, Mimir, VictoriaMetrics, or a managed metrics service against your workload.

Integration differs: Thanos Sidecar uploads blocks to object storage, while remote-write receivers ingest samples. A TSDB snapshot is a point-in-time backup operation, not an automatic retention extension or archival lifecycle. Copy backups to independent storage and test restoration. The snapshot API requires the appropriate admin API setting and access controls.

Common questions

Will more retention make queries slower? It can increase stored data and the work required for long-range queries. Actual performance depends on query shape, series count, hardware, and caching; there is no blanket guarantee of no impact.

Why is less history available than retention.time requests? Check size retention, disk pressure, earlier deletions, the storage mount, and whether the metric was being collected throughout that period.

References

• Prometheus storage and retention
• Prometheus Operator API
• kube-prometheus-stack values