What Should Be Included in a Wazuh Manager Configuration Backup?

Creating a reliable backup involves much more than copying the primary configuration file.

A complete Wazuh Manager configuration backup should include every file that controls how your deployment collects logs, detects threats, communicates with agents, and integrates with external services.

The exact files may vary depending on your deployment, but the following components should almost always be included.

Main Configuration Files

The primary configuration files define how the Wazuh Manager operates.

ossec.conf

The ossec.conf file is the heart of every Wazuh Manager installation.

It contains configuration settings for:

• Agent communication
• Log collection
• File Integrity Monitoring (FIM)
• Vulnerability Detection
• Active Response
• Cluster configuration
• Email alerts
• Integrations
• Logging behavior
• Remote monitoring

If this file is lost, rebuilding your environment manually can be extremely time-consuming.

Related Guide: How to Configure ossec.conf for Log Monitoring in Wazuh

local_internal_options.conf

This file contains locally customized internal settings that override default behavior without modifying system defaults.

Administrators often use it to tune:

• Queue sizes
• Performance settings
• Module behavior
• Internal service limits
• Debug options

Because these changes are usually deployment-specific, they should always be backed up.

internal_options.conf (Only If Customized)

Most administrators should avoid editing internal_options.conf directly because updates may overwrite it.

The Wazuh documentation recommends using local_internal_options.conf whenever possible instead.

If your environment includes legitimate modifications to internal_options.conf, include it in your backup as well.

Custom Rules

Custom detection logic often represents hundreds of hours of security engineering.

These files should always be preserved.

Local Rules

Local rules allow organizations to detect events unique to their own infrastructure.

Examples include:

• Internal application logs
• Custom authentication systems
• Proprietary software
• Business-specific security events

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

Rule Groups

Many organizations organize custom rules into separate files or logical groups.

Backing up these grouped rule files makes future maintenance much easier and preserves the relationships between related detections.

Custom Correlation Rules

Correlation rules combine multiple events into a higher-confidence security alert.

Examples include:

• Multiple failed logins followed by success
• Privilege escalation after suspicious authentication
• Malware detection followed by outbound communication

These advanced detections are often difficult to recreate manually.

Custom Decoders

Decoders tell Wazuh how to interpret incoming log formats.

Without them, custom logs may stop generating alerts.

XML Decoders

Most traditional Wazuh decoders are written in XML.

They parse application logs, appliance logs, and custom event formats.

JSON Decoders

Modern cloud platforms and APIs frequently produce JSON logs.

Custom JSON decoders enable Wazuh to correctly extract fields for rule matching.

Regex Decoders

Some applications generate unstructured logs that require regular expressions for parsing.

Regex-based decoders are especially valuable for proprietary software and legacy systems.

Related Guides:

• How to Parse Flattened Nested Keys and Arrays in Wazuh JSON Logs
• How to Fix “Field Already Defined” Syntax Errors in Wazuh Decoders

Agent Information

Although agents can usually be re-enrolled, restoring existing agent information greatly simplifies recovery.

client.keys

The client.keys file contains authentication keys used by enrolled agents.

Without this file:

• Existing agents may lose trust
• Re-enrollment may be required
• Large deployments could require significant administrative effort

Protect this file carefully because it contains sensitive authentication information.

Agent Groups

Agent groups allow centralized configuration management across multiple endpoints.

These groups define which policies are applied to different classes of systems, such as:

• Linux servers
• Windows workstations
• Web servers
• Database servers
• Domain controllers

Related Guide: How to Configure Wazuh Agent Centralized Configuration

Shared Configuration

Shared agent configuration files help maintain consistent settings across hundreds or thousands of endpoints.

Backing them up prevents lengthy manual reconfiguration after recovery.

SSL/TLS Certificates

Encrypted communication within Wazuh depends on certificates and private keys.

Always include these files in your backup.

Manager Certificates

These certificates authenticate the manager during secure communications.

Private Keys

Private keys should be backed up securely and encrypted whenever possible.

Anyone obtaining these keys may be able to impersonate trusted components.

CA Certificates

Certificate Authority files validate trusted communications between managers, indexers, dashboards, and agents.

Related Guide: How to Fix Wazuh Certificate Errors

Integration Configurations

Many production deployments integrate Wazuh with external security platforms.

Losing these settings can interrupt automated workflows.

Include configurations for:

Active Response Scripts

Scripts that automatically respond to threats by blocking IPs, killing processes, or isolating systems.

Related Guide: How to Configure Wazuh Active Response

VirusTotal Integration

API keys, module settings, and configuration files should be preserved.

Related Guide: How to Integrate Wazuh with VirusTotal for Threat Intelligence

Slack Integrations

Webhook URLs, notification channels, routing rules, and alert formatting.

Related Guide: Fix Wazuh Slack Webhook Errors: Curl 52 Empty Reply

Email Notification Settings

SMTP configuration, recipient lists, authentication credentials, and notification policies.

Related Guide: Wazuh Email Alerts Not Working? Complete Fix Guide

Syslog Forwarding Configuration

If Wazuh forwards alerts to external SIEM platforms or centralized log servers, preserve all forwarding rules and destination settings.

