How to Recover From a Malformed Database Image in wazuh-db

If you encounter the “database image malformed” error in wazuh-db, it usually means that one or more of Wazuh’s internal SQLite databases have become corrupted.

Because wazuh-db is responsible for storing and retrieving critical endpoint information, corruption can quickly affect multiple components across your Wazuh deployment.

Depending on which database is damaged, the symptoms can range from relatively minor inconsistencies to widespread monitoring failures.

Administrators may notice that agents stop updating their inventory, File Integrity Monitoring (FIM) results disappear, vulnerability detection stops producing findings, or the Wazuh manager fails to process certain events correctly.

In severe cases, agents remain connected but their metadata no longer updates, making it difficult to trust the information displayed in the Wazuh Dashboard.

The error itself originates from SQLite, the embedded database engine used by wazuh-db. SQLite reports “database disk image is malformed” whenever it detects structural corruption that prevents it from reading database pages safely.

Rather than continuing to operate on a damaged database and risking additional data loss, Wazuh surfaces the error so administrators can investigate and repair or rebuild the affected database.

Database corruption can occur for several reasons, including unexpected power failures, disk errors, abrupt system shutdowns, filesystem corruption, storage hardware failures, or processes being terminated while SQLite is writing changes to disk.

In this guide, you’ll learn how wazuh-db database image malformed errors occur, how to identify the affected database, how to verify whether corruption actually exists, and the safest recovery procedures.

We’ll also cover preventive best practices that reduce the likelihood of future database corruption and help keep your Wazuh deployment healthy.

Resource:

SQLite Database Corruption Documentation – https://www.sqlite.org/howtocorrupt.html

What Is wazuh-db?

The wazuh-db daemon is one of the core services within the Wazuh manager.

It acts as a high-performance database interface between other Wazuh components and the SQLite databases that store agent-related information.

Instead of every module interacting directly with SQLite files, modules communicate with wazuh-db, which manages database access, synchronization, and consistency.

This architecture improves performance while reducing contention between multiple Wazuh processes that need simultaneous access to agent data.

At its core, wazuh-db uses SQLite because it is lightweight, reliable, serverless, and well suited for local database operations.

Each agent maintains its own database containing operational information that various Wazuh modules continuously update.

How `wazuh-db` stores

These databases commonly store:

Agent metadata and registration information
File Integrity Monitoring (FIM) events and file state
Syscollector hardware and software inventory
Vulnerability Detection package information
Agent synchronization and state tracking data
Internal module metadata used by multiple Wazuh services

For example:

Syscollector continuously updates installed software, operating system information, running processes, network interfaces, and hardware inventory.
Vulnerability Detection compares collected package information against vulnerability feeds.
File Integrity Monitoring records monitored files and detects changes over time.
Other modules rely on the same databases to maintain agent state and synchronization.

Because so many Wazuh components depend on these SQLite databases, maintaining database integrity is essential.

Even a single corrupted database page can prevent modules from reading inventory data or writing new information, leading to cascading issues throughout the Wazuh platform.

Healthy databases allow:

Reliable event processing
Accurate asset inventories
Consistent vulnerability scanning
Stable File Integrity Monitoring
Proper synchronization between agents and the manager

Once corruption appears, administrators should treat it as a storage integrity issue rather than simply restarting services, since restarting alone rarely repairs damaged SQLite files.

Resources:

Wazuh Architecture Documentation – https://documentation.wazuh.com/current/getting-started/architecture.html

Related Guides:

What Does “database image malformed” Mean?

The error “database image malformed” is generated directly by SQLite when it detects corruption within the physical structure of a database file.

Rather than indicating an application bug in Wazuh itself, the message tells you that SQLite can no longer safely interpret part of the database.

Unlike traditional database servers, SQLite stores the entire database in a single file.

Every table, index, page, and metadata structure must remain internally consistent.

If SQLite discovers invalid page headers, broken indexes, corrupted B-tree structures, missing pages, or inconsistent checksums, it reports the database as malformed.

When wazuh-db attempts to query or update a corrupted database, SQLite returns an error similar to:

database disk image is malformed

Wazuh then records the failure in its logs because the requested operation cannot be completed successfully.

Difference between logical corruption and filesystem corruption

It is important to distinguish between logical database corruption and filesystem corruption.

