How to Configure Wazuh Log Retention

Wazuh generates and stores a massive amount of security data every day.

From endpoint activity and authentication logs to vulnerability scan results and threat detection alerts, this information is essential for monitoring, incident response, compliance, and forensic investigations.

As environments grow, however, retaining security logs indefinitely can quickly consume storage resources and negatively impact system performance.

This is where Wazuh log retention becomes important.

Properly configuring log retention allows organizations to determine how long security data should be stored before it is archived or deleted.

By establishing a clear retention policy, security teams can balance storage costs, compliance obligations, operational efficiency, and investigative requirements.

Reasons For Configuring Wazuh Log Retention

There are several common reasons organizations configure Wazuh log retention:

• Storage management by preventing log repositories from growing uncontrollably.
• Regulatory compliance with standards such as PCI DSS, HIPAA, GDPR, SOC 2, and ISO 27001.
• Performance optimization by reducing the size of searchable indexes and improving query speeds.
• Long-term forensic investigations by preserving historical security records for future analysis.

Within a typical deployment, Wazuh stores data across multiple locations, including alert files, archived events, internal logs, and OpenSearch or Elasticsearch indexes.

Each of these components may require different retention policies depending on business requirements and regulatory obligations.

In this guide, you’ll learn how Wazuh log retention works, what data can be retained, and how to configure retention settings to keep your environment efficient, compliant, and scalable.

Understanding Wazuh Log Retention

What Is Log Retention?

Log retention refers to the practice of storing security logs and event data for a defined period before archiving or deleting them.

A retention policy determines how long data remains available for searching, analysis, auditing, and forensic investigations.

In Wazuh, log retention applies to several types of security data, including alerts, archived events, indexed data, and internal application logs.

Organizations typically define retention periods based on operational requirements, compliance mandates, and available storage capacity.

It is important to understand the difference between log collection and log retention:

• Log collection is the process of gathering events from endpoints, servers, cloud services, and network devices.
• Log retention determines how long those collected events remain stored within the Wazuh environment.

Once events are collected, Wazuh processes them through its analysis engine, generates alerts when rules are triggered, and stores both raw and processed data for future use.

Wazuh stores security information in several locations:

• Local log files on the Wazuh Manager
• Archive files containing raw events
• Alert files containing rule-triggered events
• OpenSearch or Elasticsearch indexes used for searching and dashboard visualization

Understanding where data is stored is the first step toward building an effective retention strategy.

Expert Insight: The U.S. National Institute of Standards and Technology (NIST) recommends establishing formal log retention policies that align with organizational risk management and incident response requirements.

Organizations should retain logs long enough to support investigations while balancing storage costs and operational needs.

Types of Data Stored by Wazuh

Wazuh stores multiple categories of security information, and each may require different retention settings.

Alerts

Alerts are security events generated when Wazuh rules detect suspicious or noteworthy activity.

Examples include:

• Failed login attempts
• Malware detections
• Privilege escalation attempts
• File integrity monitoring events
• Vulnerability findings

These alerts are among the most commonly searched data within the Wazuh Dashboard because they represent actionable security events.

For a deeper understanding of how Wazuh detection logic works, see:

How to Create Custom Detection Rules in Wazuh (With Examples)

Archived Events

Archived events contain the original raw logs received from monitored systems before rule processing occurs.

These archives provide:

• Complete event history
• Evidence for forensic investigations
• Additional context not always present in generated alerts

Many organizations retain archived events longer than alerts because they may be required during post-incident investigations.

Internal Logs

Wazuh components generate their own operational logs.

Examples include:

• Manager logs
• API logs
• Cluster logs
• Vulnerability detection module logs
• File Integrity Monitoring module logs

These logs are often used for troubleshooting platform issues.

If you’re troubleshooting vulnerability detection, you may also find this guide helpful:

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

Indexed Data

Most modern Wazuh deployments use OpenSearch for indexing and searching security data.

Indexed data provides:

• Fast dashboard queries
• Visualizations
• Alert searching
• Historical analysis

However, indexed data often consumes the largest amount of storage within a Wazuh deployment.

Retention policies frequently focus on managing index lifecycle settings to control disk usage.

The Wazuh team recommends implementing index management strategies to automatically delete older indexes once they exceed defined retention periods.

Why Configure Wazuh Log Retention?

Without a defined retention strategy, storage requirements can grow rapidly as monitored endpoints, cloud services, and network devices generate increasing volumes of security data.

A well-designed retention policy helps maintain system performance while ensuring that critical security information remains available when needed.

