WAZUH SERVER MIGRATION

35 views
Skip to first unread message

wazuh user

unread,
Aug 5, 2026, 9:56:42 AM (5 days ago) Aug 5
to Wazuh | Mailing List
Hi Wazuh team,

I would like to seek for advice for wazuh digration,

currently our wazuh is running on all-in-one state where all wazuh instances resides in one VM. our plan is 

1. turn off the vm
2. create snapshot of the server
3. copy the snapshot to other DC
4. turn on the snapshot on the new dc

all of these will be executed while maintaining the IP of the wazuh server. this is to ensure that all agents are connected to the same server without needed to set new manager IP.

Based on this plan, what would you advice for us to include in the checklist for pre and post migration plan ? what should we validate working before we declare that the server in new dc has no problem ? i really need this team's advice on this since this is my first time managing wazuh server. Thankyou in advance for any input.

Regards,
Wazuh user

Olamilekan Abdullateef Ajani

unread,
Aug 5, 2026, 10:48:31 AM (5 days ago) Aug 5
to Wazuh | Mailing List
Hello,

My opinion, I believe this can work, especially since it is an all-in-one Wazuh server and you are keeping the same IP address.

The main things to note:

Make sure the old VM is fully powered off before starting the copy in the new DC. You do not want two Wazuh servers running with the same IP.
Confirm routing, gateway, VLAN, firewall rules, NAT, DNS, and any VPN path from agents.

For your checklist, I would include:

Before migration

Confirm Wazuh version.
Confirm server IP, gateway, DNS and hostname
Take VM snapshot while the VM is powered off.
Record disk usage and available space.
Confirm agents currently connected.
Export/save important config files.
Confirm firewall ports are allowed in the new DC

Things to also validate and check:
1514 - agent communication
1515 - agent enrollment, if used
Dashboard connection on 443, or the port if you changed the default.
9200 - indexer, if accessed internally

/var/ossec/bin/agent_control -lc
curl -k https://127.0.0.1:9200/_cluster/health?pretty
df -h
free -h
tail -f /var/ossec/logs/ossec.log
tail -f /var/ossec/logs/alerts/alerts.json

And look out for any errors.

You can also check the dashboard after migration for any pointers.

Agents are reconnecting.
New alerts are coming in.
Indexer health is green or yellow, not red.
No errors in ossec.log, Filebeat, or dashboard logs

Let it run for a few hours and confirm agents are reconnecting and new events are being indexed.

Lastly, keep the old VM powered off but available as part of your rollback plan until you are sure the new DC instance is stable.

wazuh user

unread,
Aug 6, 2026, 12:06:05 AM (5 days ago) Aug 6
to Wazuh | Mailing List
Hi Sir,

Thankyou for your opinion, if you dont mind, would you please elaborate further on " Export/save important config files.  " part?

I think this part is especially crucial for us since that would save me if anything happen to the servers.

I have take note on the other steps too. appreciate your advice on this part. Thankyou.

Regards,
Wazuh User

Olamilekan Abdullateef Ajani

unread,
Aug 6, 2026, 8:50:28 AM (4 days ago) Aug 6
to Wazuh | Mailing List
Hello,

When I said export/save important config files, I took the reference from the Wazuh back up guide.
Since your server is all-in-one, the VM snapshot is the main backup. But I will recommend a manual backup by exporting the important Wazuh config separately, just in case the VM restore has an issue or you need to rebuild manually.


Files like:
/var/ossec/etc/ossec.conf
/var/ossec/etc/client.keys
/var/ossec/etc/shared/
/var/ossec/etc/rules/
/var/ossec/etc/decoders/
/var/ossec/etc/lists/
/var/ossec/integrations/
/var/ossec/active-response/bin/
/etc/wazuh-indexer/
/etc/wazuh-dashboard/
/etc/filebeat/
/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml

You can take a cue from the documentation below:
https://documentation.wazuh.com/current/migration-guide/creating/wazuh-central-components.html

For your migration plan, keeping both the VM snapshot and the separate config backup as mentioned above is a good safety net, just incase one fails, you have something to fall back on.

Please let me know if you require further clarification on this.

Regards

Reply all
Reply to author
Forward
0 new messages