Logical database corruption occurs when the SQLite file itself contains damaged structures.

This may result from interrupted writes, hardware failures, memory corruption, or software crashes during database updates.

Filesystem corruption, on the other hand, affects the storage layer beneath SQLite.

Problems such as bad sectors, damaged filesystems, failing SSDs, RAID issues, or kernel storage errors may corrupt multiple files, not just the SQLite database.

In these situations, simply rebuilding the database without addressing the underlying storage issue often results in recurring corruption.

Administrators frequently discover the problem while reviewing Wazuh manager logs.

Common log messages include:

wazuh-db: ERROR: database disk image is malformed

wazuh-db: ERROR: SQLite database query failed.

wazuh-db: ERROR: Cannot execute statement because the database is corrupted.

ossec-analysisd: WARNING: Failed to retrieve agent database information.

wazuh-modulesd: ERROR: Unable to update Syscollector inventory.

The exact messages vary depending on which Wazuh module is accessing the damaged database, but they generally point back to SQLite reporting corruption.

Whenever you see this error, avoid immediately deleting the database.

First determine whether the corruption is isolated to a single agent database or indicative of broader storage problems.

Checking filesystem health, disk SMART data, and system logs before rebuilding the database can prevent repeated failures caused by an underlying hardware issue.

Feature insight: The SQLite developers emphasize that SQLite database corruption is uncommon under normal operation and is most often associated with external factors such as faulty storage hardware, filesystem issues, incomplete writes caused by power loss, or application-level misuse.

Their guidance recommends identifying and eliminating the root cause before restoring or recreating the database to avoid repeated corruption.

Example log snippet

2026/07/09 11:14:08 wazuh-db: ERROR: database disk image is malformed
2026/07/09 11:14:08 wazuh-db: ERROR: Cannot execute SQL statement.
2026/07/09 11:14:08 wazuh-modulesd:syscollector: ERROR: Failed to update agent inventory.
2026/07/09 11:14:09 wazuh-db: INFO: Retrying database operation.
2026/07/09 11:14:09 wazuh-db: ERROR: database disk image is malformed

Resources:

SQLite “How To Corrupt Your Database Files” – https://www.sqlite.org/howtocorrupt.html

Common Symptoms

A malformed SQLite database can affect far more than a single Wazuh module.

Since wazuh-db serves as the storage layer for multiple services, corruption often causes seemingly unrelated issues throughout the deployment.

The exact symptoms depend on which database is damaged, but administrators typically observe one or more of the following.

Repeated “database image malformed” Errors in Logs

The most obvious symptom is the continuous appearance of SQLite corruption errors in the Wazuh manager logs.

Because various modules repeatedly attempt to read or write to the damaged database, the same error may be logged every few seconds or minutes.

Typical messages include:

database disk image is malformed
SQLite query failed
Cannot execute SQL statement
Database read error

If left unresolved, log files can grow rapidly due to repeated retries.

Failed Agent Synchronization

When agent databases become corrupted, synchronization between the agent and manager may no longer function correctly.

Symptoms include:

Agent information stops updating.
Configuration changes are not reflected.
Inventory synchronization stalls.
Agent status becomes inconsistent.

The agent may still appear connected while silently failing to synchronize important metadata.

Missing Inventory Data

Syscollector relies heavily on wazuh-db to store endpoint inventory.

A corrupted database can cause missing or incomplete:

Installed software
Operating system information
Running processes
Network interfaces
Hardware inventory
Installed packages

As a result, administrators may notice devices appearing only partially populated within the dashboard.

Related Guide: How to Monitor Linux Event Logs Using Wazuh

Vulnerability Detection Stops Updating

Vulnerability Detection depends on accurate Syscollector inventory.

If package information cannot be stored or retrieved, vulnerability scans may stop producing new findings.

Common symptoms include:

Old vulnerabilities remain indefinitely.
Newly installed software is never scanned.
No recent vulnerability data appears.
Scan timestamps stop updating.

This often leads administrators to believe the Vulnerability Detection module has failed, when the underlying issue is actually SQLite corruption.

File Integrity Monitoring (FIM) Inconsistencies

Because File Integrity Monitoring also stores metadata within agent databases, corruption may lead to:

Missing monitored files
Files disappearing from reports
Duplicate entries
Inconsistent change detection
Missing FIM alerts

In severe cases, FIM scans complete successfully but produce incomplete results.

High CPU Usage Caused by Repeated Retries

Many Wazuh modules continuously retry failed database operations.

Instead of failing once, they repeatedly:

Open the database
Execute SQL queries
Receive corruption errors
Retry again

This retry loop can cause wazuh-db to consume noticeably more CPU than normal.

If the corruption affects multiple databases simultaneously, CPU utilization may increase significantly.

Missing Data in the Wazuh Dashboard

Database corruption frequently appears as missing information rather than obvious error messages.

Administrators may observe:

Empty inventory pages
Missing vulnerability reports
Blank widgets
Incomplete agent details
Missing FIM history
Outdated statistics

Since the dashboard simply displays information stored by wazuh-db, corrupted databases often result in incomplete visualizations.

Unexpected Agent Behavior

Some agents continue sending events while others appear partially functional.

Examples include:

Agent remains connected but never updates inventory.
Configuration changes are ignored.
Event counts stop increasing.
Modules fail intermittently.
Agent information becomes stale.

Because corruption usually affects only specific SQLite databases, the resulting behavior can appear inconsistent and difficult to diagnose.

Common Causes

SQLite databases are designed to be extremely reliable, and corruption is relatively rare under normal operating conditions.

According to the SQLite development team, database corruption is almost always caused by external factors such as hardware failures, storage problems, interrupted writes, or improper handling of database files rather than defects in SQLite itself.

Understanding these root causes helps prevent future occurrences after the database has been repaired or rebuilt.

Unexpected Server Shutdowns

One of the most common causes is an unexpected interruption while SQLite is writing data.

Examples include:

Sudden power outages
Kernel panics
Forced system resets
Virtual machine crashes
Hypervisor failures
Accidental power cycling

Although SQLite uses journaling mechanisms to minimize corruption, no database engine can completely protect against storage failures occurring during critical write operations.

Disk Corruption

Underlying storage hardware problems frequently lead to malformed databases.

Examples include:

Bad sectors
SSD wear-out
HDD mechanical failures
RAID degradation
Controller failures
Unrecoverable read/write errors

If storage hardware begins returning corrupted data, SQLite eventually detects inconsistencies within the database pages.

Filesystem Problems

Filesystem corruption may damage SQLite databases even when the storage hardware itself is healthy.

Examples include:

Unclean filesystem shutdowns
Corrupted filesystem metadata
Mount failures
Journal replay errors
Filesystem inconsistencies after crashes

Before rebuilding databases, administrators should verify filesystem health to avoid recurring corruption.

Running Out of Disk Space

SQLite requires sufficient free space to complete transactions safely.

When disks become completely full, writes may terminate unexpectedly, resulting in:

Partial transactions
Incomplete journal files
Interrupted checkpoints
Damaged database pages

Monitoring disk utilization helps prevent this avoidable cause of corruption.

Memory or Hardware Errors

Faulty hardware can silently corrupt data before it reaches disk.

Potential causes include:

Defective RAM
Storage controller failures
Motherboard issues
CPU cache errors
DMA transfer problems

Enterprise deployments often use ECC memory to reduce the likelihood of silent memory corruption affecting databases.

Manual Modification of Database Files

SQLite databases should never be modified while wazuh-db is actively using them.

Risky actions include:

Editing databases directly with SQLite tools
Copying active database files without stopping Wazuh
Restoring incomplete backups
Replacing individual SQLite files
Manually deleting internal database objects

These operations can easily leave databases in an inconsistent state.

Interrupted Wazuh Upgrades

Database corruption occasionally appears after interrupted upgrades.

Possible causes include:

Upgrade failures
Unexpected reboot during migration
Package installation interruption
Service termination before migration completed

Whenever an upgrade fails unexpectedly, administrators should verify database integrity before restarting production workloads.

Related Guide: How to Upgrade a Wazuh Agent

Third-Party Backup or Antivirus Interference

Some backup products and antivirus software interact poorly with active SQLite databases.

Potential issues include:

File locking
Snapshot inconsistencies
Partial file copies
Real-time scanning interruptions
Aggressive file monitoring

