How to Reduce Wazuh Storage Consumption

Reducing storage consumption does not necessarily mean collecting less security data.

Instead, the goal is to collect the right data while eliminating duplicate, low-value, or unnecessary events.

An optimized Wazuh deployment stores actionable security information without overwhelming the indexer or consuming excessive disk space.

The following techniques can significantly reduce storage usage while maintaining strong detection coverage.

Exclude Noisy Log Sources

Some systems generate enormous volumes of logs that provide little security value.

Common examples include:

• Debug logs
• Temporary application logs
• Development environments
• Health check requests
• Routine status messages
• Verbose service logs
• Software update notifications

Rather than indexing everything, review log sources regularly and exclude data that is not useful for security monitoring or compliance.

Organizations should periodically audit newly onboarded systems because default logging configurations often enable excessive verbosity.

Filter Unnecessary Events

Not every event needs to be indexed.

Filtering events before they reach the Wazuh Indexer is one of the most effective ways to reduce storage requirements.

Examples of events that may be filtered include:

• Successful routine logins
• Informational system messages
• Expected scheduled task executions
• Routine application startup events
• Known maintenance activity
• Repetitive service status updates

Filtering should always be performed carefully to avoid removing data needed for incident response or compliance investigations.

The Wazuh documentation recommends tailoring data collection to your organization’s security objectives rather than collecting every available event.

Optimize Decoder and Rule Configurations

Poorly designed decoders and detection rules can unintentionally increase storage consumption.

For example:

• Parsing unnecessary fields
• Creating multiple alerts for a single event
• Matching overly broad patterns
• Using duplicate custom rules

Regularly review custom decoders and rules to ensure they produce only meaningful alerts.

See How to Create Custom Detection Rules in Wazuh (With Examples), How to Test Wazuh Rules, and How to Safely Overwrite Local Rule IDs Without Wazuh Conflicts.

Reduce Duplicate Alerts

Duplicate alerts waste storage and make investigations more difficult.

Common causes include:

• Multiple log forwarders ingesting identical logs
• Duplicate syslog forwarding
• Overlapping Filebeat configurations
• Multiple agents monitoring the same resource
• Duplicate custom detection rules

Review your ingestion pipeline regularly to ensure every event is indexed only once.

If duplicate alerts are already occurring, investigate your log forwarding architecture before increasing storage capacity.

Adjust Alert Levels

Not every event deserves the same level of attention.

Wazuh assigns severity levels to alerts based on matching rules.

Administrators can reduce indexed alert volume by:

• Suppressing low-value informational alerts
• Increasing thresholds for repetitive events
• Using rule frequency and timeframe options
• Prioritizing higher-risk detections

Reducing unnecessary low-severity alerts improves both storage efficiency and analyst productivity.

See How to Reduce False Positives in Wazuh.

Disable Unused Modules

Every enabled Wazuh module generates additional data.

Examples include:

• File Integrity Monitoring (FIM)
• Vulnerability Detection
• Security Configuration Assessment (SCA)
• Cloud integrations
• Threat intelligence integrations
• Docker monitoring
• Kubernetes monitoring

If a module is not actively supporting security operations, consider disabling it until it is required.

Reducing unnecessary telemetry lowers both storage consumption and system overhead.

Tune Log Collection Intervals

Some modules perform periodic scans rather than continuous monitoring.

Examples include:

• Vulnerability Detection
• SCA scans
• Inventory collection
• Scheduled log collection tasks

Reducing scan frequency where operationally acceptable can significantly reduce data growth.

For example:

Intervals should always align with organizational security requirements and compliance obligations.

Monitoring Wazuh Storage Usage

Storage optimization is only effective when administrators continuously monitor disk utilization and index growth.

Regular monitoring allows teams to identify abnormal growth before storage shortages impact indexing or search performance.

Wazuh and OpenSearch provide multiple tools for tracking storage health.

Using the Wazuh Dashboard

The Wazuh Dashboard provides visibility into cluster health and indexed security data.

Administrators should routinely monitor:

• Cluster status
• Node health
• Recent index activity
• Alert volumes
• Search performance
• Data ingestion trends

Although the dashboard does not replace infrastructure monitoring, it offers an excellent operational overview for security teams.

