Log Retention Calculator
Calculate total log storage needed for a given daily volume, retention period, replica count and compression ratio.
Inputs
Raw (uncompressed) log volume ingested per day.
How many days logs must be kept before deletion/archival.
Compression factor applied at rest, e.g. 5× means 50GB compresses to 10GB.
Number of replica copies stored (e.g. Elasticsearch replica shards, cross-region copies).
Total Storage Required
600.0GB
Total Storage Required
0.586TB
Compressed Daily Volume
10.00GB/day
Monthly Storage Growth (incl. replicas)
600.0GB
Step by step
Raw total volume over retention
50 × 30
= 1500.0GB
Compressed daily volume
50 / 5
= 10.00GB/day
Total storage: daily × retention × replicas / compression
50 × 30 × 2 / 5
= 600.0GB
How it works
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)
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.
You might also need
- OpenTelemetry Data Volume CalculatorCommonly used together
- SIEM Log Retention CalculatorCommonly used together
- Prometheus Storage CalculatorCommonly used together
- Metrics Cardinality CalculatorCommonly used together
- Log Compression CalculatorAlso in Logging & Observability
- Log Ingestion CalculatorAlso in Logging & Observability