Reduce Storage Consumption

One of the primary reasons organizations configure log retention is to control storage growth.

Security logs accumulate continuously, especially in environments with:

• Hundreds or thousands of endpoints
• Cloud infrastructure monitoring
• Kubernetes clusters
• High-volume authentication systems

Over time, unmanaged log growth can consume terabytes of storage.

By defining retention periods, organizations can:

• Automatically remove obsolete data
• Reduce storage costs
• Avoid emergency disk expansion projects
• Maintain predictable infrastructure requirements

For organizations collecting large volumes of container and cloud logs, storage planning becomes especially important.

Related reading:

How to Monitor Kubernetes Using Wazuh

Improve Search Performance

Large indexes can significantly impact query performance.

As security data accumulates, dashboards and searches may experience:

• Longer query times
• Slower visualizations
• Increased resource utilization
• Higher indexing overhead

Smaller, actively managed indexes generally provide:

• Faster searches
• Improved dashboard responsiveness
• Reduced CPU consumption
• Better cluster stability

According to OpenSearch best practices, managing index lifecycles and removing outdated indexes is one of the most effective methods for maintaining search performance in large-scale deployments.

Meet Compliance Requirements

Many security frameworks require organizations to retain logs for specific periods.

Common examples include:

PCI DSS

PCI DSS requires organizations to maintain audit trail history and retain security logs for compliance validation.

HIPAA

Healthcare organizations often retain security-related audit records to support regulatory investigations and compliance audits.

GDPR

Organizations operating within GDPR jurisdictions must balance security log retention with data minimization requirements.

SOC 2

SOC 2 audits commonly evaluate how organizations collect, protect, and retain security records.

ISO 27001

ISO 27001 encourages organizations to establish documented log management and retention procedures as part of their information security management system.

Retention policies should always be reviewed alongside legal, compliance, and business requirements to ensure appropriate retention durations.

Support Incident Response and Forensics

Historical security data is often critical during investigations.

When responding to a security incident, analysts may need access to:

• Historical authentication activity
• Endpoint telemetry
• Network events
• Malware detections
• Configuration changes

Without sufficient retention periods, investigators may lose valuable evidence needed to determine:

• When an attack started
• Which systems were affected
• How an attacker moved through the environment
• What data may have been accessed

This is why many organizations maintain multiple retention tiers, such as:

• 30–90 days of searchable indexed data
• 6–12 months of archived logs
• Multi-year cold storage for compliance requirements

The challenge is finding the right balance between retention needs and storage costs.

Excessive retention increases infrastructure expenses, while insufficient retention can limit visibility during incident response.

An effective Wazuh log retention strategy should align with your organization’s threat landscape, compliance obligations, and operational budget while ensuring critical security data remains available when it matters most.

How Wazuh Stores Logs

Before configuring retention policies, it’s important to understand where Wazuh stores different types of security data.

Retention settings often vary depending on whether data is stored as local log files, archived events, or indexed records within the Wazuh Indexer.

Wazuh Manager Storage Locations

The Wazuh Manager stores several categories of logs and security events on disk.

These files provide the foundation for alerting, investigations, and compliance reporting.

Alerts Directory

Wazuh alerts are typically stored in:

/var/ossec/logs/alerts/

This directory contains security events that have triggered Wazuh rules.

Common files include:

alerts.json
alerts.log

These files contain processed security alerts generated by the Wazuh analysis engine and are often used for troubleshooting and auditing.

If you’re creating custom detections that generate alerts, see:

How to Create Custom Detection Rules in Wazuh (With Examples)

Archives Directory

Raw events received from monitored systems are stored in:

/var/ossec/logs/archives/

Common files include:

archives.json
archives.log

Unlike alerts, archived events contain the original log data before Wazuh rule processing occurs.

Many organizations retain archive data longer than alert data because it provides:

• Full forensic evidence
• Historical event reconstruction
• Additional context during investigations
• Support for compliance audits

Since archived logs can grow rapidly in large environments, they are often a primary focus of retention planning.

Internal Log Files

Operational logs generated by Wazuh components are stored within:

/var/ossec/logs/

Examples include:

ossec.log
api.log
cluster.log

These logs are used for:

• Troubleshooting manager issues
• Diagnosing agent communication problems
• Monitoring module health
• Investigating configuration errors

For example, when troubleshooting agent communication issues, administrators frequently review:

/var/ossec/logs/ossec.log

You may also find this guide useful:

How to Install a Wazuh Agent on Windows Server

Wazuh Indexer Storage

In modern Wazuh deployments, most searchable security data resides within the Wazuh Indexer, which is built on OpenSearch.

Wazuh Indexer Overview

The Wazuh Indexer receives processed events from the Wazuh Manager and stores them as indexes.

This indexed data powers:

• Dashboard searches
• Security visualizations
• Alert queries
• Threat hunting workflows
• Compliance reporting

The Wazuh Dashboard primarily interacts with indexed data rather than directly reading log files from the manager.

For a deeper understanding of the indexer architecture, the official Wazuh documentation provides an excellent overview.

Index Lifecycle Concepts

An index lifecycle defines what happens to data as it ages.

Typical lifecycle stages include:

1. Creation
2. Active use
3. Transition to lower-cost storage
4. Deletion

Modern retention strategies often automate these stages through Index Lifecycle Management (ILM) policies.

Benefits include:

• Reduced storage consumption
• Automated cleanup
• Improved cluster performance
• Consistent retention enforcement

According to OpenSearch best practices, automated lifecycle management helps maintain cluster stability while preventing uncontrolled index growth.

Daily Index Creation

By default, Wazuh commonly creates indexes on a daily basis.

Examples:

wazuh-alerts-4.x-2026.06.14
wazuh-alerts-4.x-2026.06.15
wazuh-alerts-4.x-2026.06.16

This daily index structure makes retention management easier because older indexes can be removed without affecting recent security data.

For example:

• Keep indexes for 90 days
• Automatically delete anything older than 90 days
• Maintain predictable storage utilization

This approach is widely used in enterprise SIEM and security analytics environments because it simplifies retention enforcement.

Determining Appropriate Retention Policies

There is no universal log retention period that works for every organization.

The ideal policy depends on regulatory requirements, security objectives, storage constraints, and risk tolerance.

Before configuring retention settings, evaluate the following factors.

Factors to Consider

Compliance Requirements

Many organizations must comply with regulatory frameworks that dictate how long security logs must be retained.

Examples include:

• PCI DSS
• HIPAA
• GDPR
• SOC 2
• ISO 27001

Retention requirements can vary significantly between industries.

For example:

• Financial institutions often require extended audit log retention.
• Healthcare organizations frequently maintain records for multiple years.
• Government agencies may have even longer retention obligations.

Always verify retention requirements with legal and compliance stakeholders before implementing deletion policies.

The PCI Security Standards Council specifically requires organizations to maintain audit logs and make historical records available for review.

Available Storage Capacity

Storage availability is one of the most practical considerations when designing retention policies.

Questions to evaluate include:

• How many endpoints are generating logs?
• How much data is generated daily?
• What is the annual growth rate?
• How quickly can storage be expanded?

A simple capacity planning formula is:

Daily Log Volume × Retention Days = Required Storage

For example:

50 GB/day × 90 days = 4.5 TB

Organizations should also account for:

• Replication overhead
• Snapshot storage
• Backup retention
• Future growth

Security teams that underestimate growth often encounter unexpected storage shortages within months.

Security Monitoring Needs

Retention requirements should align with security operations objectives.

Organizations performing proactive threat hunting often benefit from longer retention periods because analysts can:

• Search historical indicators of compromise
• Investigate dormant threats
• Track attacker behavior over time
• Correlate long-term activity patterns

Many advanced threat investigations require reviewing activity that occurred months before detection.

Organizations focused heavily on detection engineering may also want to preserve historical alerts for tuning and validation purposes.

Related reading:

How to Reduce False Positives in Wazuh

Business Risk Tolerance

Retention policies ultimately represent a tradeoff between visibility and cost.

Short-term retention offers:

• Lower storage expenses
• Smaller indexes
• Faster searches

Long-term retention provides:

• Greater forensic visibility
• Better compliance coverage
• Extended threat hunting capabilities

Organizations operating in highly regulated industries often accept higher storage costs in exchange for longer retention periods.

Sample Retention Recommendations

The following recommendations provide a starting point for most environments.

These values should be adjusted based on:

• Daily log volume
• Regulatory obligations
• Security maturity
• Available budget

Many enterprises adopt a tiered approach:

• 90 days searchable in OpenSearch
• 1 year archived locally
• Multiple years stored in low-cost backup storage

This strategy balances performance, compliance, and cost efficiency.

Configuring Log Rotation for Wazuh Manager

One of the simplest ways to control local log growth is through log rotation.

Log rotation automatically archives older log files and removes outdated data according to a defined retention schedule.