Modern backup solutions that support application-consistent snapshots are generally safer than copying active database files directly.

How to Diagnose the Problem

Proper diagnosis should always precede recovery.

Although the error message clearly indicates SQLite corruption, administrators should determine which database is affected and whether the underlying cause is storage-related before attempting repairs.

Check wazuh-db Logs

Begin by reviewing the Wazuh manager logs.

On most Linux installations:

sudo grep -i "malformed" /var/ossec/logs/ossec.log

Or search for SQLite-related errors:

sudo grep -Ei "sqlite|database|wazuh-db" /var/ossec/logs/ossec.log

You can also monitor new messages in real time:

sudo tail -f /var/ossec/logs/ossec.log

Look for:

database image malformed
SQLite errors
SQL query failures
Agent database names
Module names reporting failures

These messages often identify the affected agent or database.

Identify the Corrupted SQLite Database

Once you’ve confirmed corruption, determine which database is failing.

Most Wazuh agent databases reside beneath:

/var/ossec/queue/db/

List the available databases:

sudo ls -lh /var/ossec/queue/db/

Depending on your deployment, you’ll typically find one SQLite database per registered agent.

Knowing which database corresponds to which endpoint allows you to determine whether the corruption affects:

A single agent
Multiple agents
Shared Wazuh data
System-wide inventory

If only one database is damaged, recovery is generally much simpler than if multiple databases are corrupted simultaneously.

Verify Database Integrity Using SQLite

SQLite includes a built-in integrity checker.

Run:

sqlite3 /path/to/database.db "PRAGMA integrity_check;"

A healthy database returns:

ok

A corrupted database may return messages such as:

*** in database main ***
Page 421 is never used
Malformed B-Tree
Row missing from index
Database disk image is malformed

Minor index corruption may sometimes be repairable, whereas extensive page corruption often requires rebuilding the database from backups or allowing Wazuh to recreate it after the affected data has been removed.

Check System Logs for Storage Errors

If SQLite reports corruption, verify that the operating system is not reporting storage problems.

Useful commands include:

dmesg | grep -Ei "error|I/O|ext4|xfs|nvme|disk"

journalctl -k

journalctl -p err

Look for:

I/O errors
Read failures
Write failures
Filesystem corruption
Device resets
Storage controller errors

Storage-related kernel messages often explain why the SQLite database became corrupted in the first place.

Verify Available Disk Space

Ensure the server has adequate free space.

Check filesystem utilization:

df -h

Also verify inode usage:

df -i

Pay particular attention to:

Nearly full partitions
100% disk usage
Exhausted inode counts
Rapid filesystem growth

Running out of either storage space or inodes can interrupt SQLite writes and contribute to database corruption.

Determine Whether Multiple Databases Are Affected

Finally, determine whether the problem is isolated or widespread.

For example, you can run integrity checks against multiple agent databases:

find /var/ossec/queue/db -name "*.db" -exec sqlite3 {} "PRAGMA integrity_check;" \;

If only one database reports corruption, recovery can usually focus on a single affected agent.

However, if many databases fail the integrity check, the root cause is more likely to be:

Filesystem corruption
Storage hardware failure
Faulty memory
An interrupted system-wide event
Backup or virtualization issues

Widespread corruption should always prompt a thorough investigation of the underlying infrastructure before rebuilding databases, otherwise newly created databases may become corrupted again shortly afterward.

How to Recover From a Malformed Database Image

After confirming that a SQLite database is corrupted, choose the recovery method that matches the severity of the problem.

Always create a backup of the affected database before making changes, even if it appears unrecoverable.

In some cases, specialized recovery tools may still be able to extract useful data.

It’s also important to investigate the root cause of the corruption before restoring or rebuilding the database.

Otherwise, the newly created database may become corrupted again.

Solution 1: Restart wazuh-db

If the error appeared only once, perhaps after a temporary filesystem issue or an interrupted startup, a simple restart of the Wazuh services may be sufficient.

A restart is most likely to help when:

The database itself is not actually corrupted.
The error occurred during service startup.
A temporary file lock prevented database access.
Storage issues have already been resolved.

Restart the Wazuh manager:

sudo systemctl restart wazuh-manager

Verify that the service started successfully:

sudo systemctl status wazuh-manager

Review the logs for any remaining SQLite errors:

sudo tail -f /var/ossec/logs/ossec.log

If “database image malformed” continues to appear after restarting, proceed to the next recovery option.

Solution 2: Restore the Database From Backup

Restoring a known-good backup is often the safest recovery method, particularly if the corruption is extensive.

Before restoring:

Identify the most recent healthy backup.
Verify that the backup completed successfully.
Confirm it predates the corruption.

Stop the Wazuh manager before replacing database files:

sudo systemctl stop wazuh-manager

Restore the affected SQLite database from your backup solution.

After restoration, verify the ownership:

sudo chown wazuh:wazuh /var/ossec/queue/db/<database>.db

Verify permissions:

sudo chmod 660 /var/ossec/queue/db/<database>.db

Restart the manager:

sudo systemctl start wazuh-manager

Using a validated backup typically results in the shortest recovery time while preserving historical data.

Solution 3: Rebuild the Corrupted Database

If no usable backup exists, rebuilding the database is often the most practical solution.

First, stop the manager:

sudo systemctl stop wazuh-manager

Locate the corrupted database.

Instead of deleting the entire database directory, remove only the affected SQLite file.

For example:

sudo rm /var/ossec/queue/db/<affected_database>.db

Restart Wazuh:

sudo systemctl start wazuh-manager

When the affected module begins collecting new information, wazuh-db automatically recreates the missing database.

Data that is typically regenerated automatically includes:

Agent metadata
Syscollector inventory
Running processes
Installed software
Network interfaces
Hardware inventory
File Integrity Monitoring state
Vulnerability scan data

However, historical information stored only in the deleted database may be temporarily unavailable until new scans complete.

For example:

Historical inventory snapshots
Previous FIM records
Older vulnerability results

The exact recovery time depends on how frequently your agents perform inventory collection and scheduled scans.

Solution 4: Recover Data Using SQLite Dump

If the database is only partially corrupted, SQLite may still be able to recover a significant portion of the data.

Attempt to export the database contents:

sqlite3 corrupted.db ".dump" > recovered.sql

Create a new database:

sqlite3 recovered.db

Import the recovered records:

sqlite3 recovered.db < recovered.sql

After rebuilding the database, verify its integrity:

sqlite3 recovered.db "PRAGMA integrity_check;"

If the integrity check returns:

ok

the recovered database can often be used in place of the corrupted one.

Be aware that heavily damaged databases may lose some records during the export process, but partial recovery is often preferable to rebuilding everything from scratch.

SQLite Recovery Documentation – https://www.sqlite.org/recovery.html

Solution 5: Re-register the Affected Agent (If Necessary)

Occasionally, rebuilding the SQLite database resolves the corruption but the affected agent still fails to synchronize correctly.

Symptoms include:

Inventory never updates.
Vulnerability Detection remains empty.
Agent status appears inconsistent.
Synchronization errors continue.

In these situations, removing and re-registering the agent may resolve stale synchronization metadata.

The general process is:

Remove the affected agent from the Wazuh manager.
Delete the local agent configuration if necessary.
Register the agent again.
Restart the agent service.
Confirm successful communication.

After re-registration, verify that new inventory and events begin appearing.

Related Guides:

Solution 6: Repair Filesystem Errors

If multiple databases become corrupted or corruption reappears after rebuilding, the problem may lie with the underlying filesystem.

Before attempting repairs:

Back up important data.
Schedule downtime if required.
Unmount the affected filesystem whenever possible.

Depending on the filesystem, common repair utilities include:

fsck

or filesystem-specific tools such as:

xfs_repair
e2fsck

After repairs:

Reboot the server if recommended.
Verify filesystem health.
Recheck SQLite integrity.
Restart Wazuh services.

Repairing filesystem issues before rebuilding databases helps prevent recurring corruption.

Solution 7: Replace Failing Storage Hardware

If SMART errors, bad sectors, or controller failures are detected, replacing the storage device is usually the only long-term solution.

Warning signs include:

Increasing reallocated sectors
Read/write failures
Kernel I/O errors
Frequent filesystem corruption
SMART failures
Unrecoverable media errors

Recommended recovery process:

Replace the failing drive.
Reinstall or restore the operating system if necessary.
Restore Wazuh data from backups.
Verify database integrity.
Monitor the system closely for additional storage errors.