Monitoring OpenSearch Disk Usage

The OpenSearch cluster should be monitored continuously for available disk capacity.

Key metrics include:

• Total disk capacity
• Used storage
• Available storage
• Percentage utilization
• Disk usage by node

Rapid increases often indicate:

• Unexpected event spikes
• Misconfigured agents
• Duplicate log ingestion
• Failed retention policies
• Index rollover failures

The OpenSearch Project recommends monitoring cluster storage as part of routine operational health checks.

Viewing Index Sizes

Individual indexes should be reviewed regularly.

Useful metrics include:

• Index size
• Document count
• Primary storage
• Replica storage
• Growth rate

Comparing index sizes over time helps identify:

• Noisy data sources
• Modules generating excessive events
• Retention policy failures
• Unexpected ingestion increases

Large indexes are often easier to manage when rollover policies are adjusted before they become excessively large.

Monitoring Shard Allocation

Healthy shard allocation is essential for both storage efficiency and cluster performance.

Administrators should monitor:

• Number of primary shards
• Replica placement
• Unassigned shards
• Shard balance across nodes
• Oversized shards

Poor shard allocation can lead to:

• Uneven disk utilization
• Slower searches
• Longer recovery times
• Increased infrastructure costs

For more information, see How to Design a Wazuh OpenSearch Shard Allocation Strategy  and How to Build a Wazuh Indexer Cluster.

Checking Disk Watermarks

OpenSearch protects cluster stability through configurable disk watermarks.

These thresholds determine when the cluster should begin restricting shard allocation to prevent disks from becoming full.

The three primary thresholds are:

Ignoring watermark warnings can eventually stop indexing operations entirely.

The OpenSearch documentation strongly recommends addressing storage pressure before flood-stage protection is triggered.

Creating Storage Alerts

Proactive alerting enables administrators to respond before storage problems become service outages.

Useful alerts include:

• Disk utilization above 75%
• Rapid daily storage growth
• Failed snapshots
• Index rollover failures
• High shard counts
• Unassigned shards
• Flood-stage watermark reached
• Cluster status changes

Integrating these alerts with email, Slack, PagerDuty, or other notification platforms ensures storage issues are addressed promptly.

For integration guidance, see Wazuh Email Alerts Not Working? Complete Fix Guide and Resolving PagerDuty Integration Failures and Routing Key Errors in Wazuh.

Managing Indexes for Better Storage Efficiency

Indexes are the largest consumers of storage in nearly every Wazuh deployment.

Proper index management improves search performance, reduces infrastructure costs, and ensures that storage resources are used efficiently throughout the data lifecycle.

An effective strategy combines planning, automation, and periodic maintenance.

Index Lifecycle Planning

Every index should follow a defined lifecycle from creation to deletion.

A typical lifecycle includes:

1. Index creation
2. Active indexing
3. Read-only state
4. Snapshot creation
5. Archive or warm storage
6. Automatic deletion

Planning these stages in advance prevents uncontrolled index growth and simplifies long-term storage management.

Index State Management (ISM) is the preferred mechanism for automating this lifecycle.

See How to Configure Wazuh Index State Management (ISM).

Index Rollover Strategies

Rather than storing months of data in a single index, configure rollover policies based on predefined thresholds.

Common rollover triggers include:

• Maximum index size
• Maximum document count
• Maximum index age

Benefits include:

• Faster searches
• Quicker shard recovery
• Easier snapshot management
• More balanced shard allocation

The OpenSearch Project recommends avoiding oversized shards because they reduce cluster flexibility and increase recovery times.

Force Merge Older Indexes

Once an index becomes read-only, a force merge operation can reduce the number of index segments.

Benefits include:

• Lower storage overhead
• Faster searches
• Reduced segment fragmentation
• Improved cache efficiency

Because force merge is resource-intensive, it should be performed only on indexes that are no longer receiving writes.

It is commonly incorporated into automated lifecycle policies after index rollover.

Shrink Large Indexes

Indexes created with many primary shards may become inefficient after write activity stops.

The OpenSearch Shrink API allows administrators to consolidate multiple primary shards into fewer, larger shards.

Shrinking indexes can:

• Reduce cluster overhead
• Improve storage efficiency
• Lower shard counts
• Simplify long-term maintenance

