Wazuh Data Retention Guide

Effective Wazuh Data Retention is more than simply deciding how long to keep security logs. It is a critical part of maintaining a healthy, scalable, and compliant security monitoring platform.

Every event collected by Wazuh, whether it’s an authentication failure, malware detection, file integrity change, or vulnerability scan result, consumes storage and system resources.

Without a well-defined retention strategy, organizations can quickly accumulate terabytes of data that increase storage costs, slow searches, and impact overall platform performance.

Data retention in Wazuh refers to the policies and processes that determine how long security data is stored before it is archived or deleted.

These policies balance operational needs, legal requirements, forensic investigations, and infrastructure costs.

Keeping data indefinitely may seem beneficial, but excessive retention often leads to oversized indexes, slower queries, increased backup times, and unnecessary storage expenses.

Wazuh stores security data across several components. The Wazuh Manager generates alerts and archives raw events, while the Wazuh Indexer stores indexed security events that power dashboards, searches, visualizations, and threat hunting activities.

Understanding how these components interact is essential when creating an effective retention strategy.

The Wazuh Indexer plays the central role in retention management because indexed data typically consumes the largest amount of disk space.

Proper retention planning also complements other Wazuh optimization strategies, including storage management, shard allocation, index lifecycle management, and storage migrations.

Industry guidance also emphasizes aligning retention periods with business risk rather than simply storing data indefinitely.

The NIST Cybersecurity Framework recommends maintaining logging practices that support detection, response, and recovery activities throughout the incident lifecycle.

Why Data Retention Is Important

An effective retention policy affects nearly every aspect of a Wazuh deployment, from compliance to system performance.

Retaining too little information can hinder investigations, while keeping everything forever creates operational and financial challenges.

Meet Compliance and Regulatory Requirements

Many regulations require organizations to retain security logs for defined periods.

Depending on the industry, logs may need to be preserved for several months or even multiple years.

Examples include:

• PCI DSS requirements for security event logging
• HIPAA audit log retention
• SOX financial audit records
• GDPR accountability and security monitoring requirements

Retention policies should be designed to satisfy regulatory obligations while ensuring that stored data remains protected against unauthorized modification or deletion.

The PCI Security Standards Council recommends retaining audit log history for at least one year, with recent logs immediately available for analysis.

Support Forensic Investigations

Security incidents are often discovered weeks or months after the initial compromise.

Historical logs allow investigators to reconstruct attack timelines, identify affected systems, determine attacker persistence, and measure the overall impact.

Without sufficient historical data, investigators may lose visibility into:

• Initial compromise vectors
• Privilege escalation events
• Lateral movement
• Data exfiltration activities
• Malware execution timelines

Longer retention periods improve the chances of uncovering sophisticated attacks that remain dormant before detection.

This is particularly valuable when using Wazuh alongside malware detection, custom rules, and threat intelligence integrations.

Optimize Storage Utilization

Security telemetry grows rapidly.

Large environments can generate millions of events each day from:

• Endpoint agents
• Authentication logs
• Firewall devices
• Cloud services
• Kubernetes clusters
• Web servers
• Network appliances

Without automated retention policies, storage consumption increases continuously until administrators manually intervene.

A structured retention strategy helps by:

• Removing obsolete indexes automatically
• Archiving historical data
• Reducing unused disk consumption
• Keeping active storage focused on recent events

Organizations often implement tiered storage where recent indexes remain on high-performance SSDs while older indexes move to lower-cost storage.

Maintain Wazuh Indexer Performance

The Wazuh Indexer performs best when indexes remain appropriately sized and storage utilization stays within recommended limits.

Oversized clusters containing years of unnecessary data can experience:

• Slower dashboard loading
• Increased search latency
• Longer snapshot durations
• Higher JVM memory usage
• Increased shard management overhead
• Slower cluster recovery

Implementing retention policies prevents excessive index growth while allowing the Indexer to efficiently manage active security data.

This works particularly well alongside index lifecycle management and shard optimization strategies.

Reduce Infrastructure Costs

Storage represents one of the largest ongoing costs for enterprise SIEM deployments.

Retaining only valuable security data helps reduce expenses by minimizing:

• Disk capacity requirements
• Cloud storage usage
• Backup storage
• Snapshot repositories
• Replication overhead
• Hardware upgrades

