Colleagues, good afternoon!
I need help restoring my old logs after my server crashes. I performed a clean installation of the new components on the Wazuh 4.9.2 server. After that, I performed the data backup recovery according to these instructions. After that, I executed the specified script. Before that, I performed some optimization of Wazuh-Indxer in terms of JVM machine performance, and increased the size of the shards to 5,000 so that all my data for the previous 3 years would fit. The script worked correctly, as indicated on the website. After that, I deleted the /tmp/recovery file.json, deleted the line "- /tmp/recovery.json" from ".../manifest.yml" for Filebeat. I rebooted Filebeat.
I have a new server on Debian 12.\ The data is available in Discovery, and I can view it. But for some reason I can't see the Wazuh-Dashboard in other sections (TH, FIM, Vulnerability Detection, MITRE ATTACK, VirusTotal, and so on).
Hello,
Check the manager.name on the old log, I believe it is different on the old logs. As you can see, the scicky filter on the screenshot manager.name: Wazuh, Your old logs are not in the dashboard because of the filter.
You can change the manager name to the previous one by changing the hostname of the Wazuh manager server, and the old logs will be visible again on the dashboard.
hostnamectl set-hostname <hostname>
But the recent logs will be unavailable on the dashboard because of the different manager name.
The new logs will have the last configured manager.name(hostname).
We can change the manager name using the API tool per document, but cannot change it in bulk
POST /wazuh-alerts-4.x-2024.06.03/_update/<Document_ID>
{
"doc" : {
"manager": {
"name": "<new_name>"
}
}
}
Document ID:
Let me know if you need any further information on this.
Hello!
Yes, you are absolutely right. My previous server had HOSTNAME = 'Wazuh-Server'.
I have more than 1 million documents left in my previous logs over 3 years. Is it really only necessary to manually change the value for each one?
```Is there any way to reindex these documents? And where in general can I get to know this information in more detail.
The alerts are not showing in the Wazuh dashboard, but you can still access them from the Discover section.
If you have more alerts from previous with wazuh-Server manager name, you can change your server hostname to wazuh-Server, and all the alerts with wazuh-Server will map to your Wazuh dashboard, and the new alert will appear with the manager name wazuh-Server.
Now you can delete the index of the alerts with the manager name “wazuh” and restore them from the alerts.json.gz file.
Before restoring the alert, you need to write a script to change the manager name from “wazuh” to “wazuh-Server”
The script: unzip the log -> change the name from “wazuh” to “wazuh-Server”.-> zip again as alerts.json.gz file.
I believe you already have the document for restoring log, I am still shaing the document:
https://wazuh.com/blog/recover-your-data-using-wazuh-alert-backups/
I know it sounds a bit complex, but it is the only way to change the field value in bulk.
Hmm, I'll try this option!
Hello!
I tried to create a script using AI.
I checked its correctness. The result was good. All mentions of "Wazuh-Server" to "wazuh" have been changed in the corresponding files "*.log.gz " and "*.json.gz ". I checked it out. And indeed everything was as it should be.
But when I run the script "recovery.py ". For some reason, it only processes data from August 4, 2025 to August 22, 2025. It has not been processing data since 2024. It's like he doesn't see them.
Is there any other way to change the old logs without changing them on the existing Wazuh system?!
```
Make sure to adjust the time on the script.
Run this script without the nohup to see the output and identify the issue.
./recovery.py -eps 500 -min 2024-01-01T13:59:30 -max 2025-02-10T22:00:00 -o /tmp/recovery.json -log ./recovery.log -sz 2.5 &
As you are trying to restore a lot of logs at the same time. I will instead try to ingest all the logs at once you can restore logs month by month by adjusting the -min and -max in the script.
Also, I will suggest you check if you have enough storage on the manager and the indexer node.
Let me know the update on the issue.
Good afternoon!
Just to increase the capacity of the "Wazuh Indexer". I executed the commands listed in the documentation for "Wazuh". By configuring "Wazuh Indexer", I increased the number of valid SHARDS to 5,000 using DevTools in the "Wazuh Dashboard" → "Menu" → "Indexer menegement" panel.
Before that, the script was working properly, and it took 1.5 days for it to process all events from the old log files.
I still haven't figured out what the reason was, but it seems like the process has started.
I used this command:
As you have mentioned, -w "/root/wazuh_files_backup/2025-07-29_17:41/var/ossec" in the command, the script is looking for the json.gz file in
/root/wazuh_files_backup/2025-07-29_17:41/var/osseclogs/alerts/YEAR/MON/ directory
The log shows it cannot find the json.gz file in the mentioned path
2025-08-27 18:53:10 wazuh-reinjection: Couldn't find file /root/wazuh files backup/2025-07-29 17:41/var/osseclogs/alerts/2025/Jul/ossec-alerts-31.json.gz
2025-08-27 18:53:10 wazuh-reinjection: Couldn't find file /root/wazuh_files backup/2025-07-29 17:41/var/osseclogs/alerts/2025/Aug/ossec-alerts-01.json.gz
2025-08-27
18:53:10
wazuh-reinjection: Couldn't find file /root/wazuh_files_backup/2025-07-29_17:41/var/osseclogs/alerts/2025/Aug/ossec-alerts-02.json.gz
2025-08-27 18:53:10 wazuh-reinjection: Couldn't find file /root/wazuh_files_backup/2025-07-29 17:41/var/osseclogs/alerts/2025/Aug/ossec-alerts-03.json.gz
2025-08-27 18:53:10 wazuh-reinjection: Couldn't find file /root/wazuh files backup/2025-07-29 17:41/var/osseclogs/alerts/2025/Aug/ossec-alerts-04.json.qz
10
Make sure you have the json.gz file inside that folder.
Go to /root/wazuh_files_backup/2025-07-29_17:41/var/osseclogs/alerts/YEAR/MON/
Let me know if you need any further information.
Hello!
I have deleted this directory from the main server for now.
I will run the test on a separate virtual server. I am currently performing a backup from there to a separate target server.
I will repeat the tests on it. With the scripts that I used before. If it works, then I'll think about what the reason might be, and I'll share the information with you.
Hello.
Yes, indeed, the server name (hostname) affects the display of old logs in the system.
The second point...
I found a mistake... Most likely, I ran the script incorrectly "recovery.py ". I am currently restoring data from the backup server to the current working one. I will run scripts on it to change the fields "Wazuh-Server" to "wazuh". I'll run the script after that "recovery.py ".
I am waiting for the results of my actions.
Good afternoon!
The problem is solved. I did not specify the parameters correctly when running the script "Recovery.py ".
The script has now worked perfectly.
Performed all the necessary operations.
The data that was from previous logs is displayed correctly in the "Wazuh Dashboard" panels.
The script is reported to be working incorrectly here.