Every Wazuh deployment I have built eventually reaches the same conversation: what happens if this host dies?
The answer is usually "we have backups", followed by a pause when someone asks whether the indexer and the manager were backed up together, and whether anyone has restored them.
Why a script
A Wazuh deployment is not one thing. There is the Manager with its configuration, decoders and rules. There is the Indexer holding the data. There is the Dashboard with its saved objects and users. Back them up separately and you get a restore that almost works.
I wrote a script that treats them as one unit.
It does four things:
- Backs up the central components in a single run
- Keeps configuration and data together
- Writes a log of what happened, so a failed run is visible rather than silent
- Verifies checksums, so a truncated archive does not look like a good backup
What still matters after the script runs
A backup is only worth the restore you have tested. The script removes the excuse about doing it consistently. It does not remove the need to:
- Restore into a clean host once a quarter and confirm the manager starts, the indexer comes up, and the dashboard shows yesterday's data.
- Copy the archives off the host. A backup on the same disk as the database is a backup in name only.
- Keep the restore steps next to the backup, not in someone's head.
The script
Source and usage: github.com/enes-ismaili/wazuh-backup
There are companion scripts for restoring and for bulk upgrading, which is the other job nobody enjoys at 2am.
If you run Wazuh in production, the question worth answering this week is not whether you have a backup. It is when you last restored one.