This operation is most beneficial for historical indexes that are queried occasionally but no longer updated.

Delete Obsolete Indexes Safely

Deleting expired indexes is the final stage of an effective storage lifecycle.

Before removing indexes:

• Verify retention requirements.
• Confirm snapshots have completed successfully.
• Ensure no ongoing investigations require the data.
• Validate applicable regulatory or compliance obligations.

Automated deletion through ISM policies minimizes administrative effort while preventing unnecessary storage growth.

For organizations with compliance requirements, combining snapshots with automated deletion provides an effective balance between long-term retention and operational efficiency.

Performance Optimization Tips

Efficient storage management is closely connected to Wazuh performance.

Poorly optimized storage configurations can increase indexing latency, slow dashboard searches, delay alert processing, and reduce the overall reliability of the security monitoring platform.

Optimizing storage performance requires balancing disk capacity, indexing speed, search requirements, and cluster availability.

Choose Appropriate Shard Sizes

Shard sizing is one of the most important factors affecting OpenSearch performance.

Oversized shards can cause:

• Slow searches
• Longer recovery times
• Increased memory consumption
• Difficult cluster maintenance

Excessively small shards can also create problems by increasing:

• Cluster metadata overhead
• File handles
• JVM memory usage
• Shard management complexity

A practical approach is to design indexes so shards remain within a manageable size range based on workload requirements.

Factors affecting shard size include:

• Daily ingestion volume
• Retention period
• Query frequency
• Number of nodes
• Available storage capacity

Administrators should regularly review shard sizes and adjust rollover policies as data volumes change.

For more guidance, see How to Design a Wazuh OpenSearch Shard Allocation Strategy.

Balance Storage Across Nodes

Uneven storage distribution can reduce cluster performance even when total capacity appears sufficient.

Common causes of imbalance include:

• Unequal disk sizes between nodes
• Incorrect shard allocation settings
• Recently added nodes
• Failed shard relocation
• Heavy ingestion on specific indexes

A balanced cluster provides:

• More predictable performance
• Faster recovery
• Better resource utilization
• Reduced risk of individual node failures

Administrators should regularly monitor:

• Disk usage per node
• Shard distribution
• Index allocation
• Node availability

Optimize JVM Heap Usage

The Wazuh Indexer relies on the Java Virtual Machine (JVM), and improper heap allocation can negatively affect storage performance.

Too little heap may cause:

• Frequent garbage collection
• Slow indexing
• Search delays
• Memory pressure

Too much heap can also reduce performance by limiting operating system filesystem caching.

General OpenSearch guidance recommends keeping JVM heap allocation balanced with available system memory rather than assigning all RAM to Java.

Administrators should monitor:

• JVM heap usage
• Garbage collection frequency
• Memory pressure
• Indexing latency

For related tuning guidance, see How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes.

Use SSD Storage for Hot Data

Storage performance directly affects indexing and search operations.

For active Wazuh data, SSD or NVMe storage provides significant advantages:

• Faster indexing
• Lower query latency
• Faster shard recovery
• Improved dashboard responsiveness

Hot data typically includes:

• Recent security alerts
• Active investigation data
• Frequently searched indexes

Lower-cost storage can be used for older archived data that does not require immediate access.

Reduce Unnecessary Replicas

Replica shards improve availability, but they also increase storage requirements and indexing workload.

For example:

• One replica doubles storage consumption.
• Two replicas triple storage consumption.

Organizations should configure replicas based on availability requirements.

Consider:

• Number of indexer nodes
• Required fault tolerance
• Search workload
• Recovery objectives

Development environments may require fewer replicas, while production environments typically require at least one replica for resilience.

Monitor Storage Latency

Storage capacity alone does not determine performance.

Slow storage can create:

• Increased indexing delays
• Longer searches
• High CPU wait times
• Dashboard responsiveness issues

Monitor metrics such as:

• Disk I/O latency
• Read/write throughput
• IOPS
• Filesystem utilization

High latency often indicates that storage hardware needs improvement or that indexing workloads exceed current capacity.

Security Best Practices

Wazuh stores sensitive security information, including authentication events, vulnerability data, endpoint activity, and incident investigation records.