Related Guide: How to Configure Wazuh as a Centralized Syslog Server

Authentication Files

Depending on your deployment, authentication-related files may include:

• API credentials
• Cluster authentication settings
• Enrollment secrets
• Authentication tokens
• Access control configuration

These files should be stored securely because they contain sensitive security information.

Custom Scripts

Many organizations automate administrative tasks using custom Bash, Python, or PowerShell scripts.

Examples include:

• Scheduled maintenance
• Alert enrichment
• Threat intelligence lookups
• Automated reporting
• Log processing
• Backup automation

These scripts often represent significant operational knowledge and should be included in every backup.

Dashboard Configuration (If Applicable)

If your Wazuh Dashboard resides on the same server or you manage its configuration alongside the manager, consider backing up:

• Dashboard settings
• Authentication configuration
• Saved objects
• Custom dashboards
• Index patterns
• Visualizations
• Role mappings

Keep in mind that dashboard configuration is separate from the Wazuh Manager itself and may require additional backup procedures.

Related Guide: Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

Where Wazuh Manager Configuration Files Are Stored

Before creating backups, you should know where the configuration files are located.

While most installations follow the standard directory structure, file locations can vary depending on the installation method and deployment architecture.

Default Linux Installation Paths

Most Linux installations place Wazuh Manager files under:

/var/ossec/

This directory contains nearly everything required to operate the manager, including:

• Configuration files
• Rules
• Decoders
• Agent keys
• Active Response scripts
• Logs
• Queues
• Integrations
• SSL certificates

For many environments, backing up the appropriate portions of /var/ossec/ captures the majority of the manager configuration.

Package-Based Installations

Installations performed using RPM or DEB packages generally follow the standard layout.

Common directories include:

Only certain directories contain configuration that needs regular backup.

Temporary queues and runtime files generally do not need to be included unless specifically required for troubleshooting.

Docker Deployments

Docker deployments store configuration differently.

Most production deployments mount persistent Docker volumes or bind mounts that contain:

• Configuration files
• Certificates
• Rules
• Decoders
• Integrations
• Agent keys

Instead of backing up the running container, back up the persistent storage attached to the container.

The Wazuh documentation recommends using persistent volumes to ensure configuration survives container recreation.

Related Guide: Fix Wazuh Docker Compose Deployment

Clustered Wazuh Deployments

In clustered environments, configuration synchronization occurs between cluster nodes, but administrators should still back up the master node regularly.

For high-availability environments, consider backing up:

• Master configuration
• Worker-specific settings
• Cluster certificates
• Synchronization configuration
• Shared agent configuration

Periodic verification ensures synchronization remains healthy across the cluster.

Related Guide: How to Set Up a Multi-Node Wazuh Cluster

Common Directories Worth Backing Up

While every deployment differs slightly, these directories are commonly included in configuration backups:

Backing up these directories captures most of the customization that makes your Wazuh deployment unique.

Prerequisites Before Creating a Backup

Before creating a backup, perform a few simple checks to ensure the process completes successfully and produces a usable backup.

Root or sudo Access

Most Wazuh configuration files are owned by the ossec user or require elevated privileges to access.

Run backup commands using:

sudo

or as the root user to avoid permission-related failures.

Verify Available Disk Space

Configuration backups are relatively small compared to indexed security data, but compressed archives can still consume significant storage over time.

Before creating backups, verify available space:

df -h

Also ensure your destination storage has sufficient capacity for multiple backup generations.

Identify the Wazuh Installation Path

Although /var/ossec/ is the standard installation directory, always confirm the location before creating backup scripts.

If your deployment uses custom paths, update your backup commands accordingly.

This is particularly important for:

• Docker deployments
• Custom Linux installations
• Clustered environments
• Restored systems

Decide on a Backup Location

Choose a backup destination that balances security, reliability, and accessibility.

Common options include:

• Dedicated backup server
• External storage
• Network Attached Storage (NAS)
• Secure cloud object storage
• Offline encrypted storage
• Enterprise backup platforms

Follow the widely recommended 3-2-1 backup strategy: maintain at least three copies of your data, on two different storage media, with one copy stored off-site.

This approach is advocated by backup and disaster recovery experts because it improves resilience against hardware failures, ransomware, and site-wide disasters.

Test Backup Permissions

A backup is only valuable if it can be created and restored successfully.

Before automating the process:

• Verify read permissions on all required files.
• Confirm write permissions to the backup destination.
• Ensure sufficient privileges to preserve ownership and file permissions.
• Perform a test restore in a non-production environment to validate backup integrity.

Regularly testing your backups helps ensure they remain reliable when you need them most, reducing the risk of unpleasant surprises during a real recovery scenario.

Method 1: Back Up the Entire Wazuh Configuration Directory

Backing up the entire configuration directory is the simplest and most comprehensive approach for most deployments.

Rather than selecting individual files, this method creates a compressed archive containing your Wazuh Manager configuration, custom rules, decoders, certificates, scripts, and other important configuration assets.

This approach is ideal for:

• Small to medium-sized deployments
• Disaster recovery planning
• Pre-upgrade backups
• Configuration migration
• Scheduled automated backups