Many organizations separate retention into multiple phases:

This lifecycle-based approach provides an effective balance between operational efficiency and long-term compliance.

How Wazuh Stores Data

Understanding how Wazuh organizes security information makes it much easier to build an effective retention strategy.

Different types of security data are stored separately, allowing administrators to apply customized lifecycle policies based on operational importance.

Wazuh Alerts Indexes

The majority of searchable security information resides inside alert indexes stored by the Wazuh Indexer.

These indexes contain:

• Security alerts
• Authentication events
• Detection rule matches
• Malware detections
• Compliance findings
• Threat intelligence matches
• Agent-generated events

When users search within the Wazuh Dashboard, queries are executed against these indexed alert documents.

Because alerts typically consume the largest portion of storage, they are usually the primary focus of retention policies.

Archived Event Logs

In addition to indexed alerts, Wazuh can archive raw events before they are processed.

Archived logs provide:

• Original unmodified log data
• Long-term forensic evidence
• Backup copies of security events
• Validation during investigations

Unlike indexed alerts, archived logs are generally stored as compressed files on disk rather than searchable indexes.

Organizations with strict compliance requirements often retain archived logs much longer than searchable indexes.

File Integrity Monitoring (FIM) Data

File Integrity Monitoring continuously records changes made to monitored files and directories.

Stored information includes:

• File creation
• Modification
• Deletion
• Ownership changes
• Permission changes
• Cryptographic hash changes

Over time, environments monitoring thousands of files can generate significant amounts of FIM data.

Retention policies should balance historical visibility with storage consumption.

Vulnerability Detection Data

Wazuh Vulnerability Detection stores information about software packages, CVEs, severity scores, remediation status, and affected endpoints.

As vulnerability feeds are updated regularly, historical findings accumulate over time.

Organizations commonly retain vulnerability history to:

• Track remediation progress
• Demonstrate compliance
• Measure security improvements
• Support audits

Related Guide: Wazuh Vulnerability Detection Not Working? Here’s How to Fix It

Security Configuration Assessment (SCA) Results

Security Configuration Assessment (SCA) scans generate compliance results for operating systems and applications.

Stored information includes:

• Passed checks
• Failed checks
• Compliance scores
• Benchmark results
• Historical scan data

Retaining previous assessment results allows administrators to measure compliance improvements and identify recurring configuration drift.

Related Guide: Fixing Wazuh SCA Scan Failures: Adding Shell Wrappers to Command Rules

Inventory Data

Wazuh also maintains inventory information collected from managed endpoints.

Inventory data may include:

• Installed software
• Hardware information
• Operating system details
• Network interfaces
• Running processes
• Installed packages

Although inventory changes less frequently than security events, historical records can assist during incident investigations and asset management.

Index Naming Conventions

The Wazuh Indexer organizes searchable data into indexes that follow predictable naming patterns.

These naming conventions simplify lifecycle management, retention automation, snapshots, and maintenance tasks.

Common examples include:

• wazuh-alerts-*
• wazuh-archives-*
• wazuh-monitoring-*

Administrators can apply retention policies to entire groups of indexes using wildcard patterns, making it possible to automatically archive or delete older data without affecting current security operations.

For large deployments, maintaining consistent index naming conventions also simplifies storage migrations, cross-cluster searches, and disaster recovery planning.

According to OpenSearch documentation, index lifecycle management policies are designed to automate index transitions, retention, and deletion, making consistent index naming an important operational best practice.

Understanding Wazuh Index State Management (ISM)

One of the most effective ways to manage Wazuh Data Retention is by using Index State Management (ISM).

Rather than manually deleting old indexes or constantly monitoring disk usage, ISM automates the entire lifecycle of indexed data.

Administrators can define policies that determine when indexes should roll over, transition between storage tiers, or be deleted, ensuring the Wazuh Indexer remains efficient while meeting organizational retention requirements.

Wazuh leverages the OpenSearch Index Management plugin, allowing retention policies to execute automatically based on configurable conditions such as index age, size, or document count.

What ISM Is

Index State Management (ISM) is OpenSearch’s lifecycle management framework that automates how indexes are handled throughout their lifespan.

Instead of manually managing indexes, administrators create policies that specify actions to perform when defined conditions are met.

Typical automated actions include:

• Rolling over indexes
• Transitioning indexes to different lifecycle states
• Changing replica counts
• Reducing index priority
• Force merging segments
• Taking snapshots (when integrated with snapshot repositories)
• Deleting expired indexes

Once assigned, the policy continuously evaluates indexes and performs actions without administrator intervention.

Related Guide: How to Configure Wazuh Index State Management (ISM)

How Retention Policies Work

Retention policies define when an index should change states and what actions should occur at each stage.

For example, an organization may implement a policy such as:

Policies can trigger transitions based on:

• Index age
• Index size
• Document count
• Custom conditions

This eliminates the need for manual cleanup and helps maintain consistent storage usage across the cluster.

Index Lifecycle Stages

Although organizations define lifecycle stages differently, most Wazuh environments use a progression similar to the following:

Hot Stage

Recent security events remain on high-performance storage where searches are frequent.

Ideal for:

• Active investigations
• Dashboards
• Threat hunting
• Alerting

Warm Stage

Older indexes remain searchable but move to lower-cost storage.

Warm indexes typically experience:

• Less frequent queries
• Lower indexing activity
• Reduced hardware requirements

Cold or Archive Stage

Some organizations archive older security data before deletion.

Archived data may be stored in:

• Snapshot repositories
• Object storage
• Network-attached storage
• Long-term backup systems

Although archived data is not immediately searchable, it remains available for audits or investigations.

Delete Stage

When the retention period expires, ISM automatically removes the index.

Automatic deletion helps prevent:

• Disk exhaustion
• Oversized clusters
• Manual maintenance
• Performance degradation

Deleting obsolete indexes is often significantly more efficient than attempting to shrink or continuously optimize them.

Automatic Index Deletion

Automatic deletion is one of the most valuable ISM features.

Without automated cleanup, administrators often experience:

• Full disks
• Yellow or red cluster health
• Failed shard allocation
• Slow dashboard queries
• Indexing failures

Instead of relying on manual scripts, ISM safely removes expired indexes according to the configured policy.

Before enabling automatic deletion, organizations should ensure that:

• Required backups exist
• Compliance retention periods have been met
• Archived copies are available if needed

Rollover and Transition Concepts

Rather than allowing a single index to grow indefinitely, Wazuh environments commonly use index rollover.

A rollover creates a new active index when predefined thresholds are reached, such as:

• Maximum age
• Maximum size
• Maximum document count

For example:

wazuh-alerts-000001
↓
Rollover
↓
wazuh-alerts-000002
↓
Rollover
↓
wazuh-alerts-000003

Each older index then follows its own lifecycle policy independently.

This approach provides several advantages:

• Smaller indexes
• Faster searches
• Faster recovery
• More balanced shard allocation
• Easier retention management

Related Guide: How to Design a Wazuh OpenSearch Shard Allocation Strategy

Benefits of Automated Retention

Implementing automated retention through ISM provides significant operational advantages.

Key benefits include:

• Eliminates manual index cleanup
• Prevents storage from growing uncontrollably
• Improves Indexer performance
• Supports compliance retention requirements
• Reduces operational overhead
• Standardizes retention across environments
• Minimizes the risk of accidental data deletion
• Keeps storage costs predictable

For large enterprise deployments managing billions of security events, automated lifecycle management becomes an essential component of maintaining a healthy and scalable Wazuh infrastructure.

Planning a Wazuh Data Retention Strategy

Before creating retention policies, organizations should evaluate both business and technical requirements.

An effective strategy balances regulatory obligations, investigative needs, storage capacity, and infrastructure costs while ensuring the Wazuh Indexer continues operating efficiently as log volumes grow.

Identify Compliance Requirements

Compliance regulations often dictate the minimum amount of time security logs must be retained.

Questions to consider include:

• Which regulations apply?
• How long must logs remain accessible?
• Are archived logs acceptable?
• Must data remain immutable?
• Are encrypted archives required?

Common retention periods include:

*Always verify the latest regulatory requirements applicable to your industry.

Organizations should always design retention policies around the strictest applicable requirement.

Estimate Daily Log Ingestion

Retention planning begins with understanding how much data enters the platform each day.

Sources include:

• Windows Event Logs
• Linux logs
• Firewalls
• IDS/IPS systems
• Cloud services
• Kubernetes
• Network devices
• Applications

For example:

Actual values depend on logging verbosity, integrations, and detection rules.