Protecting this data is critical because unauthorized access could expose valuable information about an organization’s infrastructure.

Storage security should include encryption, access controls, monitoring, and secure backup practices.

Encrypt Stored Security Data

Encryption protects Wazuh data if storage media is compromised or unauthorized users gain physical access.

Recommended protections include:

• Full-disk encryption
• Encrypted storage volumes
• Encrypted snapshot repositories
• Encrypted backup storage

Encryption should be applied to:

• Wazuh Manager storage
• Wazuh Indexer volumes
• Snapshot repositories
• Archive locations

Organizations should also protect encryption keys using secure key management practices.

Restrict Access to Storage Volumes

Storage volumes containing Wazuh data should only be accessible by authorized administrators and services.

Best practices include:

• Restrict filesystem permissions
• Disable unnecessary accounts
• Separate administrative privileges
• Monitor privileged access
• Use secure authentication methods

Avoid allowing broad operating system access to directories containing:

• Alerts
• Logs
• Index data
• Snapshots
• Configuration files

Protect Snapshot Repositories

Snapshot repositories contain copies of potentially sensitive security information.

Protect repositories by:

• Encrypting stored snapshots
• Restricting repository permissions
• Limiting administrative access
• Monitoring repository activity
• Validating snapshot integrity

Cloud storage repositories should use security controls such as:

• Private buckets
• Access policies
• Encryption keys
• Network restrictions

Implement Least-Privilege Access

Only users and services that require storage access should receive permissions.

Examples:

• Security analysts should access dashboards, not raw storage directories.
• Backup systems should access snapshot repositories only.
• Administrators should receive elevated permissions only when required.

Least-privilege access reduces the risk of accidental deletion, unauthorized modification, or data exposure.

Monitor Storage-Related Audit Logs

Storage-related activities should be monitored for suspicious behavior.

Examples include:

• Unauthorized snapshot deletion
• Changes to storage permissions
• Unexpected index deletion
• Failed backup operations
• Access from unknown systems

Monitoring these events helps identify operational mistakes and potential security incidents.

Secure Backup Storage

Backups should receive the same security attention as production data.

Recommended practices include:

• Encrypt backups at rest
• Store copies in separate locations
• Limit backup administrator access
• Regularly test restoration
• Maintain multiple recovery points

A secure backup strategy protects against:

• Hardware failure
• Accidental deletion
• Malware
• Ransomware
• Infrastructure outages

Real-World Example

Scenario

A security operations team manages a Wazuh deployment monitoring approximately 25,000 endpoints across multiple geographic locations.

The environment collects Windows event logs, Linux system logs, cloud activity, vulnerability information, and File Integrity Monitoring data.

Over several months, storage utilization increases rapidly due to:

• High daily event volumes
• Long retention requirements
• Extensive FIM monitoring
• Frequent vulnerability scans
• Cloud workload expansion

Eventually, the Wazuh Indexer cluster approaches critical disk capacity.

Analysts begin experiencing slow searches, delayed dashboard loading, and increased indexing latency.

The team investigates the issue and identifies several causes:

• Indexes growing without rollover policies
• Historical data remaining searchable indefinitely
• Unnecessary log sources being collected
• Excessive FIM events from temporary directories
• Large vulnerability datasets accumulating over time

To resolve the problem, administrators implement a comprehensive storage management strategy.

They configure Index State Management (ISM) policies to automate the entire index lifecycle, including rollover, retention, and deletion.

They also:

• Enable automatic index rollover based on size and age.
• Delete expired indexes after 90 days.
• Move older indexes to warm storage.
• Create automated snapshots for long-term retention.
• Reduce unnecessary log collection.
• Exclude noisy FIM paths.
• Optimize vulnerability detection schedules.
• Adjust shard allocation for better balance.
• Monitor disk watermarks continuously.

After these changes:

• Storage growth becomes predictable.
• Search performance improves.
• Indexing delays are eliminated.
• Disk utilization remains below critical thresholds.
• Historical data remains available through snapshots.
• The environment can scale as endpoint counts increase.

This approach allows the security team to maintain strong visibility while controlling infrastructure costs and preventing unexpected storage outages.

Frequently Asked Questions (FAQ)

Question: What Is Wazuh Storage?