Attempting to continue operating on failing storage often leads to repeated database corruption and additional data loss.

Verify the Recovery

After completing the recovery process, verify that Wazuh has returned to normal operation before considering the issue resolved.

Confirm wazuh-db Starts Successfully

Begin by confirming that the Wazuh manager starts without database errors.

Check the service status:

sudo systemctl status wazuh-manager

Review the logs:

sudo tail -100 /var/ossec/logs/ossec.log

You should no longer see recurring messages such as:

database disk image is malformed

or other SQLite-related errors.

Verify Agent Synchronization

Next, confirm that affected agents are communicating normally.

Verify:

Agent status is active.
Inventory updates resume.
Agent synchronization timestamps update.
No synchronization errors appear in the logs.

If synchronization still fails after rebuilding the database, consider re-registering the affected agent.

Confirm Inventory and Vulnerability Data Returns

After recovery, allow sufficient time for agents to perform scheduled scans.

Verify that:

Syscollector inventory repopulates.
Installed software appears.
Hardware information returns.
Vulnerability Detection resumes producing findings.
File Integrity Monitoring records new events.

Depending on scan intervals and the number of monitored endpoints, complete repopulation may take several minutes or longer.

Related Guides:

Validate Database Integrity Again

Finally, rerun SQLite’s integrity check against the recovered database:

sqlite3 /path/to/database.db "PRAGMA integrity_check;"

A successful recovery should return:

ok

Continue monitoring the logs over the next several hours.

If corruption reappears, investigate the underlying storage subsystem rather than repeatedly rebuilding the database.

Preventing Future Database Corruption

Although SQLite corruption is uncommon, following a few operational best practices can significantly reduce the risk of future database failures.

Schedule Regular Backups

The fastest recovery is restoring a recent, verified backup.

A good backup strategy should include:

Regular automated backups
Version retention
Off-site or immutable copies
Periodic restoration testing

Backups should be validated routinely to ensure they are usable during an actual recovery.

Use Reliable Storage

Storage quality directly impacts database reliability.

For production Wazuh deployments, consider:

Enterprise-grade SSDs
Redundant storage where appropriate (such as RAID 1 or RAID 10)
Reliable storage controllers
ECC memory on critical systems

These technologies reduce the likelihood of silent data corruption and hardware-related failures.

Monitor Disk Health

Storage problems often develop gradually before causing database corruption.

Monitor:

SMART attributes
Reallocated sectors
Wear levels
Read/write error counts
Device temperatures

Automated monitoring and alerting allow administrators to replace failing drives before data loss occurs.

smartmontools Documentation – https://www.smartmontools.org/

Prevent Unexpected Shutdowns

Unexpected power loss is one of the leading causes of interrupted database writes.

Reduce the risk by implementing:

Uninterruptible Power Supply (UPS) systems
Graceful shutdown procedures
Reliable virtualization infrastructure
Controlled maintenance windows

These practices help ensure SQLite transactions complete successfully.

Keep Adequate Free Disk Space

Running out of disk space can interrupt active database transactions.

Monitor:

Filesystem utilization
Inode consumption
Log growth
Database growth

Configure log rotation and storage alerts so disks never reach critical capacity.

Related Guide: How to Configure Wazuh Log Retention

Avoid Manual Database Editing

Directly modifying active SQLite databases is strongly discouraged.

Instead:

Use supported Wazuh management tools.
Stop services before restoring databases.
Avoid copying live database files.
Never edit production SQLite files while wazuh-db is running.

Following supported maintenance procedures minimizes the risk of introducing corruption.

Keep Wazuh Updated

Regular updates provide stability improvements, bug fixes, and compatibility enhancements across the Wazuh platform.

Keeping Wazuh current also ensures you’re using recent versions of bundled components and benefiting from ongoing reliability improvements.

Related Guide: How to Upgrade a Wazuh Agent

Monitor System Logs Proactively

Many storage and filesystem issues generate warning messages long before they result in database corruption.

Regularly review:

Kernel logs
Filesystem warnings
SMART alerts
Wazuh manager logs
Hardware event logs

Early detection enables administrators to replace failing hardware or repair storage issues before SQLite databases are affected, reducing both downtime and the risk of data loss.

