Log Retention Calculator

Calculate storage needed to retain logs for a given period at your ingestion rate.

About Log Retention Calculator

Total log storage scales linearly with daily volume, retention window and replica count, and is reduced by whatever compression ratio your storage backend achieves at rest. Formula: storage = daily_volume × retention_days × replicas / compression_ratio. This is the core sizing calculation for provisioning Elasticsearch/OpenSearch data nodes, S3/object storage buckets, or any log pipeline's storage tier.

Formula

storage_GB = daily_volume_GB × retention_days × replicas / compression_ratio

daily_volume_GB: Raw log volume ingested per day (GB)
retention_days: Number of days logs are retained
replicas: Number of stored copies (including primary)
compression_ratio: Compression factor at rest (e.g. 5× means 5:1)

Worked example

With the default values below, Log Retention Calculator returns Total Storage Required of 600.0. Change any input above and every figure here is recalculated in your browser.

Inputs used

Daily Log Volumeaccepts 0–1,000,000 GB/day: 50 GB/day
Retention Periodaccepts 1–36,500 days: 30 days
Compression Ratioaccepts 1–100 ×: 5 ×
Replica Countaccepts 1–100 copies: 2 copies

Results

Total Storage Required: 600.0 GB
Total Storage Required: 0.586 TB
Compressed Daily Volume: 10.00 GB/day
Monthly Storage Growth (incl. replicas): 600.0 GB

Step by step

1Raw total volume over retention= 1500.0GB
2Compressed daily volume= 10.00GB/day
3Total storage: daily × retention × replicas / compression= 600.0GB

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax or fees or charges into account.
Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

What's a realistic compression ratio for logs?

Plain-text structured logs (JSON) typically compress 5-10× with standard algorithms (gzip, zstd); highly repetitive log formats can reach higher ratios, while already-compact binary formats compress less. Measure your own backend's actual ratio for accuracy.

Why multiply by replica count?

Distributed stores like Elasticsearch/OpenSearch keep replica shards for durability and read scaling, and multi-region setups may keep full copies elsewhere — each replica consumes its own storage, so total capacity must account for all copies, not just the primary.

Should retention be based on compliance or cost?

Often both — compliance requirements (e.g. security logs kept 1 year+) set a floor, but cost usually drives tiering: keep recent logs on fast/expensive storage and move older logs to cheaper cold storage or delete them once compliance windows pass.

Does this include index overhead (e.g. Elasticsearch metadata)?

No — this estimates the compressed log payload only. Search engines like Elasticsearch add index overhead (inverted indices, doc values) that can add 20-50%+ on top of the raw compressed size depending on mapping and field count.