Wazuh storage refers to the locations and systems used to store security events, alerts, logs, indexes, configuration data, and backups.

Wazuh storage typically includes:

• Wazuh Manager files
• Wazuh Indexer OpenSearch indexes
• Dashboard objects
• Snapshot repositories
• Archived logs

Question: Where Does Wazuh Store Logs?

Wazuh stores logs in multiple locations depending on the type of data.

Common locations include:

• Wazuh Manager log directories
• Alert files
• Archive files
• OpenSearch indexes managed by the Wazuh Indexer

Most searchable security data is stored inside the Wazuh Indexer.

Question: How Much Storage Does Wazuh Need?

Storage requirements depend on:

• Number of endpoints
• Events per second
• Log size
• Enabled modules
• Retention period
• Replica configuration

Small deployments may require hundreds of gigabytes, while enterprise environments may require multiple terabytes.

Storage should always be calculated based on actual ingestion rates rather than endpoint count alone.

Question: How Do I Reduce Wazuh Storage Usage?

Common ways to reduce storage consumption include:

• Implementing Index State Management
• Deleting expired indexes
• Reducing unnecessary log collection
• Filtering noisy events
• Optimizing FIM configuration
• Reducing duplicate alerts
• Using snapshots for older data

Question: What Is the Best Retention Period for Wazuh Logs?

The ideal retention period depends on:

• Compliance requirements
• Security investigation needs
• Storage budget
• Business risk

Many organizations keep:

• 30–90 days of searchable data
• Longer-term data in snapshots or archives

Retention should balance accessibility with storage cost.

Question: Can I Automatically Delete Old Wazuh Indexes?

Yes.

Administrators can use OpenSearch Index State Management policies to automatically:

• Roll over indexes
• Archive older data
• Delete expired indexes

Automation prevents uncontrolled storage growth.

Question: Should I Use Snapshots for Backups?

Yes.

Snapshots are the recommended method for backing up Wazuh Indexer data because they preserve:

• Index data
• Mappings
• Metadata
• Cluster information

Snapshots are especially useful for long-term retention because they allow older data to be removed from active storage.

Question: How Do I Monitor Wazuh Disk Usage?

Storage usage can be monitored through:

• Wazuh Dashboard
• OpenSearch APIs
• Operating system tools
• Infrastructure monitoring platforms

Important metrics include:

• Disk utilization
• Index growth
• Shard allocation
• Cluster health
• Watermark status

Question: What Causes Wazuh Storage to Grow Quickly?

Common causes include:

• Large endpoint counts
• Excessive log collection
• Long retention periods
• Broad FIM monitoring
• Cloud and container logs
• Duplicate events
• Missing lifecycle policies

Question: Can Wazuh Use Hot-Warm Storage Architectures?

Yes.

Large Wazuh deployments can separate data into different storage tiers.

A typical architecture includes:

• Hot storage for recent searchable data
• Warm storage for older searchable indexes
• Cold storage or snapshots for long-term retention

This approach improves performance while reducing infrastructure costs.

Conclusion

Managing Wazuh storage effectively is essential for maintaining a reliable, scalable security monitoring platform.

As environments grow, uncontrolled data accumulation can quickly impact indexing performance, dashboard responsiveness, and operational stability.

The most important storage management practices include:

• Implementing Index State Management (ISM)
• Configuring automated index rollover
• Removing expired indexes
• Using snapshots for long-term retention
• Optimizing log collection
• Tuning File Integrity Monitoring
• Monitoring disk utilization continuously
• Balancing shards across indexer nodes

Storage planning should be treated as an ongoing operational process rather than a one-time deployment task.

Regular monitoring, capacity planning, and lifecycle automation allow organizations to scale Wazuh confidently without unexpected outages.

As your Wazuh environment grows, focus on improving storage efficiency before adding more capacity.

A well-optimized storage architecture improves search performance, reduces infrastructure costs, and ensures security teams can continue investigating threats effectively.

For continued optimization, explore related guides including:

• The Complete Wazuh Cluster Architecture Guide 
• How to Build a Wazuh Indexer Cluster 
• How to Configure Wazuh Index State Management (ISM)
• How to Design a Wazuh OpenSearch Shard Allocation Strategy