How to Backup Wazuh RBAC Configurations

Test and Validate the Restored RBAC Configuration

Restoring Wazuh RBAC configuration is only the first stage of recovery.

The next step is to prove that the restored authorization model works as intended.

A successful test should verify both positive authorization and negative authorization.

Users should be able to perform the actions assigned to their roles, while unauthorized operations should continue to be denied.

Testing should cover the Wazuh Server API, Wazuh Dashboard, Wazuh Indexer, authentication providers, and tenant configuration where applicable.

Test Administrator Authentication

Start with an administrator account.

Confirm that the administrator can successfully authenticate through the configured authentication method.

If using local authentication, test the internal administrator account.

If using SSO, test the appropriate administrator identity or group.

After authentication, verify that the administrator can:

• Access the Wazuh Dashboard.
• Access security-management functionality.
• View users.
• View roles.
• View role mappings.
• Access required Indexer security functionality.
• Perform permitted administrative API operations.

A successful login alone does not prove that the administrator role was restored correctly.

For example, the administrator might authenticate successfully but receive a 403 Forbidden response when attempting an operation that should be permitted.

Test Analyst Permissions

Next, test a representative analyst account.

The analyst should be able to perform normal monitoring tasks such as:

• View permitted alerts.
• View agents.
• Search authorized security data.
• Access assigned Dashboard functionality.
• View permitted visualizations and saved objects.

The analyst should not be able to perform administrator-only operations such as:

• Creating privileged users.
• Modifying security roles.
• Changing critical authorization settings.
• Accessing restricted tenants.
• Performing unauthorized administrative API requests.

This verifies that the restored role contains the intended least-privilege permissions.

Test Incident Responder Permissions

If your environment has a dedicated incident-response role, test it separately.

An incident responder may have more privileges than a read-only analyst but fewer than a Wazuh administrator.

For example:

Incident Responder
├── Read alerts
├── Read agent information
├── Investigate events
├── Perform approved response actions
└── No user/role administration

Test both the permissions that should succeed and operations that should remain blocked.

This is important because a role restoration problem can manifest as either missing permissions or excessive permissions.

Test Restricted Resources

Negative testing is an essential part of RBAC validation.

Attempt to access a resource that the test account should not be authorized to access.

For example:

Analyst → Read alerts              → ALLOWED
Analyst → View assigned agents     → ALLOWED
Analyst → Modify security role     → DENIED
Analyst → Create administrator     → DENIED

The expected result should be an authorization failure such as HTTP 403 Forbidden, depending on the interface and operation being tested.

Do not disable security controls simply to make the test succeed.

The purpose of the test is to demonstrate that the restored RBAC configuration continues enforcing the intended security boundary.

Test Tenant Access

If multi-tenancy is enabled, test every important user category against its expected tenant.

For example:

Confirm that users can access the correct tenant and cannot access tenants outside their assigned permissions.

Also verify that tenant-specific saved objects and Dashboard functionality behave as expected.

Test SSO Role Mappings

SSO environments require additional testing because authentication and authorization occur across multiple systems.

Test a representative user from each important identity-provider group.

For example:

IdP Group: SOC-Analysts
        ↓
Wazuh Role Mapping
        ↓
Analyst Role
        ↓
SOC Tenant

Verify that the expected identity-provider group results in the expected Wazuh role.

Test at least:

• Analyst group.
• Incident-response group.
• Administrator group.
• Auditor group.

Also test a user who belongs to no privileged group.

That user should not unexpectedly receive an administrative role.

Related Guides:

•  How to Configure Wazuh SAML Authentication
•  How to Configure Wazuh OIDC
• How to Configure Wazuh LDAP Authentication

Check Wazuh Dashboard Access

After restoring the RBAC configuration, verify the Dashboard from the perspective of multiple user roles.

Check:

