SIEM Log Retention Calculator
Work out how many days of logs a given storage budget actually buys, and whether it clears your compliance retention floor.
Inputs
10% for a bare inverted index, 35% when every field is indexed and accelerated.
Retention Achievable
738days
Storage Consumed per Day
162.50GB/day
Storage Needed for Policy
59.31TB
Shortfall Against Policy
0.00TB
Effective Bytes-Stored Ratio
0.313× raw
Compliance Verdict
Compliant with room to extend retention or add sources
Step by step
Values used
Raw ingest per day = 520 GB/day; Usable storage available = 120 TB; Compression ratio = Typical text logs — 8×; Search index overhead = 25 %; Replica copies (including primary) = 2 copies; Required retention (policy or regulation) = 365 days
SIEM Log Retention
Stored GB/day = raw GB/day × (1 + index overhead) ÷ compression ratio × replicas; retention days = usable TB × 1,000 ÷ stored GB/day.
Policy shortfall
Storage for policy = stored GB/day × required days ÷ 1,000; shortfall = that figure minus usable TB.
Retention Achievable
= 738 days
Storage Consumed per Day
= 162.50 GB/day
Storage Needed for Policy
= 59.31 TB
Shortfall Against Policy
= 0.00 TB
Effective Bytes-Stored Ratio
= 0.313 × raw
Compliance Verdict
= Compliant with room to extend retention or add sources
How it works
Compression and index overhead pull in opposite directions: 8× compression on a payload that carries 25% index overhead nets an effective 0.156× of raw bytes per copy, which two replicas then double. Dividing available capacity by that daily figure gives the honest retention window. PCI DSS wants a year with 90 days immediately available, and most regulators want more — discovering your 'twelve-month' SIEM only holds seven months of data during an investigation is a very expensive surprise.
Formulas
SIEM Log Retention
Stored GB/day = raw GB/day × (1 + index overhead) ÷ compression ratio × replicas; retention days = usable TB × 1,000 ÷ stored GB/day.
- index overhead
- Extra bytes for the searchable term index, 10–35%
- compression ratio
- 6–10× is typical for text logs
- replicas
- Copies kept for durability and search parallelism
Policy shortfall
Storage for policy = stored GB/day × required days ÷ 1,000; shortfall = that figure minus usable TB.
- required days
- Retention floor set by policy or regulation
- usable TB
- Capacity after filesystem and cluster reserve
Frequently Asked Questions
How is SIEM Log Retention calculated?
Stored GB/day = raw GB/day × (1 + index overhead) ÷ compression ratio × replicas; retention days = usable TB × 1,000 ÷ stored GB/day. Compression and index overhead pull in opposite directions: 8× compression on a payload that carries 25% index overhead nets an effective 0.156× of raw bytes per copy, which two replicas then double. Dividing available capacity by that daily figure gives the honest retention window.
Why does SIEM Log Retention matter?
PCI DSS wants a year with 90 days immediately available, and most regulators want more — discovering your 'twelve-month' SIEM only holds seven months of data during an investigation is a very expensive surprise.
What values do I need to enter?
This calculator takes 6 inputs: Raw ingest per day, Usable storage available, Compression ratio, Search index overhead, Replica copies (including primary), Required retention (policy or regulation). The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Can I count cold object storage towards retention?
Yes for compliance, usually not for detection. Regulators care that the data exists and is retrievable; correlation rules and hunts only see what is in hot or warm tiers, so track searchable retention and retained retention as two separate numbers.
Do replicas really double my storage?
For index-replicated platforms, yes — a replication factor of 2 stores every byte twice. Object-store-backed architectures instead rely on the store's own erasure coding, which typically costs 1.2–1.5× rather than 2×.