Create a Compressed Archive

The standard Wazuh installation stores configuration under /var/ossec/.

You can create a compressed archive using the tar utility.

For example:

sudo tar -czpf wazuh-manager-backup-$(date +%F).tar.gz \
/var/ossec/etc \
/var/ossec/active-response

Depending on your deployment, you may also want to include additional directories such as:

• /var/ossec/etc/rules/
• /var/ossec/etc/decoders/
• /var/ossec/etc/shared/
• /var/ossec/etc/lists/
• SSL certificate directories
• Custom integration scripts

If your environment stores custom scripts or certificates outside /var/ossec/, include those paths as well.

Verify the Archive

Never assume a backup completed successfully.

Verify that the archive exists:

ls -lh wazuh-manager-backup-*.tar.gz

Then inspect its contents:

tar -tf wazuh-manager-backup-2026-07-22.tar.gz

Check that important files are present, including:

• ossec.conf
• Custom rules
• Custom decoders
• client.keys
• Certificates
• Active Response scripts

For even greater confidence, perform a test extraction in a temporary directory and confirm that the expected file structure is preserved.

Backup experts consistently emphasize that a backup is only as good as its ability to be restored.

Periodic restore testing is considered a critical part of any backup strategy.

Store the Backup Securely

Configuration backups contain sensitive information, including:

• Authentication keys
• Certificates
• API credentials
• Integration secrets
• Agent enrollment keys
• Internal infrastructure details

Avoid storing backups only on the production server.

Instead, consider storing them in:

• Secure backup servers
• Network Attached Storage (NAS)
• Encrypted external drives
• Secure cloud object storage
• Enterprise backup platforms

Restrict file permissions so only authorized administrators can access backup archives.

Advantages and Disadvantages

For most administrators, this is the recommended backup method because it captures nearly every important configuration component with minimal effort.

Method 2: Back Up Only Critical Configuration Files

Some organizations prefer to back up only the files that contain customizations rather than archiving the entire configuration directory.

This approach reduces storage requirements and makes version control easier, particularly when configuration files are managed through Git or other source control systems.

Export Essential Files

At a minimum, consider backing up:

• ossec.conf
• client.keys
• Custom rules
• Custom decoders
• Shared agent configuration
• Active Response scripts
• Certificates
• API configuration
• Integration configuration
• Agent groups
• Custom lists

For example:

mkdir -p ~/wazuh-config-backup

cp /var/ossec/etc/ossec.conf ~/wazuh-config-backup/
cp /var/ossec/etc/client.keys ~/wazuh-config-backup/
cp -r /var/ossec/etc/rules ~/wazuh-config-backup/
cp -r /var/ossec/etc/decoders ~/wazuh-config-backup/
cp -r /var/ossec/active-response ~/wazuh-config-backup/

Modify the paths as needed to match your deployment.

Organize the Backup Structure

A consistent directory structure makes restoration much easier.

For example:

wazuh-config-backup/
├── etc/
│   ├── ossec.conf
│   ├── client.keys
│   ├── rules/
│   ├── decoders/
│   ├── shared/
│   └── lists/
├── active-response/
├── certificates/
├── api/
└── integrations/

Separating files by function also simplifies configuration reviews and version tracking.

Many administrators choose to place these files under Git version control to document configuration changes over time.

Validate File Integrity

After copying the files, verify that the backup completed correctly.

Common validation techniques include:

• Comparing directory sizes
• Comparing file counts
• Generating SHA-256 checksums
• Reviewing file timestamps
• Opening configuration files for inspection

Example checksum generation:

sha256sum ~/wazuh-config-backup/etc/ossec.conf

Recording checksums allows administrators to detect corruption or unintended modifications before restoration.

Advantages and Disadvantages

This method works particularly well for experienced administrators who understand which files have been customized and who maintain disciplined configuration management practices.

Method 3: Automate Wazuh Manager Configuration Backups

Manual backups are useful before upgrades or major configuration changes, but relying on administrators to remember routine backups is risky.

Automating the process ensures backups are created consistently and reduces the likelihood of human error.

Automation is especially valuable in production environments where configuration changes occur frequently.

Create a Backup Script

Create a simple shell script that archives the required configuration directories and stores them in a designated backup location.

For example:

#!/bin/bash

BACKUP_DIR="/backup/wazuh"
DATE=$(date +%F)

mkdir -p "$BACKUP_DIR"

tar -czpf "$BACKUP_DIR/wazuh-config-$DATE.tar.gz" \
/var/ossec/etc \
/var/ossec/active-response

Depending on your environment, you can extend the script to:

• Include certificates
• Back up API configuration
• Save custom scripts
• Generate checksums
• Log backup activity
• Send success or failure notifications

Schedule with Cron

Once the script has been tested, schedule it using cron.

For example, to create a backup every night at 2:00 AM:

0 2 * * * /usr/local/bin/wazuh-backup.sh

Choose a time when system activity is relatively low to minimize any impact on production workloads.

If configuration changes occur frequently, consider running backups multiple times per day.

Add Backup Rotation