Best Practices for Maintaining Healthy wazuh-db Databases

Preventing SQLite database corruption is far easier than recovering from it.

While wazuh-db is designed to be highly reliable, adopting a proactive maintenance strategy can significantly reduce downtime and improve the overall stability of your Wazuh deployment.

Perform Routine Integrity Checks

SQLite includes built-in tools for detecting corruption before it causes widespread problems.

Periodically run integrity checks on important databases using:

sqlite3 /path/to/database.db "PRAGMA integrity_check;"

For large environments, consider automating these checks during scheduled maintenance windows and logging the results for future reference.

Routine integrity verification helps detect problems early, allowing you to repair or restore affected databases before multiple Wazuh components begin failing.

Monitor Database Growth

Agent databases naturally increase in size as inventory data, File Integrity Monitoring events, and other metadata accumulate.

Unexpected database growth may indicate:

Excessive File Integrity Monitoring activity
Large software inventories
Duplicate data collection
Configuration issues
Runaway processes

Track database sizes over time and investigate sudden changes. Monitoring growth trends can also help with capacity planning and storage allocation.

Implement Backup Verification

Creating backups is only part of an effective disaster recovery strategy.

Backups should also be verified to ensure they can actually be restored.

A good verification process includes:

Confirming backup completion
Validating backup integrity
Performing periodic restoration tests
Maintaining multiple recovery points

Organizations often discover backup problems only during an emergency, making routine verification essential.

Test Recovery Procedures Regularly

Recovery documentation is most valuable when it has been tested.

Schedule periodic recovery exercises that simulate:

Database corruption
Hardware failures
Filesystem damage
Complete server restoration

Testing recovery procedures helps administrators:

Reduce recovery time objectives (RTO)
Validate documentation
Identify missing dependencies
Improve operational readiness

Recovery testing is a widely recommended practice in disaster recovery planning because it exposes gaps before a real outage occurs.

Monitor Hardware Health

Storage hardware often provides warning signs long before failure.

Regularly monitor:

SMART attributes
SSD wear levels
Reallocated sectors
Pending sector counts
Controller errors
RAID health

Configure automated alerts so deteriorating hardware can be replaced before it corrupts production databases.

smartmontools Documentation – https://www.smartmontools.org/

Use Stable Filesystems

The reliability of SQLite databases depends heavily on the underlying filesystem.

For production deployments:

Keep filesystems healthy.
Run filesystem checks after unclean shutdowns when appropriate.
Follow vendor recommendations for your filesystem.
Avoid experimental storage configurations in production.

Using mature, well-maintained filesystems reduces the likelihood of corruption caused by storage-layer issues.

Protect Against Power Loss

Unexpected shutdowns remain one of the leading causes of interrupted database writes.

Reduce risk by implementing:

Uninterruptible Power Supply (UPS) systems
Graceful shutdown automation
Reliable virtualization platforms
Redundant power supplies where appropriate

These safeguards help ensure active SQLite transactions complete successfully.

Maintain Consistent Upgrade Procedures

Many database issues occur during interrupted or incomplete upgrades.

Follow a consistent upgrade process:

Back up databases before upgrades.
Review release notes.
Verify sufficient disk space.
Complete upgrades during maintenance windows.
Validate services after restarting.
Confirm database integrity following major upgrades.

Carefully planned upgrades reduce the risk of incomplete migrations and unexpected database inconsistencies.

Frequently Asked Questions (FAQ)

Question: What causes the “database image malformed” error in wazuh-db?

This error is generated by SQLite when it detects structural corruption within a database file.

Common causes include unexpected power failures, filesystem corruption, failing storage devices, interrupted database writes, hardware errors, incomplete upgrades, and improper manual handling of active SQLite databases.

According to the SQLite developers, corruption is typically caused by external factors rather than bugs in SQLite itself.

Question: Can a corrupted Wazuh SQLite database be repaired?

Sometimes. Minor corruption may be recoverable using SQLite’s recovery features or by exporting recoverable records with the .dump command and importing them into a new database.

However, severely damaged databases often require restoration from backup or complete rebuilding.

The success of any repair depends on how extensive the corruption is.

Question: Is it safe to delete a corrupted Wazuh database?

Yes, but only after confirming that the affected database can be safely recreated and after stopping the Wazuh manager.