Monitoring daily ingestion for several weeks provides a more accurate baseline than relying on estimates alone.

Calculate Storage Requirements

Once average daily ingestion is known, estimating storage becomes straightforward.

A simplified calculation is:

Daily ingestion × Retention days = Required raw storage

For example:

150 GB/day × 180 days = 27 TB

Remember to account for:

• Replicas
• Snapshots
• Index overhead
• Future growth
• Temporary rollover indexes

Planning for additional capacity helps avoid emergency storage expansions later.

Related Guide: How to Manage Wazuh Storage

Define Hot and Warm Retention Periods

Not all data requires high-performance storage throughout its lifecycle.

A common strategy is:

Recent security events remain immediately searchable, while older data moves to less expensive storage.

This tiered approach helps maintain fast search performance while reducing infrastructure costs.

Determine Archive Requirements

Many organizations cannot simply delete security data once it ages out of active indexes.

Instead, they archive information for:

• Compliance audits
• Legal investigations
• Incident response
• Historical reporting
• Business continuity

Archives should include:

• Snapshot verification
• Integrity validation
• Encryption
• Secure access controls
• Regular restoration testing

Simply creating backups is not enough, administrators should periodically confirm that archived data can be restored successfully.

Balance Performance and Storage Costs

Keeping every security event in high-performance storage is rarely cost-effective.

Instead, organizations should optimize based on:

• Search frequency
• Investigation needs
• Compliance requirements
• Storage pricing
• Cluster performance

Questions to ask include:

• How often are six-month-old logs searched?
• Is archived storage sufficient after 90 days?
• Can cold data remain offline until needed?
• How quickly must historical data be restored?

Finding the right balance prevents overspending while maintaining operational effectiveness.

How to Configure Wazuh Data Retention

After planning the retention strategy, the next step is implementing it using OpenSearch Index State Management.

The following workflow demonstrates the typical configuration process.

Always test new policies in a non-production environment before applying them to production indexes.

Verify Existing Index Policies

Begin by reviewing the policies already configured within the Wazuh Indexer.

This helps identify:

• Existing lifecycle policies
• Default retention behavior
• Assigned templates
• Potential policy conflicts

You can review current policies through:

• OpenSearch Dashboards
• Wazuh Dashboard Dev Tools
• OpenSearch REST APIs

Document existing policies before making changes so they can be restored if necessary.

Create a Custom ISM Policy

Next, create a policy that reflects your organization’s retention requirements.

A typical policy includes:

• Default state
• Rollover conditions
• Transition rules
• Delete actions

Example workflow:

1. Create the ISM policy.
2. Define lifecycle states.
3. Configure transition conditions.
4. Add delete actions for expired indexes.
5. Save and validate the policy.

The policy can then be reused across multiple index templates.

Related Guide: How to Configure Wazuh Index State Management (ISM)

Configure Index Templates

Index templates automatically assign lifecycle policies to newly created indexes.

A template generally defines:

• Index patterns
• Lifecycle policy
• Shard configuration
• Replica count
• Index settings
• Mappings

Using templates ensures every new index receives the correct retention policy without requiring manual intervention.

Apply the Policy to Existing Indexes

Existing indexes created before the new policy must be updated manually.

Administrators should:

• Identify target indexes
• Verify backups
• Apply the policy
• Confirm successful assignment

Applying policies gradually allows administrators to monitor cluster behavior and reduce operational risk.

Verify Policy Assignment

After applying the policy, verify that indexes are correctly associated with it.

Confirm that:

• The expected policy is attached.
• The current lifecycle state is correct.
• Transition conditions are recognized.
• No policy execution errors are reported.

Early verification helps prevent indexes from remaining unmanaged.

Monitor Policy Execution

Retention management is not a one-time task.

Policies should be monitored regularly to ensure they continue operating as expected.

Monitor items such as:

• Lifecycle state transitions
• Successful rollovers
• Automatic deletions
• Cluster health
• Disk utilization
• Index growth trends
• ISM execution errors

Routine monitoring helps identify issues before they impact storage capacity or search performance.

Managing Data with Index Rollovers

Index rollovers are a fundamental part of an effective Wazuh Data Retention strategy.

Instead of allowing a single index to grow indefinitely, rollovers create a new write index once predefined conditions are met.