Without rotation, backup archives will continue consuming storage until the backup destination becomes full.

A simple rotation policy can automatically remove older archives.

For example:

find /backup/wazuh -name "*.tar.gz" -mtime +30 -delete

This example retains the last 30 days of backups.

Many organizations implement retention policies such as:

• Daily backups for 30 days
• Weekly backups for 12 weeks
• Monthly backups for one year

The appropriate policy depends on your organization’s recovery objectives and compliance requirements.

Encrypt Backup Archives

Configuration backups often contain sensitive information that should never be stored in plaintext on external systems.

Consider encrypting backup archives before transferring them to remote storage.

Common encryption options include:

• GnuPG (GPG)
• OpenSSL
• Encrypted backup repositories
• Enterprise backup software with built-in encryption

The Center for Internet Security (CIS) recommends protecting backup data with strong encryption and appropriate access controls to reduce the impact of unauthorized access.

Encryption keys should be stored securely and separately from the backup archives themselves.

Test Automated Backups

Automation should never be considered complete until the backups have been successfully restored.

Periodically perform a full restoration in a non-production environment to verify:

• Archives can be extracted
• Configuration files are intact
• Permissions are preserved
• Services start successfully
• Custom rules load correctly
• Agents reconnect properly
• Integrations continue functioning

Wazuh’s official documentation also recommends validating configuration changes before deployment using built-in tools where appropriate, helping reduce the risk of restoring invalid configurations.

A good practice is to incorporate backup verification into your regular maintenance schedule.

Testing not only confirms that the backup process works but also familiarizes administrators with the recovery procedure, significantly reducing downtime during an actual incident.

Backing Up Wazuh Manager Configuration in a Cluster

Clustered Wazuh deployments introduce additional considerations when creating configuration backups.

While a standalone manager stores all configuration locally, a cluster distributes responsibilities across multiple nodes, with the master coordinating synchronization and workers handling agent connections and event processing.

A backup strategy for clustered environments should ensure that all configuration required for cluster operation can be restored without causing synchronization issues or inconsistent behavior between nodes.

Related Guide: How to Set Up a Multi-Node Wazuh Cluster

Master Node Configuration

The master node is the primary source of configuration within a Wazuh cluster.

It typically stores and synchronizes:

• Main configuration files
• Custom rules
• Custom decoders
• Shared agent configuration
• Cluster settings
• Agent groups
• Active Response configuration

Because worker nodes receive synchronized configuration from the master, the master should be considered the highest-priority backup target.

Whenever configuration changes are made, create a fresh backup of the master node before performing upgrades or maintenance.

Worker Node Configuration

Although most configuration originates from the master node, worker nodes may still contain important local settings, including:

• Node-specific configuration
• Local certificates
• Network settings
• Service configuration
• Local logs
• Monitoring scripts

If workers contain custom scripts or deployment-specific modifications, include them in your backup plan as well.

For large clusters, administrators often automate worker backups alongside master backups to simplify disaster recovery.

Cluster Keys

Secure communication between cluster members relies on authentication keys and certificates.

Back up all cluster authentication materials, including:

• Cluster keys
• TLS certificates
• Private keys
• Certificate Authority (CA) certificates

Losing these files can prevent nodes from rejoining the cluster after restoration.

Protect these backups carefully because they contain sensitive authentication credentials.

Related Guide: How to Fix Wazuh Certificate Errors

Synchronization Considerations

Configuration synchronization occurs automatically between cluster members, but backups should still be performed carefully.

Before creating backups:

• Confirm cluster synchronization is healthy.
• Verify there are no pending synchronization errors.
• Ensure all recent configuration changes have propagated to worker nodes.
• Avoid making configuration changes while a backup is in progress.

After restoring a clustered environment, verify that synchronization resumes successfully and that all nodes report consistent configuration.

Best Practices for Cluster Backups

To improve reliability and reduce recovery time, follow these best practices:

• Back up the master node before any major configuration change.
• Schedule automated backups during periods of low activity.
• Encrypt backup archives containing certificates and authentication files.
• Store copies off-site or in secure cloud storage.
• Test cluster restoration procedures regularly.
• Document the recovery process for each cluster node.
• Verify cluster health after every restoration.

The Wazuh documentation recommends maintaining consistent configuration across cluster members to ensure reliable synchronization and predictable detection behavior.

Related Guide: Step-by-Step Wazuh Manager Scaling Guide

How to Verify Your Backup

Creating a backup is only the first step.

Before relying on it during an emergency, you should verify that it is complete, readable, and capable of being restored.

Routine verification helps detect corruption, incomplete backups, permission issues, or missing files before they become critical problems.

Compare File Counts

One of the simplest validation techniques is comparing the number of files in the source directories with those stored in the backup.

For example, compare:

• Configuration files
• Custom rules
• Decoders
• Scripts
• Certificates

Unexpected differences may indicate that files were skipped during the backup process.

Validate Archive Integrity

Compressed archives should always be checked for corruption.

For tar.gz archives, list the contents:

tar -tf wazuh-manager-backup.tar.gz

If the archive opens successfully and displays the expected directory structure, the archive is likely intact.

For additional verification, generate a checksum:

sha256sum wazuh-manager-backup.tar.gz

Store checksum values separately so they can be compared later to detect corruption or tampering.

Review Backup Logs

If your backup process is automated, review backup logs regularly.

Look for:

• Permission errors
• Missing files
• Failed archive creation
• Disk space warnings
• Cron execution failures
• Checksum errors

Monitoring backup logs allows administrators to identify issues long before a restoration becomes necessary.

Perform a Test Restore

The most reliable validation method is restoring the backup to a test environment.

A successful test restore confirms that:

• Files are readable.
• Permissions are preserved.
• Archives are complete.
• Services can start successfully.
• Configuration is usable.

Backup professionals consistently recommend routine restoration testing because many backup failures are only discovered during recovery attempts.

Confirm Configuration Consistency

After restoring the configuration in a test environment:

• Verify ossec.conf loads correctly.
• Confirm custom rules compile successfully.
• Check custom decoders for syntax errors.
• Ensure certificates are recognized.
• Verify Active Response scripts remain executable.
• Confirm integrations load correctly.
• Validate agent communication.

Useful validation commands include:

sudo /var/ossec/bin/wazuh-control status

and:

sudo /var/ossec/bin/wazuh-logtest

The wazuh-logtest utility is particularly useful for confirming that restored rules and decoders behave as expected.

Related Guide: Troubleshooting wazuh-logtest: Why Alerts Are Missing from JSON Output

How to Restore Wazuh Manager Configuration

A successful backup strategy includes a documented restoration procedure.

During an outage, administrators should be able to restore configuration quickly while minimizing downtime and avoiding additional configuration inconsistencies.

The exact process depends on your deployment architecture, but the following workflow applies to most Linux-based Wazuh Manager installations.

Stop Wazuh Services

Before restoring configuration files, stop the Wazuh Manager to prevent services from reading partially restored files.

For systems using systemd:

sudo systemctl stop wazuh-manager

If your deployment includes additional services on the same server, such as the Wazuh Indexer or Dashboard, determine whether they should also be stopped based on your maintenance plan.

Restore Configuration Files

Extract or copy the backed-up configuration files back to their original locations.

For example:

sudo tar -xzpf wazuh-manager-backup.tar.gz -C /

If restoring individual files instead of a complete archive, ensure they are copied to the correct directories while preserving ownership and permissions.

Pay particular attention to:

• ossec.conf
• Shared configuration
• API configuration
• Integration settings
• Cluster configuration

Restore Rules and Decoders

Next, restore your custom detection content.

This typically includes:

• Local rules
• Rule groups
• XML decoders
• JSON decoders
• Regex decoders
• Custom CDB lists

After restoration, verify that these files are free of syntax errors before restarting the manager.

Related Guide:

• How to Create Custom Detection Rules in Wazuh (With Examples)
• How to Fix “Field Already Defined” Syntax Errors in Wazuh Decoders

Restore Certificates

Restore all required certificates and keys to their original locations.

These commonly include:

• Manager certificates
• Private keys
• CA certificates
• Cluster certificates

After copying them, verify:

• File ownership
• File permissions
• Certificate expiration
• Correct file paths referenced in configuration files

Improper permissions are a common cause of TLS communication failures after restoration.

Restore Agent Keys

Restore the client.keys file so previously enrolled agents can continue communicating with the manager without requiring re-enrollment.

After restoration:

• Confirm ownership is correct.
• Restrict file permissions.
• Verify agents authenticate successfully.

If client.keys cannot be restored, agents may need to be re-enrolled individually or through automated enrollment procedures.

Related Guide: Step-by-Step Guide to Wazuh Agent Auto-Enrollment

Restart Wazuh Manager

Once all files have been restored, restart the manager.

For example:

sudo systemctl start wazuh-manager

Monitor startup logs carefully for:

• XML parsing errors
• Missing certificates
• Invalid rule syntax
• Decoder errors
• Integration failures
• Cluster synchronization issues

Resolving these errors immediately helps avoid prolonged monitoring interruptions.

Verify Successful Recovery

After the manager starts successfully, perform a complete post-restoration validation.

Recommended checks include:

• Confirm the manager service is running.
• Verify connected agents begin reporting.
• Check that alerts are being generated.
• Validate custom rules and decoders.
• Confirm Active Response functions correctly.
• Test third-party integrations.
• Verify cluster synchronization (if applicable).
• Review logs for unexpected warnings or errors.

The Wazuh documentation recommends validating service health and reviewing logs after configuration changes or recovery operations to ensure the platform is functioning as expected.

If all validation steps succeed, your Wazuh Manager configuration has been successfully restored, allowing normal security monitoring to resume with minimal disruption.

Best Practices for Wazuh Manager Configuration Backups

A reliable Wazuh Manager configuration backup strategy requires more than simply creating archive files.

Organizations should implement processes that ensure backups are secure, available, regularly tested, and easy to restore during an emergency.

Following these best practices helps reduce recovery time, protect sensitive configuration data, and maintain continuous security monitoring.

Automate Backups

Manual backups are useful before major changes, but they are not reliable as a long-term strategy.

Administrators may forget to create backups before:

• Configuration changes
• Software upgrades
• Rule deployments
• Infrastructure migrations
• Troubleshooting activities

Automated backups ensure that configuration snapshots are created consistently without relying on human memory.

Common automation methods include:

• Cron jobs on Linux servers
• Enterprise backup platforms
• Configuration management tools
• Scheduled scripts using Bash, Python, or Ansible

Related Guide: How to Automate Bulk Wazuh Agent Deployment with Ansible and SCCM

A good practice is to schedule backups:

• Daily for production environments
• Before major changes
• Before Wazuh upgrades
• After significant configuration updates

Follow the 3-2-1 Backup Strategy

The 3-2-1 backup strategy is one of the most widely adopted approaches for protecting critical data.

It recommends maintaining:

• 3 copies of your backup data
• 2 different storage types
• 1 copy stored offsite

For Wazuh Manager configuration backups, this could mean:

• Primary configuration on the production manager
• Local backup archive on separate storage
• Encrypted copy stored in another location

This approach protects against:

• Hardware failures
• Ransomware attacks
• Accidental deletion
• Data center outages
• Natural disasters

Encrypt Backup Files

Wazuh configuration backups frequently contain sensitive security information, including:

• Agent authentication keys
• TLS private keys
• API credentials
• Integration tokens
• Internal infrastructure details

Unencrypted backups create a security risk if they are stolen or accessed by unauthorized users.

Recommended protections include:

• Encrypting backup archives
• Using secure transfer protocols
• Protecting encryption keys separately
• Limiting access to backup storage

Example using GPG:

gpg -c wazuh-manager-backup.tar.gz

This creates an encrypted backup archive that requires a password before extraction.

Store Backups Offsite

Keeping backups only on the Wazuh Manager server creates a single point of failure.

If the server experiences:

• Disk failure
• Ransomware infection
• Accidental deletion
• Hardware damage

your backups may be lost at the same time.

Store copies in separate locations such as:

• Remote backup servers
• Cloud storage platforms
• Secure data centers
• Offline storage systems

Offsite storage is especially important for organizations operating critical security monitoring infrastructure.

Version Your Configuration

Configuration changes should be tracked over time.

Instead of keeping only the latest backup, maintain historical versions that allow administrators to:

• Identify when changes occurred
• Roll back failed modifications
• Compare configuration differences
• Investigate security changes

Many teams use:

• Git repositories
• Configuration management platforms
• Automated backup versioning systems

Version control is particularly useful for:

• Custom rules
• Decoders
• Agent configurations
• Integration files

Related Guide: How to Test Wazuh Rules

Test Restores Regularly

A backup that has never been restored is not guaranteed to work.

Restore testing verifies that:

• Archives are not corrupted
• Required files are included
• Permissions are preserved
• Services start correctly
• Agents reconnect successfully

A recommended practice is performing:

• Monthly restore tests for production systems
• Restore testing before major upgrades
• Disaster recovery exercises

Testing restores ensures administrators know exactly how to recover during a real incident.

Restrict Backup Access

Configuration backups should be protected using the same security controls applied to production systems.

Limit access to authorized administrators only.

Recommended controls include:

• File permissions
• Role-based access control
• Multi-factor authentication
• Audit logging
• Encrypted storage

For example:

chmod 600 wazuh-manager-backup.tar.gz

This prevents unauthorized users from accessing sensitive backup contents.

Document Recovery Procedures

A backup strategy is incomplete without clear recovery documentation.

Create a recovery guide that includes:

• Backup locations
• Restoration commands
• Required permissions
• Service restart procedures
• Validation steps
• Contact information for responsible administrators

Documentation reduces recovery time because administrators do not need to recreate procedures during an emergency.

Monitor Backup Jobs

Automated backups can fail silently if they are not monitored.

Track:

• Successful backup completion
• Failed archive creation
• Storage availability
• Permission errors
• Encryption failures
• Backup duration

Consider sending notifications when:

• A backup fails
• Storage reaches capacity
• The backup size changes unexpectedly

Monitoring ensures backup failures are discovered before recovery is required.

Keep Backup Retention Policies

Keeping every backup forever creates unnecessary storage costs and management complexity.

Define retention rules based on:

• Organization requirements
• Compliance standards
• Recovery objectives
• Available storage capacity

Example retention schedule:

A structured retention policy ensures you have enough historical recovery points without unnecessary storage usage.

Common Backup Mistakes to Avoid

Even organizations with backup procedures can experience recovery failures because important configuration components were overlooked.

Avoiding these common mistakes improves the reliability of your Wazuh Manager backup strategy.

Forgetting Custom Rules

Custom rules are often the most valuable part of a Wazuh deployment because they contain organization-specific detection logic.

Failing to back them up can result in losing:

• Custom threat detections
• Compliance monitoring rules
• Application-specific alerts
• Security tuning adjustments

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

Missing client.keys

The client.keys file contains authentication information for registered agents.

If it is missing during recovery:

• Existing agents may fail authentication
• Large environments may require mass re-enrollment
• Recovery time increases significantly

Always include this file in configuration backups.

Ignoring Certificates