Understanding Log Rotation

Purpose of Log Rotation

Without rotation, log files continue growing indefinitely.

Large log files can cause:

• Storage exhaustion
• Slower file access
• Backup inefficiencies
• Operational management challenges

Log rotation addresses these issues by:

• Creating new log files on a schedule
• Compressing older logs
• Removing expired files
• Reducing storage consumption

How Rotation Affects Retention

Log rotation is often the first layer of a broader retention strategy.

For example:

Daily rotation
30 retained copies
Compression enabled

This configuration effectively preserves approximately 30 days of historical logs while minimizing disk usage.

Rotation settings typically govern:

• Number of retained files
• Rotation frequency
• Compression behavior
• Automatic deletion timing

Reviewing Current Log Files

Before implementing rotation policies, review existing log storage.

Use:

ls -lah /var/ossec/logs/

Example output:

-rw-r----- 1 wazuh wazuh 1.2G ossec.log
-rw-r----- 1 wazuh wazuh 850M alerts.log
-rw-r----- 1 wazuh wazuh 3.8G archives.log

This helps identify rapidly growing files that may require more aggressive rotation settings.

Using Logrotate with Wazuh

Most Linux distributions include the Logrotate utility for automated log management.

Create a Logrotate Policy

Create a custom configuration file:

sudo nano /etc/logrotate.d/wazuh

Example configuration:

/var/ossec/logs/*.log {
    daily
    rotate 30
    compress
    missingok
    notifempty
}

Configuration explanation:

This configuration provides approximately one month of local log retention while significantly reducing disk consumption through compression.

Test the Configuration

Before deploying the policy, validate the configuration.

Run:

logrotate -d /etc/logrotate.conf

The debug mode performs a dry run and reports any syntax errors without modifying files.

Review the output carefully to ensure your Wazuh policy behaves as expected.

Force a Rotation

To immediately execute a rotation and verify functionality:

logrotate -f /etc/logrotate.conf

After completion, inspect the directory:

ls -lah /var/ossec/logs/

You should see:

ossec.log
ossec.log.1
ossec.log.2.gz

This confirms that rotation, compression, and retention settings are working correctly and that older log files will be automatically managed moving forward.

Configuring Archive Log Retention

Archive logs are often the largest source of storage consumption in a Wazuh deployment.

While they provide valuable forensic data, retaining raw events indefinitely can quickly exhaust available disk space.

A well-designed archive retention strategy ensures that historical data remains available when needed while preventing uncontrolled storage growth.

Understanding Archive Data

Archive files contain the original events received by the Wazuh Manager before rule processing and alert generation.

Unlike alerts, which only represent events that triggered a rule, archives provide a complete record of collected logs.

Purpose of archives.json and archives.log

The primary archive files are:

/var/ossec/logs/archives/archives.json
/var/ossec/logs/archives/archives.log

These files store:

• Raw agent events
• Syslog messages
• Cloud service logs
• Network security events
• Authentication records

Because every collected event can be stored, archive files typically grow much faster than alert logs.

Benefits of retaining archive data include:

• Complete forensic visibility
• Historical threat investigations
• Regulatory auditing
• Event reconstruction

However, the storage cost can be substantial in large environments.

Impact on Storage Consumption

Organizations frequently discover that archive logs consume significantly more space than alerts.

For example:

The exact volume depends on:

• Number of monitored endpoints
• Cloud integrations
• Network log sources
• Syslog ingestion volume
• Kubernetes workloads

If you’re collecting large volumes of cloud or container logs, archive growth can become one of the largest storage challenges in your deployment.

Related reading:

How to Monitor AWS CloudTrail Logs Using Wazuh

Enable or Verify Event Archiving

Before configuring retention, verify whether archive logging is enabled.

The configuration is located in:

/var/ossec/etc/ossec.conf

Look for the following settings:

<logall>yes</logall>
<logall_json>yes</logall_json>

Setting descriptions:

If both options are disabled, archive files may not be generated.

Keep in mind that enabling these settings can dramatically increase storage usage.

The official Wazuh documentation notes that full event archiving should be enabled only when required for compliance, auditing, or investigative purposes.

Implement Archive Cleanup Policies

Many organizations supplement log rotation with automated archive cleanup.

The goal is simple:

• Retain archive data for a defined period
• Remove expired files automatically
• Prevent disk exhaustion

Automatic Cleanup Script

The following example removes archive files older than 90 days:

#!/bin/bash

ARCHIVE_PATH="/var/ossec/logs/archives"

find $ARCHIVE_PATH -type f -mtime +90 -delete

echo "$(date): Old archive logs removed" >> /var/log/wazuh-archive-cleanup.log

This script:

• Searches archive directories
• Identifies files older than 90 days
• Deletes expired files
• Creates an audit trail for cleanup actions

Before using automated deletion in production, test the script in a non-production environment and verify compliance requirements.

Schedule Cleanup with Cron

Automating cleanup eliminates the need for manual maintenance.

Example cron job:

0 2 * * * /opt/scripts/wazuh-log-cleanup.sh

This runs every day at 2:00 AM.

Benefits include:

• Consistent retention enforcement
• Reduced administrative effort
• Lower risk of storage-related outages

Verifying Archive Removal

After cleanup executes, verify that expired files were removed successfully.

Review remaining archive files:

find /var/ossec/logs/archives -type f | wc -l

Confirm deletion activity:

cat /var/log/wazuh-archive-cleanup.log

Check available storage:

df -h

You should see increased available disk space following successful cleanup operations.

Configuring Wazuh Index Retention

For most modern deployments, indexed data stored in the Wazuh Indexer consumes more storage than local log files.

Managing index retention is therefore one of the most important aspects of Wazuh log retention.

Understanding Wazuh Indexes

The Wazuh Indexer stores processed security events as searchable indexes.

These indexes power:

• Dashboard searches
• Threat hunting
• Alert analysis
• Reporting
• Visualizations

Daily Index Creation

By default, Wazuh creates indexes on a daily basis.

Examples:

wazuh-alerts-4.x-2026.06.14
wazuh-alerts-4.x-2026.06.15
wazuh-alerts-4.x-2026.06.16

Daily indexing simplifies retention because entire indexes can be deleted once they exceed their retention period.

Storage Impact Over Time

Index storage can grow rapidly.

Example:

Without retention controls, storage growth eventually impacts:

• Query performance
• Cluster health
• Backup costs
• Hardware requirements

The OpenSearch project recommends lifecycle management policies to automate index aging and deletion.

Viewing Existing Indexes

To review current indexes:

curl -k -u admin:password https://localhost:9200/_cat/indices?v

Example output:

health status index
green  open   wazuh-alerts-4.x-2026.06.14
green  open   wazuh-alerts-4.x-2026.06.13
green  open   wazuh-alerts-4.x-2026.06.12

Review:

• Number of indexes
• Index age
• Storage consumption
• Growth trends

This information helps determine appropriate retention periods.

Creating an Index Retention Policy

A retention policy defines when indexes should be deleted automatically.

Define Retention Periods

Common retention periods include:

The correct value depends on:

• Compliance requirements
• Threat hunting objectives
• Storage availability
• Incident response needs

Configure Index State Management (ISM)

OpenSearch Index State Management (ISM) automates index lifecycle operations.

Basic policy example:

{
  "policy": {
    "description": "Delete old Wazuh indexes",
    "default_state": "hot"
  }
}

A complete production policy typically includes:

• Hot state
• Aging conditions
• Delete actions
• Automated transitions

The official Wazuh documentation provides detailed ISM examples and deployment guidance.

Applying the Policy to Wazuh Indexes

After creating the policy:

1. Open OpenSearch Dashboards.
2. Navigate to Index Management.
3. Select the target Wazuh indexes.
4. Assign the retention policy.
5. Save the configuration.

Many administrators apply policies using index patterns such as:

wazuh-alerts-*

This ensures that newly created indexes automatically inherit the policy.

Verifying Successful Application

Confirm policy assignment by reviewing:

• Index Management dashboard
• Policy status
• Index state transitions
• Scheduled deletion actions

You can also verify using the OpenSearch API.

Successful implementation ensures that expired indexes are removed automatically without manual intervention.

Configuring Long-Term Log Archival

Some organizations must retain security records for years rather than months.

In these environments, storing all historical data in the Wazuh Indexer is often impractical due to storage costs.

Long-term archival provides a cost-effective alternative.

When Long-Term Archiving Is Needed

Organizations commonly implement long-term archival for:

Compliance Requirements

Examples include:

• PCI DSS
• HIPAA
• SOX
• SOC 2
• ISO 27001

Many regulations require historical audit records to remain available long after operational use has ended.

Audit Requests

External auditors may request:

• Historical authentication records
• Security alerts
• Access logs
• Incident evidence

Archival systems ensure that these records remain accessible.

Forensic Investigations

Security incidents are sometimes discovered months after the initial compromise.

Long-term retention helps investigators:

• Reconstruct attacker activity
• Establish timelines
• Identify affected systems
• Validate remediation efforts

Archiving to External Storage

External storage solutions are commonly used to reduce local infrastructure costs.

Network Storage

Traditional options include:

NFS

Benefits:

• Simple deployment
• Linux compatibility
• Centralized storage

SMB Shares

Benefits:

• Windows compatibility
• Existing enterprise infrastructure
• Easy integration

These approaches work well for organizations with on-premises storage environments.

Cloud Storage

Cloud platforms offer highly scalable archival options.

Amazon S3

Features:

• Low-cost storage tiers
• Lifecycle policies
• Long-term durability

Azure Blob Storage

Features:

• Archive tiers
• Automated retention controls
• Enterprise integration

Google Cloud Storage

Features:

• Object lifecycle management
• Cost optimization
• Long-term archival support

Cloud providers generally offer significantly lower storage costs compared to maintaining large OpenSearch clusters.

Automating Archive Transfers

Manual archival quickly becomes difficult at scale.

Organizations typically automate:

• Scheduled exports
• Compression
• Transfer operations
• Lifecycle management

Example workflow:

1. Compress logs.
2. Transfer to cloud storage.
3. Verify integrity.
4. Delete local copies after retention requirements are met.

Compression can dramatically reduce storage requirements.

Common tools include:

• gzip
• bzip2
• xz

Retention Lifecycle Management

A mature archival strategy usually includes multiple stages:

This layered approach balances accessibility and cost.

Monitoring Storage Usage

Retention policies are only effective when storage consumption is continuously monitored.

Regular monitoring helps identify unexpected growth before it becomes a service-impacting issue.

Check Disk Usage

Use the following command to review filesystem utilization:

df -h

Example output:

Filesystem      Size  Used Avail Use%
/dev/sda1       500G  420G   80G  84%

Pay particular attention to partitions hosting:

• Wazuh Manager logs
• Archive data
• Indexer data directories

Identify Large Log Directories

To identify major storage consumers:

du -sh /var/ossec/logs/*

Example output:

20G alerts
150G archives
5G integrations

This quickly reveals which components require attention.

Monitor Index Storage Consumption

The Wazuh Dashboard provides visibility into index growth and storage utilization.

Useful metrics include:

• Index size
• Document count
• Daily ingestion rates
• Retention effectiveness

Wazuh Dashboard Methods

Administrators can review:

• Index Management
• Storage dashboards
• Cluster health
• Data node utilization

These views help identify growth trends before they become operational issues.

OpenSearch Monitoring Tools

OpenSearch also provides monitoring capabilities for:

• Disk usage
• Shard allocation
• Node health
• Index growth

Tracking these metrics helps ensure retention policies continue operating as expected.

Set Up Storage Alerts

Monitoring should include proactive alerting.

Recommended thresholds:

Alerting can be implemented through:

• Wazuh rules
• OpenSearch monitoring
• External monitoring platforms

Preventing Unexpected Outages

Storage exhaustion is one of the most common causes of operational issues in log management platforms.

A combination of:

• Log rotation
• Archive cleanup
• Index lifecycle management
• Long-term archival
• Storage monitoring

provides a comprehensive strategy for preventing unexpected outages while ensuring that critical security data remains available when needed.

Related reading:

How to Configure File Integrity Monitoring (FIM) in Wazuh

Best Practices for Wazuh Log Retention

Implementing log retention is not simply about deleting old data.

An effective retention strategy should balance compliance requirements, security visibility, operational performance, and storage costs.

The following best practices can help ensure your Wazuh environment remains scalable and manageable over time.

Define Retention Requirements Before Deployment

One of the most common mistakes organizations make is deploying Wazuh without a formal retention policy.

Before enabling large-scale log collection, determine:

• Compliance obligations
• Security monitoring requirements
• Storage limitations
• Business retention expectations
• Backup requirements

Questions to ask include:

• How long must security logs be retained?
• Which logs are required for audits?
• How much historical data is needed for investigations?
• What storage budget is available?

Establishing these requirements early prevents costly migrations and storage upgrades later.

Separate Hot and Cold Data

Not all security data needs to remain immediately searchable.

A tiered storage model is often more cost-effective:

For example:

• Keep 90 days of searchable indexes in the Wazuh Indexer.
• Move older logs to archive storage.
• Retain long-term records in cloud storage or backup repositories.

This approach reduces index storage costs while preserving historical data.

Industry analysts at Gartner have consistently recommended tiered log storage architectures for large-scale security monitoring environments because they improve cost efficiency without sacrificing visibility.

Compress Older Logs

Compression can significantly reduce storage requirements.

Common compression tools include:

gzip
bzip2
xz

Benefits include:

• Reduced disk usage
• Lower backup costs
• Faster archive transfers
• Improved storage efficiency

Many organizations achieve storage reductions of 70% or more when compressing archived log files.

Compression should be enabled wherever possible for:

• Alert logs
• Archive logs
• Exported backups
• Long-term archival data

Regularly Review Storage Consumption

Retention policies should not be treated as a one-time configuration.

Monitor:

• Daily log growth
• Index size trends
• Available disk capacity
• Archive expansion rates

As environments grow, retention settings may require adjustment.

Factors that commonly increase storage consumption include:

• New agents
• Additional cloud integrations
• Kubernetes deployments
• Increased logging verbosity
• Expanded compliance requirements

Monthly storage reviews help identify issues before they affect operations.

Test Retention Policies in Non-Production Environments

Never deploy aggressive retention settings directly into production without testing.

Potential risks include:

• Accidental deletion of required logs
• Misconfigured index lifecycle policies
• Compliance violations
• Loss of forensic evidence

A staging environment allows administrators to validate:

• Log rotation behavior
• Archive cleanup scripts
• Index deletion policies
• Backup restoration procedures

Testing helps ensure retention automation behaves as expected before affecting production data.

Document Retention and Deletion Procedures

Retention processes should be formally documented.

Documentation should include:

• Retention periods
• Storage locations
• Cleanup schedules
• Backup procedures
• Approval requirements
• Recovery procedures

Benefits include:

• Easier audits
• Faster onboarding
• Consistent operations
• Reduced administrative risk

Organizations with mature security programs often include retention procedures within broader log management policies.

Align Retention with Compliance Requirements

Retention settings should always be validated against applicable regulations.

Examples include:

• PCI DSS
• HIPAA
• GDPR
• SOC 2
• ISO 27001

The International Organization for Standardization (ISO) recommends that organizations establish documented procedures governing the retention, protection, and disposal of security records.

A retention policy that saves storage but violates compliance requirements can create significant legal and operational risks.

Troubleshooting Log Retention Issues

Even properly configured environments occasionally experience retention-related problems.

The following troubleshooting procedures can help identify and resolve the most common issues.

Disk Usage Continues to Grow

If storage utilization continues increasing despite configured retention policies, one or more cleanup mechanisms may not be functioning correctly.

Possible Causes

Archive Cleanup Not Running

Common causes include:

• Cron job failures
• Incorrect file permissions
• Missing scripts
• Syntax errors

Verify scheduled jobs:

crontab -l

Review cleanup logs:

cat /var/log/wazuh-archive-cleanup.log

Index Policies Misconfigured

A common issue is creating retention policies but never assigning them to indexes.

Check:

• Policy status
• Index assignments
• State transitions
• Deletion schedules

Unexpected Event Volume

Storage growth may simply reflect increased log ingestion.

Common causes include:

• New endpoints
• Increased syslog traffic
• Cloud integrations
• Verbose logging settings

Solutions

Verify Scheduled Tasks

Confirm that:

• Cron jobs execute successfully
• Cleanup scripts complete without errors
• Rotation schedules remain active

Check Index Lifecycle Status

Review:

• OpenSearch Index Management
• ISM policies
• Index states
• Policy execution history

Review Logging Levels

Excessive logging can dramatically increase storage consumption.

Evaluate whether:

• Debug logging is enabled
• Unnecessary data sources are being collected
• Archive logging is required

Reducing unnecessary log volume often provides immediate storage relief.

Indexes Are Not Being Deleted

One of the most common retention problems is index lifecycle policies failing to remove expired indexes.

Diagnostic Steps

Review ISM Policy Status

Verify policy status through:

• OpenSearch Dashboards
• ISM APIs
• Index Management

Look for:

• Failed transitions
• Policy errors
• Permission issues

Check Index Assignments

Ensure indexes are actually attached to the intended policy.

Review index metadata and confirm the policy is associated with the appropriate index pattern.

Resolution

Reapply Retention Policy

If assignments are missing:

1. Remove the policy.
2. Reassign it.
3. Verify successful attachment.

Many deletion issues are caused by incomplete policy assignments.

Restart Index Management Services

In rare cases, restarting services may resolve stalled policy execution.

Example:

systemctl restart wazuh-indexer

Always verify cluster health before restarting production components.

Missing Historical Logs

Organizations occasionally discover that expected historical data is unavailable.

Possible Causes

Retention Period Too Short

The most common cause is an overly aggressive retention policy.

Example:

• Investigation requires six months of data.
• Retention policy only preserves 30 days.

Manual Deletion

Administrators may accidentally remove:

• Archive files
• Indexes
• Backups

This can occur during maintenance or troubleshooting activities.

Storage Failures

Hardware issues may result in:

• Corrupted indexes
• Lost archive files
• Incomplete backups

Storage infrastructure should be monitored and regularly validated.

Resolution

Restore from Backups

If backups exist:

1. Identify the required recovery point.
2. Restore archived data.
3. Reindex logs if necessary.
4. Validate data integrity.

Regular backup testing is critical to ensure successful restoration.

Adjust Retention Settings

If historical data is routinely unavailable:

• Extend retention periods.
• Increase storage capacity.
• Implement cold storage archives.
• Review compliance requirements.

Retention policies should support both operational and investigative needs.

Frequently Asked Questions

Question: How Long Should Wazuh Logs Be Retained?

The appropriate retention period depends on compliance requirements, storage capacity, and security objectives.

A common starting point is:

• Small environments: 30 days
• SMBs: 90 days
• Enterprises: 180–365 days
• Compliance-focused organizations: 1–7 years

Organizations subject to regulatory requirements should always follow applicable legal retention mandates.

Question: Does Deleting Logs Affect Existing Alerts?

Deleting historical logs or indexes removes the associated data from searches and dashboards.

Once deleted:

• Historical searches may no longer return results.
• Dashboards may show reduced historical coverage.
• Investigations may lose valuable context.

Always ensure data is no longer required before deletion.

Question: Can Wazuh Automatically Delete Old Logs?

Yes.

Common automation methods include:

• Logrotate
• Cleanup scripts
• Cron jobs
• OpenSearch Index State Management (ISM)
• Cloud lifecycle policies

Most mature deployments rely heavily on automation to enforce retention consistently.

Question: What Is the Difference Between Alerts and Archives?

Alerts contain events that triggered Wazuh rules.

Archives contain the original raw events received by the manager.

In general:

Archives typically consume significantly more storage but provide greater forensic detail.

Question: How Much Storage Does Wazuh Require?

Storage requirements vary based on:

• Number of endpoints
• Event volume
• Retention period
• Archive settings
• Cloud integrations

A small deployment may require only a few hundred gigabytes, while large enterprise environments can consume multiple terabytes annually.

Regular capacity planning is essential for accurate sizing.

Question: Can I Store Wazuh Logs in Cloud Storage?

Yes.

Many organizations archive older logs to:

• Amazon S3
• Azure Blob Storage
• Google Cloud Storage

Cloud storage is often used for:

• Long-term retention
• Compliance requirements
• Backup repositories
• Cost optimization

A common approach is to keep recent data searchable in the Wazuh Indexer while moving older records to cloud archives.

Conclusion

Configuring Wazuh log retention is a critical part of maintaining a secure, scalable, and compliant security monitoring platform.

Without a defined retention strategy, organizations can quickly encounter storage shortages, degraded search performance, and challenges meeting regulatory requirements.

Throughout this guide, we’ve covered the three primary components of Wazuh log retention:

• Manager log retention through log rotation and cleanup policies
• Archive retention using automated deletion and long-term archival strategies
• Index retention through OpenSearch Index State Management (ISM) policies

Together, these mechanisms help ensure that security data remains available when needed while preventing unnecessary storage growth.

The most effective retention strategy balances three competing priorities:

• Compliance requirements
• Security visibility
• Storage costs

Organizations that retain too little data may struggle during incident investigations, while those that retain everything indefinitely often face significant infrastructure expenses and performance issues.

As your environment grows, retention policies should be reviewed regularly to account for:

• Additional endpoints
• Increased event volume
• New compliance obligations
• Expanded threat hunting requirements

Periodic audits of storage consumption and retention effectiveness can help ensure your Wazuh deployment remains efficient and sustainable over time.

For additional Wazuh administration and optimization guidance, you may also find these resources useful:

• How to Reduce False Positives in Wazuh
  
• How to Monitor Kubernetes Using Wazuh
  
• How to Configure File Integrity Monitoring (FIM) in Wazuh
  
• Wazuh vs OpenSearch