This keeps indexes at manageable sizes, improves search performance, and simplifies lifecycle management through Index State Management (ISM).

Without rollovers, large indexes can become difficult to search, require longer recovery times after failures, and place unnecessary strain on the Wazuh Indexer.

When Indexes Should Roll Over

Indexes should roll over before they become excessively large or contain too many documents.

Common rollover triggers include:

• Maximum index size
• Maximum index age
• Maximum document count
• Combined size and age thresholds

The ideal rollover schedule depends on your environment’s daily log volume.

A high-ingestion environment may require multiple rollovers per day, while smaller deployments may only need weekly or monthly rollovers.

When determining rollover intervals, consider:

• Daily log ingestion
• Average search workload
• Available storage
• Shard size recommendations
• Recovery time objectives (RTOs)

Monitoring index growth for several weeks before configuring rollover policies provides more accurate thresholds.

Size-Based Rollovers

Size-based rollovers create a new index after the current index reaches a specified storage limit.

For example:

• 20 GB
• 30 GB
• 50 GB
• 75 GB

The exact threshold depends on:

• Hardware specifications
• Number of shards
• Query frequency
• Cluster size

Using size-based rollovers helps maintain relatively consistent shard sizes, which contributes to predictable cluster performance.

Oversized indexes often lead to:

• Slower searches
• Increased JVM memory usage
• Longer shard relocation
• Extended recovery times after node failures

For many production environments, maintaining shard sizes within OpenSearch best-practice recommendations helps maximize cluster stability.

Age-Based Rollovers

Age-based rollovers create new indexes after a specified period regardless of their size.

Common schedules include:

Age-based rollovers offer predictable index naming and simplify retention calculations because each index represents a fixed period.

For example:

wazuh-alerts-2026.07.01
wazuh-alerts-2026.07.02
wazuh-alerts-2026.07.03

This approach also makes troubleshooting, backups, and snapshot management easier.

Performance Benefits

Regular rollovers significantly improve the overall health of the Wazuh Indexer.

Benefits include:

• Faster search execution
• Smaller shard sizes
• Reduced recovery times
• Lower JVM memory consumption
• Improved cache efficiency
• Faster snapshot operations
• More balanced cluster resource utilization

Smaller indexes are also easier to relocate during node maintenance or cluster rebalancing.

Combined with shard allocation strategies, rollovers help maintain consistent performance as log volumes increase.

Preventing Oversized Indexes

One of the primary goals of rollovers is preventing indexes from becoming too large.

Oversized indexes can contribute to:

• Slow dashboard loading
• Increased query latency
• Failed shard allocation
• High disk watermarks
• Longer backup windows
• Difficult cluster recovery

Administrators should regularly review:

• Average shard size
• Index growth rate
• Disk utilization
• Search latency
• Cluster health status

If indexes consistently exceed planned sizes, consider:

• Reducing rollover thresholds
• Increasing rollover frequency
• Optimizing noisy log sources
• Expanding cluster capacity
• Reviewing retention periods

Proactive monitoring helps prevent storage-related issues before they affect production workloads.

Using Snapshots for Long-Term Retention

While retention policies eventually delete older indexes, many organizations still need to preserve historical security data for audits, legal requirements, or forensic investigations.

Snapshots provide an efficient way to archive indexes before they are removed from active storage.

Unlike standard file backups, snapshots capture the state of OpenSearch indexes, allowing them to be restored when needed.

Why Snapshots Are Useful

Snapshots provide several advantages for long-term retention.

They allow organizations to:

• Preserve historical security events
• Reduce storage costs on production clusters
• Recover deleted indexes
• Meet regulatory retention requirements
• Support disaster recovery planning
• Restore data for forensic investigations

Instead of keeping years of data online, organizations can maintain only recent indexes in the Wazuh Indexer while archiving older ones as snapshots.

Snapshot Repositories

Before snapshots can be created, a snapshot repository must be configured.

Common repository types include:

• Shared file systems (NFS)
• Amazon S3
• Microsoft Azure Blob Storage
• Google Cloud Storage
• Other S3-compatible object storage

The repository should provide:

• High durability
• Encryption
• Access controls
• Adequate capacity
• Geographic redundancy when appropriate

Administrators should also monitor repository health to ensure snapshots complete successfully.

Scheduling Snapshots