TLS certificates are essential for secure communication between Wazuh components.

Missing certificates can cause:

• Agent communication failures
• Cluster connection problems
• Dashboard authentication issues
• API errors

Related Guide: How to Fix Wazuh Certificate Errors

Backing Up Live Temporary Files

Not every file under /var/ossec/ needs to be backed up.

Including temporary runtime data can:

• Increase backup size
• Slow restoration
• Restore outdated runtime information

Focus backups on configuration, rules, certificates, scripts, and authentication data.

Never Testing Restores

A backup that cannot be restored provides a false sense of security.

Common restoration problems include:

• Missing files
• Incorrect permissions
• Corrupted archives
• Invalid paths
• Missing dependencies

Always perform periodic restore tests.

Storing Backups on the Same Server

Keeping backups on the same machine defeats the purpose of disaster recovery.

If the Wazuh Manager fails completely, local backups may also become unavailable.

Use separate storage whenever possible.

Skipping Permission Preservation

Linux file permissions are important for Wazuh security.

Incorrect permissions after restoration can prevent:

• Services from starting
• Certificates from loading
• Scripts from executing

When creating archives, preserve ownership and permissions:

tar -czpf backup.tar.gz /var/ossec/etc

The p option preserves permissions.

Overwriting Previous Backups

Keeping only one backup version creates unnecessary risk.

If that backup contains corrupted configuration or accidental changes, recovery options are limited.

Maintain multiple backup generations to provide rollback options.

Real-World Example

Scenario

A healthcare organization operates a highly available Wazuh deployment that monitors more than 8,000 Linux, Windows, and cloud workloads across its infrastructure.

The security operations team relies on Wazuh for:

• Endpoint monitoring
• Compliance visibility
• Threat detection
• File Integrity Monitoring
• Security alert generation

Before upgrading the Wazuh Manager to a newer version, the team creates a complete configuration backup.

The backup includes:

• ossec.conf
• Custom detection rules
• Custom decoders
• Agent enrollment keys (client.keys)
• TLS certificates
• Active Response scripts
• Cluster configuration files
• Integration settings

Related Guide: Step-by-Step Wazuh Manager Scaling Guide

During the upgrade process, a configuration conflict prevents the Wazuh Manager service from starting correctly.

The issue is caused by an incompatibility between the updated configuration and existing custom security policies.

Without a backup, administrators would need to manually rebuild months of configuration changes, including:

• Custom detection rules
• Decoder definitions
• Agent configurations
• Integration settings
• Automated response workflows

Instead, the security team restores the previously tested backup archive.

The recovery process includes:

1. Stopping the affected Wazuh services.
2. Restoring configuration files.
3. Replacing custom rules and decoders.
4. Restoring certificates and authentication keys.
5. Restarting the manager services.
6. Validating cluster health and agent connectivity.

Within minutes, the environment returns to normal operation.

Because the backup had already been validated through restore testing:

• Agent communication resumes immediately.
• Custom detection rules continue generating alerts.
• Active Response workflows remain operational.
• The security operations center avoids extended monitoring downtime.

This example demonstrates why Wazuh Manager configuration backups are not just an administrative task, they are a critical component of maintaining a resilient security monitoring infrastructure.

Frequently Asked Questions (FAQ)

Question: Does backing up the Wazuh Manager configuration also back up alerts and indexed security events?

No. A Wazuh Manager configuration backup does not include historical security alerts, indexed events, dashboards, or searchable security data stored in the Wazuh Indexer.

The manager configuration contains operational settings such as:

• ossec.conf
• Custom rules
• Custom decoders
• Agent configuration
• Certificates
• Active Response scripts
• Integration settings

Historical alerts and event data are stored separately in the Wazuh Indexer or OpenSearch cluster.

For a complete disaster recovery strategy, organizations should back up both:

1. Wazuh Manager configuration
   • Controls how security monitoring operates.
2. Wazuh Indexer data
   • Contains collected security events, alerts, dashboards, and historical records.

Treat these as separate backup processes because restoring one does not restore the other.

Related Guide: How to Build a Wazuh Indexer Cluster

Question: Which files are most important to include in a Wazuh configuration backup?

The most important Wazuh Manager configuration files depend on your deployment, but a complete backup should generally include:

• ossec.conf
• local_internal_options.conf
• Custom rules
• Custom decoders
• client.keys
• Agent groups
• Shared configuration
• SSL/TLS certificates
• Active Response scripts
• Integration configurations
• API configuration
• Custom scripts

The most commonly overlooked files are:

• client.keys
• Custom rules
• Custom decoders
• Certificates

Missing these files can significantly increase recovery time after a failure.

Related Guide: How to Configure ossec.conf for Log Monitoring in Wazuh

Question: How often should I back up my Wazuh Manager configuration?

The backup frequency depends on how frequently your environment changes.

Recommended schedules include:

• Daily backups for production environments
• Weekly backups for smaller deployments
• Before every upgrade
• Before major configuration changes
• After deploying new detection rules or integrations

Security teams managing large Wazuh environments should consider automated daily backups combined with additional snapshots before major changes.

The goal is to ensure that the most recent working configuration can always be restored.