In many cases, Wazuh automatically rebuilds missing agent databases as agents reconnect and modules such as Syscollector and File Integrity Monitoring collect new information.

However, deleting the wrong database or removing multiple databases unnecessarily can result in avoidable data loss, so always identify the affected file first.

Question: Will rebuilding the database cause data loss?

Rebuilding a database generally removes historical information stored within that database.

After rebuilding, Wazuh typically regenerates:

Agent metadata
Software inventory
Hardware inventory
Running processes
Network interfaces
Vulnerability information
File Integrity Monitoring state

Historical records that were not backed up may be permanently lost until new data is collected.

Question: How do I identify which agent database is corrupted?

Start by reviewing /var/ossec/logs/ossec.log for SQLite error messages. These logs often identify the affected database or agent.

Next, run PRAGMA integrity_check against individual SQLite databases to determine which ones report corruption.

This approach helps distinguish an isolated problem from widespread storage issues.

Question: Can hardware problems cause SQLite corruption?

Yes. Faulty SSDs, failing hard drives, storage controller issues, defective RAM, and filesystem corruption are among the most common causes of SQLite database damage.

If multiple databases become corrupted or corruption returns after rebuilding, investigate the underlying hardware before recreating additional databases.

Question: How can I prevent future database corruption in Wazuh?

The most effective preventive measures include:

Maintaining verified backups
Monitoring SMART and storage health
Preventing unexpected shutdowns
Keeping adequate free disk space
Avoiding manual modification of active SQLite databases
Monitoring Wazuh logs for early warning signs
Following consistent upgrade procedures

Together, these practices significantly reduce the likelihood of future corruption.

Question: Should I restore from backup or rebuild the database?

If a recent, verified backup is available, restoring it is generally the preferred option because it preserves historical data and typically results in the fastest recovery.

If no usable backup exists, rebuilding the affected database allows Wazuh to regenerate operational data as agents report back.

Before choosing either option, ensure that any underlying storage or filesystem issues have been resolved to avoid recurring corruption.

Conclusion

The wazuh-db database image malformed error is a strong indicator that one or more SQLite databases used by Wazuh have become corrupted.

Although the issue can interrupt agent synchronization, inventory collection, File Integrity Monitoring, vulnerability detection, and other core functions, it is usually recoverable when approached methodically.

The first step is always to identify which database is affected and determine whether the corruption is isolated or the result of a broader storage problem.

Reviewing Wazuh logs, running SQLite integrity checks, examining filesystem health, and checking for hardware errors provide the information needed to choose the most appropriate recovery method.

In many cases, the issue can be resolved by restoring a recent backup, rebuilding the affected database, or recovering usable records with SQLite’s recovery tools.

If corruption is caused by failing hardware or filesystem damage, addressing those underlying issues is essential before restoring production databases.

Finally, the best defense against future corruption is a proactive maintenance strategy.

Regular backups, periodic integrity checks, storage health monitoring, verified recovery procedures, and consistent upgrade practices help ensure your wazuh-db databases remain healthy and your Wazuh deployment continues to provide reliable security monitoring with minimal downtime.

How to Recover From a Malformed Database Image in wazuh-db

What Is wazuh-db?

How wazuh-db stores

What Does “database image malformed” Mean?

Difference between logical corruption and filesystem corruption

Common Symptoms

Repeated “database image malformed” Errors in Logs

Failed Agent Synchronization

Missing Inventory Data

Vulnerability Detection Stops Updating

File Integrity Monitoring (FIM) Inconsistencies

High CPU Usage Caused by Repeated Retries

Missing Data in the Wazuh Dashboard

Unexpected Agent Behavior

Common Causes

Unexpected Server Shutdowns

Disk Corruption

Filesystem Problems

Running Out of Disk Space

Memory or Hardware Errors

Manual Modification of Database Files

Interrupted Wazuh Upgrades

Third-Party Backup or Antivirus Interference

How to Diagnose the Problem

Check wazuh-db Logs

Identify the Corrupted SQLite Database

Verify Database Integrity Using SQLite

Check System Logs for Storage Errors

Verify Available Disk Space

Determine Whether Multiple Databases Are Affected

Be First to Comment

Leave a Reply Cancel reply

How `wazuh-db` stores