• Login.
• Dashboard loading.
• Alerts.
• Discover/search functionality.
• Agent views.
• Security-management pages.
• Tenant selection.
• Saved objects.
• Role-specific functionality.

If a user can authenticate but the Dashboard displays errors such as missing data or forbidden operations, investigate both Wazuh RBAC and Indexer permissions.

This is one reason why it is important to distinguish between Wazuh Server API authorization and Indexer authorization.

Review Wazuh and Indexer Logs

Logs can reveal authorization problems that are not immediately obvious from the Dashboard.

Review the relevant Wazuh and Indexer logs after testing.

Search for terms such as:

grep -iE 'security|permission|forbidden|unauthorized|authentication|authorization' \
    /var/log/wazuh-indexer/*.log

Depending on your environment, also review Wazuh Manager and Dashboard logs.

Look for:

• Authentication failures.
• Authorization failures.
• Missing roles.
• Invalid role mappings.
• Security-plugin errors.
• Certificate errors.
• Configuration parsing failures.
• Tenant authorization failures.

Do not treat every 403 as a Wazuh RBAC problem.

A 403 can originate from different authorization layers, so correlate the request with the affected component and log entry.

Confirm Unauthorized Access Remains Blocked

The final validation step is to prove that security restrictions survived the restoration.

Create a test matrix:

This is the most important part of the validation process.

A restoration should reproduce the security boundaries, not simply make the application accessible again.

Troubleshoot Wazuh RBAC Backup and Restore Problems

RBAC restoration problems can originate from several different layers.

A missing role may be caused by an incomplete backup, an incorrect Indexer security configuration, a failed API import, an SSO mapping problem, or a version mismatch.

When troubleshooting, identify the layer first:

Authentication
     ↓
Wazuh Dashboard
     ↓
Wazuh Server API RBAC
     ↓
Wazuh Indexer Security
     ↓
Tenant / Data Permissions

This prevents administrators from attempting to fix an Indexer authorization problem by changing Wazuh Server API roles, or vice versa.

RBAC Configuration Files Are Missing

If expected files are absent from the backup, first inspect the archive:

tar -tzpf wazuh-rbac-backup.tar.gz

Then compare the archive contents against your documented backup inventory.

Check for:

• roles_mapping.yml.
• roles.yml.
• internal_users.yml.
• Tenant configuration.
• Dashboard security configuration.
• API exports.
• SSO-related configuration.

If files are missing, do not assume the backup is complete.

Identify the most recent known-good backup that contains the missing configuration.

You should also review the backup script to determine whether:

• The source path changed.
• The file was moved.
• The backup command failed.
• Permissions prevented access.
• A new Wazuh version changed the configuration structure.

Restored Roles Do Not Appear

If a restored role does not appear, determine which RBAC layer owns the role.

First distinguish:

• Wazuh Server API role.
• Wazuh Indexer role.
• Dashboard role mapping.

Then verify the source configuration or API response.

For Server API RBAC, query the security API and verify the role exists.

For Indexer security, inspect the applicable security configuration and confirm that the restored role was actually applied to the security subsystem.

Also check for:

• Incorrect role names.
• Syntax errors.
• Version incompatibility.
• Failed security-plugin updates.
• Restoring configuration to the wrong node.
• Restoring configuration without applying it.

Users Cannot Authenticate After Restoration

Authentication failures should be investigated separately from authorization failures.

Ask:

Can the user authenticate, or can they authenticate but lack permissions?

If authentication itself fails, check:

• Internal-user configuration.
• Password hashes.
• LDAP configuration.
• SAML configuration.
• OIDC configuration.
• Certificates.
• Identity-provider connectivity.
• Dashboard authentication configuration.

Also, if only one user fails, compare that user’s configuration with another working user.

If every user fails, investigate the authentication provider and security configuration before changing individual role mappings.

Related Guides:

• How to Configure Wazuh SSO
• How to Configure Wazuh LDAP Authentication

Role Mappings Are Not Working

If users authenticate but receive the wrong permissions, inspect the mappings.

For local users, verify:

User
 ↓
Role Mapping
 ↓
Role
 ↓
Permissions

For SSO users:

IdP Group / Claim
 ↓
Backend Role
 ↓
Wazuh/Indexer Role Mapping
 ↓
Effective Permissions

Common causes include:

• Incorrect group name.
• Incorrect backend role.
• Case mismatch.
• Missing mapping.
• Mapping assigned to the wrong role.
• Conflicting mappings.
• Incorrect SAML attribute.
• Incorrect OIDC claim.
• Stale SSO session.

After correcting a mapping, sign out and establish a new authentication session rather than relying on an existing session.

Dashboard Permissions Are Incorrect

If the Dashboard loads but users see incorrect functionality, determine whether the problem originates from Dashboard configuration, Wazuh Server API RBAC, or Indexer security.

For example:

Dashboard loads
       ↓
User authenticates
       ↓
Page displays
       ↓
Data request → 403

This often indicates an authorization problem below the Dashboard layer rather than a basic Dashboard availability issue.

Check:

• User’s effective role.
• Indexer role.
• Wazuh API role.
• Tenant permissions.
• wazuh.yml.
• SSO mappings.
• Indexer security logs.

See our Wazuh Dashboard Not Loading? Complete Troubleshooting Guide if the restoration causes broader Dashboard availability problems.

SSO Users Receive Incorrect Roles

If SSO authentication succeeds but users receive the wrong role, compare the identity-provider attributes with the role mappings expected by Wazuh.

Check:

• SAML attributes.
• OIDC claims.
• LDAP groups.
• Backend roles.
• Group names.
• Role-mapping definitions.
• Tenant mappings.

For example, if the identity provider returns:

groups = ["SOC-Analysts"]

but Wazuh expects:

groups = ["soc_analysts"]

the mapping may not match.

Also check for users belonging to multiple groups.

Multiple mappings can result in multiple effective roles, depending on the authorization configuration.

Multi-Tenancy Stops Working

If users can authenticate but tenant access is incorrect, verify:

• Tenant definitions.
• Role-to-tenant permissions.
• User-to-role mappings.
• Indexer roles.
• Dashboard tenant configuration.
• SSO group mappings.

Test each tenant using representative accounts.

If every user suddenly sees the same tenant after restoration, compare the restored tenant and role configuration with the known-good backup.

Security Configuration Fails to Load

A security configuration that fails to load may contain:

• Invalid YAML.
• Invalid JSON.
• Incorrect indentation.
• Unsupported configuration parameters.
• Invalid role names.
• Invalid permissions.
• Incompatible configuration from another Wazuh version.

Before applying a restored file, inspect it:

sudo less /path/to/restored/configuration.yml

If your Wazuh version provides configuration-validation utilities, use the appropriate tool before restarting a production service.

Do not repeatedly restart the service without identifying the underlying configuration error.

Wazuh Indexer Reports Security Plugin Errors

Indexer security errors require particular attention because the Indexer security layer is separate from Wazuh Server API RBAC.

Review the Indexer logs for messages related to:

security plugin
authentication
authorization
roles
role mappings
certificates
configuration

Common causes include:

• Invalid security configuration.
• Incorrect certificates.
• Incorrect file ownership.
• Failed security-admin operation.
• Cluster communication problems.
• Incompatible security configuration.
• Corrupted configuration.
• Restoring the wrong cluster’s security state.

See our How to Fix Wazuh Certificate Errors guide if when security-plugin failures involve TLS or certificate validation.

File Ownership or Permissions Cause Failures

Restored files may have incorrect ownership after being copied from another server or extracted from an archive.

Check:

ls -la /etc/wazuh-indexer/opensearch-security/

and:

stat /etc/wazuh-indexer/opensearch-security/roles_mapping.yml

Compare the restored permissions with a known-good installation.

Do not blindly assign permissions copied from another Wazuh installation.

Ownership requirements can vary by component and installation method.

The correct approach is to restore ownership and permissions appropriate to the target system.

Configuration Differs Between Cluster Nodes

If nodes have inconsistent security configuration, identify which node contains the intended state.

Compare relevant configuration carefully:

sha256sum /etc/wazuh-indexer/opensearch-security/roles_mapping.yml

Repeat on each relevant node.

However, a checksum difference does not automatically mean that the cluster is broken.

Some files may legitimately contain node-specific configuration.

Focus on security objects that should be consistent across the cluster.

If the cluster’s effective authorization state differs from the intended backup, follow the Wazuh-supported procedure for synchronizing the security configuration rather than manually overwriting every node.

Best Practices for Backing Up Wazuh RBAC

A reliable Wazuh RBAC backup strategy should combine automation, secure storage, versioning, integrity verification, and periodic restoration tests.

The objective is not simply to have a collection of configuration files.

The objective is to maintain a known-good, recoverable authorization configuration.

Follow the 3-2-1 Backup Strategy

Apply the 3-2-1 principle to RBAC backups:

• 3 copies of important backup data.
• 2 different storage media or systems.
• 1 copy stored off-site or otherwise isolated from production.

For example:

Production Wazuh
       │
       ├── Local backup
       │
       ├── Backup server
       │
       └── Immutable/offline copy

For critical environments, consider extending this with immutable storage and geographically separate recovery infrastructure.

Back Up Before RBAC Changes

Create an immediate backup before:

• Creating roles.
• Deleting roles.
• Changing permissions.
• Changing role mappings.
• Modifying internal users.
• Changing LDAP mappings.
• Changing SAML configuration.
• Changing OIDC configuration.
• Modifying tenant permissions.
• Upgrading Wazuh.
• Changing Indexer security configuration.

This gives you a clear rollback point.

A simple naming convention can identify the purpose:

wazuh-rbac-before-sso-change-20260810.tar.gz

rather than:

backup-final-new2.tar.gz

Maintain Versioned RBAC Backups

Keep multiple historical versions instead of overwriting the previous backup.

A useful directory structure is:

/backups/wazuh-rbac/
├── 2026/
│   ├── 08/
│   │   ├── 20260808-010000/
│   │   ├── 20260809-010000/
│   │   └── 20260810-010000/

This allows administrators to restore the RBAC configuration from a specific point in time.

Versioning is particularly useful when a problem is discovered days after an authorization change.

Automate Recurring Backups

Scheduled backups eliminate dependence on administrator memory.

Use a tested script and schedule it through cron, a system scheduler, or your organization’s enterprise backup platform.

The automated process should:

1. Collect RBAC configuration.
2. Export API settings.
3. Create an archive.
4. Generate a checksum.
5. Encrypt the backup.
6. Transfer it to secure storage.
7. Apply retention.
8. Report failures.

Encrypt Sensitive Configuration

RBAC configuration should be encrypted when stored outside the protected Wazuh host.

Encrypt:

• Backup archives.
• API exports.
• Internal-user configuration.
• SSO-related configuration containing secrets.
• Private certificates.
• Authentication credentials.

Keep encryption keys separate from the backup data.

For enterprise environments, use centralized key-management and secrets-management systems whenever available.

Store Backups Outside the Wazuh Cluster

Do not depend on a backup stored only on the Wazuh Manager or Indexer cluster.

If the cluster suffers:

• Ransomware.
• Hardware failure.
• Storage corruption.
• Administrative compromise.
• Accidental deletion.

the local backup could disappear at the same time.

Use a separate backup system with separate credentials.

A compromised Wazuh administrator should not automatically have permission to delete every historical RBAC backup.

Test Restoration Regularly

Schedule restoration exercises.

For example:

Monthly
  ↓
Select recent backup
  ↓
Restore into isolated environment
  ↓
Test administrator
  ↓
Test analyst
  ↓
Test responder
  ↓
Test SSO
  ↓
Test tenant restrictions

Record the results.

If restoration fails, treat the failure as a backup-system incident and correct the backup process immediately.

Document the Restoration Procedure

A backup is much more valuable when another administrator can restore it without relying on tribal knowledge.

Your recovery documentation should include:

• Backup locations.
• Backup naming conventions.
• Encryption process.
• Key-management procedure.
• Wazuh version compatibility requirements.
• Indexer restoration procedure.
• Dashboard restoration procedure.
• Server API RBAC restoration procedure.
• SSO restoration procedure.
• Tenant restoration procedure.
• Validation checklist.
• Rollback procedure.
• Emergency administrator access procedure.

Keep the recovery documentation separate from the production Wazuh server so it remains available if the server is completely unavailable.

Monitor Backup Success and Failure

Configure monitoring for the backup process.

Alert when:

• A scheduled backup does not run.
• The backup script exits unsuccessfully.
• API authentication fails.
• The archive cannot be created.
• Encryption fails.
• The remote transfer fails.
• The backup destination is unavailable.
• Disk space becomes low.
• A checksum does not match.

A particularly useful control is a backup freshness alert.

For example:

No successful Wazuh RBAC backup has been created in the last 25 hours.

This catches situations where the scheduler itself has stopped running.

Review RBAC Backups After Major Wazuh Upgrades

After a Wazuh upgrade, verify that your backup procedure still captures the correct security configuration.

Check:

• Configuration paths.
• API endpoints.
• RBAC objects.
• Indexer security files.
• Dashboard configuration.
• Authentication integrations.
• Tenant configuration.
• Backup scripts.
• File permissions.

Do not assume that a backup script written for an older Wazuh release will continue to capture every required file after an upgrade.

Perform a test backup after the upgrade and compare it with the previous version.

See our How to Upgrade a Wazuh Agent  guide for more information.

A mature RBAC backup strategy should ultimately provide four guarantees:

                Wazuh RBAC
                    │
        ┌───────────┼───────────┐
        ↓           ↓           ↓
     Capture     Protect      Verify
        │           │           │
        ↓           ↓           ↓
     Version     Encrypt      Restore
        │           │           │
        └───────────┼───────────┘
                    ↓
             Reliable Recovery

If you can consistently capture, protect, verify, and restore your Wazuh RBAC configuration, you have moved beyond simply keeping configuration copies and established a practical RBAC disaster-recovery capability.

Real-World Wazuh RBAC Backup and Recovery Example

Consider an enterprise Security Operations Center (SOC) running Wazuh across a multi-node deployment.

The organization uses Wazuh to monitor servers, workstations, cloud infrastructure, and network devices while separating security responsibilities between administrators, analysts, incident responders, and auditors.

The SOC has four primary user groups:

The organization also uses SSO and multi-tenancy to prevent users from accessing security data outside their responsibilities.

Separate Wazuh Administrators, Analysts, Responders, and Auditors

The SOC begins by defining custom roles based on least privilege.

For example:

wazuh_admin
    └── Full administrative access

soc_analyst
    ├── Read alerts
    ├── Search security data
    ├── View agents
    └── No RBAC administration

incident_responder
    ├── Analyst permissions
    ├── Approved response operations
    └── No user/role administration

security_auditor
    ├── Read-only access
    ├── Compliance visibility
    └── No configuration changes

This approach prevents every SOC employee from receiving administrator privileges simply because they need access to Wazuh.

Create Custom RBAC Roles

The organization creates custom roles based on the tasks performed by each team.

Rather than giving analysts unrestricted access, the SOC defines exactly which resources and operations each role requires.

For example, the incident responder role may be allowed to perform approved response actions while remaining unable to modify authentication providers or create administrator accounts.

The resulting authorization model follows:

User
  ↓
Identity Provider Group
  ↓
Role Mapping
  ↓
Custom Wazuh Role
  ↓
Permissions
  ↓
Tenant Access

This makes the RBAC configuration easier to audit and restore because each authorization decision has a documented purpose.

Configure Role Mappings and Multi-Tenancy

The enterprise uses SSO groups to assign Wazuh roles.

For example:

SOC-Admins       → wazuh_admin
SOC-Analysts     → soc_analyst
SOC-Responders   → incident_responder
SOC-Auditors     → security_auditor

The SOC also separates data using tenants.

SOC Tenant
├── Analysts
└── Responders

Audit Tenant
└── Auditors

Administrative Tenant
└── Wazuh Administrators

This prevents an analyst assigned to the SOC tenant from automatically gaining access to audit or administrative data.

Schedule Automated RBAC Backups

The SOC creates a scheduled backup process that runs every night.

The backup process captures:

• Wazuh RBAC configuration.
• Indexer security configuration.
• Custom roles.
• Role mappings.
• Internal users.
• Tenant configuration.
• Relevant Dashboard security configuration.
• API-based RBAC exports.

A typical backup directory might look like:

/var/backups/wazuh-rbac/
├── 2026-08-08/
├── 2026-08-09/
└── 2026-08-10/

Each backup is timestamped so administrators can identify the exact recovery point.

The backup process also generates SHA-256 checksums and records whether the operation completed successfully.

Store Encrypted Backups on a Separate Backup Server

The SOC does not keep its only RBAC backup on the Wazuh infrastructure.

After creation, the backup is encrypted and transferred to a dedicated backup server.

The architecture looks like:

Wazuh Cluster
      │
      │ Encrypted transfer
      ▼
Dedicated Backup Server
      │
      ├── Daily backups
      ├── Weekly backups
      └── Monthly backups

The backup server uses restricted permissions so that only authorized recovery administrators can access the archives.

For stronger protection, the organization also maintains an offline or immutable copy.

This prevents an attacker who compromises the Wazuh environment from simply deleting the backups needed for recovery.

Simulate Wazuh Indexer Failure

The SOC performs a disaster-recovery exercise rather than waiting for a real outage.

During the exercise, the primary Wazuh Indexer node is treated as unavailable.

The recovery team verifies that:

1. The failed node cannot provide the expected Indexer functionality.
2. The latest RBAC backup is available.
3. The backup checksum is valid.
4. The backup corresponds to the deployed Wazuh version.
5. The recovery procedure is documented.

The team then provisions a replacement Indexer environment using the organization’s normal Wazuh deployment procedure.

Restore RBAC Configurations

Once the replacement environment is ready, the recovery team restores the appropriate security configuration.

The recovery process restores the required:

Indexer security configuration
        ↓
Custom roles
        ↓
Role mappings
        ↓
Internal users
        ↓
Tenant configuration
        ↓
Dashboard security settings

The team does not simply copy files and assume recovery is complete. It follows the appropriate Wazuh security-configuration procedure and verifies that the restored configuration has actually been applied.

Afterward, the team checks Indexer and Wazuh logs for configuration or security-plugin errors.

Validate User Access and Permissions

The SOC then performs role-based validation.

The administrator verifies full administrative access.

The analyst verifies that alerts and assigned security data are accessible.

The incident responder verifies the additional response permissions.

The auditor verifies read-only access.

The team also performs negative tests:

Analyst → Create administrator role       DENIED
Analyst → Modify RBAC configuration       DENIED
Auditor → Modify security configuration   DENIED
Responder → Access unauthorized tenant    DENIED
Administrator → Administrative functions  ALLOWED

The SOC also tests SSO authentication to ensure that identity-provider groups still map to the correct Wazuh roles.

Document the Disaster Recovery Process

After the exercise, the SOC documents:

• Backup location.
• Backup schedule.
• Encryption process.
• Retention policy.
• Wazuh and Indexer versions.
• Recovery prerequisites.
• Restoration commands and procedures.
• SSO configuration dependencies.
• Tenant configuration.
• Validation tests.
• Rollback procedure.
• Recovery responsibilities.

The organization records the recovery time and any problems encountered during the exercise.

This turns the RBAC backup from a passive collection of files into a tested Wazuh authorization disaster-recovery process.

Frequently Asked Questions

Question: What is a Wazuh RBAC backup?

A Wazuh RBAC backup is a protected copy of the configuration that defines Wazuh users, roles, permissions, role mappings, tenants, and related authentication and authorization settings.

Depending on the deployment, a complete backup can involve both Wazuh Server API RBAC data and Wazuh Indexer security configuration.

Question: What should I back up for Wazuh RBAC?

At minimum, identify and back up the RBAC configuration relevant to your deployment, including:

• Custom roles.
• Role mappings.
• Internal users.
• Security policies.
• Tenant configuration.
• Indexer security configuration.
• Dashboard security-related configuration.
• SSO mappings.
• Relevant API exports.

The exact files and configuration locations depend on the Wazuh version and authentication architecture.

Question: Where is Wazuh RBAC configuration stored?

Wazuh RBAC configuration can exist across multiple components.

The Wazuh Server API maintains its own RBAC-related configuration, while the Wazuh Indexer uses the OpenSearch Security plugin for its security roles, mappings, users, and related authorization configuration.

Therefore, there is not necessarily one single file that represents the entire Wazuh RBAC configuration.

Question: Can I export Wazuh RBAC roles?

Yes. Depending on the Wazuh component and version, RBAC information can be retrieved through supported API or security-management mechanisms.

API exports are particularly useful because they provide a representation of the effective security configuration that can be stored alongside filesystem backups.

Question: How do I backup Wazuh security roles?

Identify the roles used by your Wazuh deployment and export or copy the corresponding security configuration using the procedure appropriate for your Wazuh version.

For Indexer security, this can include the relevant roles.yml configuration.

Do not back up only the roles. Role mappings and associated permissions must also be preserved.

Question: How do I backup Wazuh role mappings?

For Indexer security, role mappings are commonly represented by roles_mapping.yml.

You should also preserve any Wazuh Server API or SSO configuration that determines how users are assigned to roles.

A role without its corresponding mapping may exist after restoration but never be assigned to the intended users.

Question: Can I automate Wazuh RBAC backups?

Yes. RBAC backups can be automated with shell scripts, scheduled jobs such as cron, enterprise backup systems, or configuration-management platforms.

An automated backup should ideally:

1. Collect the required configuration.
2. Export relevant API data.
3. Create a timestamped archive.
4. Generate a checksum.
5. Encrypt sensitive data.
6. Transfer it to separate storage.
7. Apply retention.
8. Report failures.

Question: How often should I backup Wazuh RBAC?

For an enterprise deployment, a daily backup is a reasonable baseline.

You should also create an immediate backup before significant changes such as:

• RBAC modifications.
• SSO changes.
• Tenant changes.
• Indexer security changes.
• Wazuh upgrades.
• Authentication-provider changes.

The more frequently RBAC changes, the more frequently you should capture backups.

Question: How do I restore Wazuh RBAC configurations?

The general process is:

1. Identify the correct backup.
2. Verify its integrity.
3. Back up the current configuration.
4. Prepare the Wazuh environment.
5. Restore the relevant configuration.
6. Apply the security configuration using the supported Wazuh procedure.
7. Restart affected services when required.
8. Test authentication.
9. Test role mappings.
10. Validate authorization and tenant access.

Avoid blindly copying configuration between production systems because Wazuh component versions, certificates, cluster topology, and authentication architecture can differ.

Question: Should I back up Wazuh RBAC before an upgrade?

Yes.

Create a known-good RBAC backup immediately before a Wazuh upgrade.

Also preserve the version information associated with the backup:

Backup:
2026-08-10-010000

Wazuh:
<version>

Indexer:
<version>

Dashboard:
<version>

This makes it easier to identify the correct recovery point if the upgrade changes authentication or authorization behavior.

Question: Can Wazuh RBAC backups be used on another Wazuh server?

They can be useful during migration or disaster recovery, but they should not automatically be treated as portable configuration packages.

Before restoring an RBAC backup to another server, verify:

• Wazuh version compatibility.
• Indexer version.
• Cluster topology.
• Certificates.
• Hostnames.
• Authentication providers.
• Tenant configuration.
• SSO settings.
• File paths.
• Security-plugin configuration.

A backup from one environment may contain environment-specific assumptions that are inappropriate on another system.

Question: How do I verify a Wazuh RBAC backup?

Use several validation methods.

Check that expected files exist:

tar -tzpf wazuh-rbac-backup.tar.gz

Generate and verify a checksum:

sha256sum wazuh-rbac-backup.tar.gz

Inspect exported roles and mappings and, most importantly, perform periodic test restorations.

The strongest verification is a successful restore into an isolated environment followed by authentication and authorization tests.

Question: How do I recover Wazuh RBAC after an Indexer failure?

First rebuild or replace the failed Indexer component using a compatible Wazuh/Indexer version and restore the required cluster configuration.

Then restore the appropriate Indexer security configuration, including relevant roles, role mappings, internal users, and tenant settings.

After applying the security configuration, verify:

• Indexer health.
• Administrator authentication.
• Role mappings.
• Tenant access.
• Dashboard functionality.
• Analyst permissions.
• Responder permissions.

Question: Are Wazuh RBAC backups sensitive?

Yes.

RBAC backups can contain sensitive security information such as:

• User information.
• Password hashes.
• Role definitions.
• Permission structures.
• Authentication configuration.
• SSO mappings.
• Certificates or references to credentials.
• Tenant information.

Treat RBAC backups as sensitive security artifacts.

Question: How should I secure Wazuh RBAC backup files?

Use multiple layers of protection:

• Restrict filesystem permissions.
• Encrypt backup archives.
• Encrypt transfers.
• Store backups on separate infrastructure.
• Protect encryption keys separately.
• Avoid hard-coded passwords in scripts.
• Limit backup-server access.
• Maintain offline or immutable copies.
• Monitor backup access.
• Apply defined retention policies.
• Periodically test restoration.

The backup itself should be protected with the same seriousness as the Wazuh security configuration it contains.

Conclusion

Backing up Wazuh RBAC is an important part of maintaining a recoverable Wazuh security architecture.

Roles, permissions, role mappings, internal users, tenants, and SSO configuration collectively determine who can access Wazuh and what they can do.

Losing that configuration can therefore create both operational disruption and security risk.

A reliable Wazuh RBAC backup strategy should capture the relevant configuration from every authorization layer, including the Wazuh Server API, Wazuh Indexer, Dashboard, and external authentication integrations where applicable.

The most effective approach is to:

• Back up RBAC configuration before major changes.
• Maintain versioned backups.
• Export important RBAC objects through supported interfaces.
• Protect backups with encryption and restrictive permissions.
• Store copies outside the Wazuh cluster.
• Automate recurring backups.
• Maintain offline or immutable copies.
• Verify backup integrity.
• Perform regular restoration tests.
• Document the complete recovery procedure.

Most importantly, do not consider a backup successful simply because an archive was created.

A known-good Wazuh RBAC backup is one that has been verified and successfully restored in a controlled environment.

By combining automated backups, secure storage, integrity verification, and periodic recovery testing, organizations can ensure that an Indexer failure, configuration mistake, failed upgrade, or other infrastructure incident does not permanently disrupt their Wazuh authorization model.