Question: Can I automate Wazuh configuration backups?

Yes. Automating backups is strongly recommended for production deployments.

Common automation approaches include:

• Linux cron jobs
• Bash scripts
• Ansible automation
• Enterprise backup platforms
• Cloud backup solutions

An automated backup process should include:

• Archive creation
• Backup naming
• Encryption
• Storage transfer
• Retention management
• Success/failure notifications

Related Guide: How to Automate Bulk Wazuh Agent Deployment with Ansible and SCCM

Automation reduces the risk of forgetting backups and ensures consistent recovery points.

Question: Should I stop the Wazuh Manager before creating a backup?

For most configuration-only backups, stopping the Wazuh Manager is not always required.

However, stopping services before creating a backup can provide a more consistent snapshot, especially when backing up:

• Authentication files
• Certificates
• Cluster configuration
• Files being actively modified

A common approach is:

1. Stop Wazuh Manager services.
2. Create the backup archive.
3. Verify the archive.
4. Restart services.

For automated backups, many administrators create backups while services are running because configuration files typically change infrequently.

Question: How do I restore a Wazuh Manager configuration after a failure?

A typical restoration process involves:

1. Installing the same or compatible Wazuh version.
2. Stopping Wazuh services.
3. Restoring configuration files.
4. Restoring rules and decoders.
5. Restoring certificates.
6. Restoring client.keys.
7. Restoring integrations and scripts.
8. Restarting Wazuh services.
9. Validating agent communication and alerts.

After restoration, verify:

• Manager service health
• Agent connectivity
• Rule loading
• Decoder functionality
• Integration status
• Cluster synchronization

A tested restoration procedure significantly reduces recovery time during a real outage.

Related Guide: Wazuh Agent Not Connecting to Manager? 12 Proven Fixes

Question: Do clustered Wazuh deployments require backing up every node?

Not always.

In most Wazuh clusters, the master node contains the primary configuration that synchronizes with worker nodes.

However, administrators should still consider backing up:

• Master node configuration
• Worker-specific settings
• Cluster certificates
• Authentication keys
• Local customization files

For high-availability environments, maintaining backups of all nodes provides additional protection and simplifies full cluster recovery.

Related Guide: How to Set Up a Multi-Node Wazuh Cluster

Question: Is it safe to store Wazuh backups in cloud storage?

Yes, but only when proper security controls are applied.

Cloud storage can be an excellent backup destination because it provides:

• Offsite protection
• Scalability
• Geographic redundancy
• Automated retention options

However, Wazuh backups contain sensitive information, so organizations should use:

• Encryption at rest
• Encryption during transfer
• Strong access controls
• Multi-factor authentication
• Private storage buckets
• Audit logging

Never upload unencrypted Wazuh configuration backups to publicly accessible storage.

Question: Can I migrate a Wazuh Manager configuration to a new server using a backup?

Yes. A configuration backup can be used to migrate a Wazuh Manager deployment to new hardware or a new virtual machine.

A typical migration process includes:

1. Install Wazuh on the new server.
2. Stop Wazuh services.
3. Restore configuration files.
4. Restore certificates and authentication keys.
5. Restore custom rules and decoders.
6. Start services.
7. Validate communication.

Before migration, ensure:

• The Wazuh versions are compatible.
• File ownership is preserved.
• Network settings are updated.
• Certificates match the new environment.

Configuration backups are commonly used during hardware replacements, cloud migrations, and infrastructure upgrades.

Question: What’s the difference between backing up the Wazuh Manager configuration and backing up the Wazuh Indexer data?

The two backups protect different parts of the Wazuh platform.

For example:

• Restoring the manager configuration restores your detection logic.
• Restoring the indexer restores your historical security visibility.

A complete Wazuh disaster recovery strategy should include both.

Conclusion

A Wazuh Manager configuration backup is one of the most important safeguards for maintaining a reliable security monitoring environment.

While Wazuh provides powerful detection and response capabilities, those capabilities depend heavily on the configuration files, custom rules, certificates, integrations, and scripts created by administrators over time.

Without proper backups, organizations risk losing:

• Custom detection logic
• Agent authentication settings
• Security integrations
• Active Response workflows
• Cluster configuration
• Months or years of security tuning

The safest backup approach is to combine multiple strategies:

• Create complete configuration archives for fast disaster recovery.
• Back up critical files separately for easier version control.
• Automate backups to eliminate human error.
• Encrypt backup archives to protect sensitive security information.
• Store copies in secure offsite locations.

Related Guide: How to Configure Wazuh Log Retention

Regular backup testing is just as important as creating backups.

A backup that has never been restored cannot be considered reliable.

Performing scheduled restore tests ensures your team can recover quickly and confidently during hardware failures, failed upgrades, security incidents, or unexpected configuration problems.

Organizations running Wazuh in production should implement an automated backup and recovery strategy that includes:

• Scheduled configuration backups
• Secure storage
• Retention policies
• Backup monitoring
• Regular restoration testing

By treating Wazuh configuration as a critical security asset, organizations can minimize downtime, preserve custom security controls, and maintain continuous threat detection even during unexpected failures.