Snapshots should be automated rather than created manually.

Scheduling depends on:

• Daily log volume
• Compliance requirements
• Recovery objectives
• Available storage

Typical schedules include:

Automated scheduling ensures historical data is consistently protected without relying on manual processes.

Restoring Archived Indexes

When historical data is needed, administrators can restore selected indexes from a snapshot repository.

Common restoration scenarios include:

• Security incident investigations
• Compliance audits
• Legal discovery
• Historical reporting
• Recovery from accidental deletion

Rather than restoring every archived index, administrators can often recover only the specific indexes required, minimizing downtime and resource consumption.

After restoration, indexes become searchable again through the Wazuh Dashboard.

Best Practices for Backup Retention

A snapshot strategy should complement, not replace, your retention policy.

Recommended practices include:

• Automate snapshot creation.
• Verify snapshot completion regularly.
• Test restoration procedures periodically.
• Encrypt snapshot repositories.
• Restrict repository access using least privilege.
• Monitor repository capacity.
• Remove obsolete snapshots according to policy.
• Maintain multiple recovery points for critical environments.

Organizations should periodically perform restoration tests to confirm backups remain usable. A backup that has never been tested may not be reliable when needed.

Related Guide: How to Backup Wazuh Manager Configuration

Adjusting Retention for Different Types of Data

Not all Wazuh data has the same operational value or storage requirements.

Applying a single retention period across every data type often results in unnecessary storage costs or insufficient historical visibility.

A better approach is to classify data based on its purpose and assign retention policies accordingly.

High-Volume Alert Indexes

Alert indexes usually consume the largest amount of storage within a Wazuh deployment.

These indexes contain:

• Detection rule matches
• Authentication events
• Malware alerts
• Network activity
• Threat intelligence matches

Because they grow rapidly, many organizations retain searchable alert indexes for shorter periods before archiving or deleting them.

Typical considerations include:

• Investigation frequency
• Storage availability
• Compliance requirements
• SOC operational needs

Using shorter hot-storage retention periods helps maintain fast searches while controlling storage growth.

Audit Logs

Audit logs record administrative and security-related activities performed within systems and applications.

Examples include:

• User logins
• Configuration changes
• Administrative actions
• Privilege modifications
• Policy updates

Since audit logs are frequently required during investigations, organizations often retain them longer than standard operational alerts.

Retention periods should align with internal governance and regulatory requirements.

Compliance Logs

Compliance-related logs often have the longest retention requirements.

Examples include logs supporting:

• PCI DSS
• HIPAA
• SOX
• ISO 27001
• Internal governance programs

Although these logs may be accessed infrequently, they should remain protected against unauthorized modification and be readily available during audits.

Using archived snapshots allows organizations to meet retention obligations without consuming expensive production storage.

Endpoint Inventory

Inventory data changes less frequently than security alerts and generally requires less storage.

Examples include:

• Installed software
• Operating system versions
• Hardware information
• Installed packages
• Network configuration

Retention periods should support:

• Asset management
• Change tracking
• Incident investigations
• Historical reporting

Organizations commonly preserve inventory history long enough to analyze trends without storing obsolete asset records indefinitely.

Vulnerability Assessment Data

Vulnerability assessment data helps organizations measure their security posture over time.

Historical vulnerability records support:

• Remediation tracking
• Compliance reporting
• Trend analysis
• Risk assessments
• Security program metrics

Rather than deleting vulnerability history immediately after remediation, many organizations retain historical findings to demonstrate continuous improvement during audits.

Related Guide: Wazuh Vulnerability Detection Not Working? Here’s How to Fix It

Long-Term Forensic Data

Certain security events may require significantly longer retention than routine operational logs.

Examples include:

• Incident response evidence
• Breach investigations
• Legal hold data
• Executive investigations
• Insider threat cases
• Advanced persistent threat (APT) activity

This information is often archived separately using encrypted snapshots or dedicated evidence repositories.

The NIST Computer Security Incident Handling Guide (SP 800-61 Rev. 2) recommends preserving evidence throughout the incident response lifecycle to support analysis, recovery, and potential legal proceedings.

Forensic data should follow documented chain-of-custody procedures where applicable and be protected with strong access controls to maintain its integrity and evidentiary value.

Daily ingestion × Retention period = Required storage

100 GB/day × 180 days = 18 TB