Wazuh Migration From Older Machine to A Newer Setup

[John Carry]

Dear Wazuh Team,
We are currently facing issues with Older Hardware that is  Hosting Wazuh Production, and now we are planning to install a dedicated new wazuh installation on a new hardware, but we are looking for the steps, backups and the procedure required that would help us to align our fresh wazuh deployment to import and reflect Older wazuh data including Rules, Dashboards, Ossec Configuration , Open Distro elastic instance etc .

Please be noted that we just need to Migrate our Older Wazuh overall data to new instance of Wazuh that is a fresh installed.

 I would request you to please provide detailed steps in an ordered way to successfully complete the activity.

Our Deployment Architecture:
Wazuh All-in-One ( Wazuh , Kibana, Open Distro)

[John Carry]

To conclude, We Need to ensure that Our Old Wazuh Setup's Dashboard, Custom rules, Decoders, Custom scripts, Configuration and Most importantly the storage i-e Elastic should migrate to the new Wazuh Setup (Which is a fresh Installation of Wazuh).

[John Carry]

Dear Wazuh Team,
Can we have the Update please?

[John Carry]

Dear Wazuh Team,
Please respond.

[Olusegun Adenrele Oyebo]

Dear John,

Thank you for using Wazuh and sorry for the late reply.

Dear John,

Thank you for reaching Wazuh and reaching out to us.

Kindly find summary of steps below for backup and restore of wazuh files to a new server:

BACKUPS:

Wazuh manager server:

• Create the destination folder to store the files. For version control, add the date and time of the backup to the name of the folder:

            bkp_folder=~/wazuh_files_backup/$(date +%F_%H:%M)
            mkdir -p $bkp_folder && echo $bkp_folder

• Save the host information:

           cat /etc/*release* > $bkp_folder/host-info.txt
           echo -e "\n$(hostname): $(hostname -I)" >> $bkp_folder/host-info.txt

• Back up the Wazuh server data and configuration files as described below:

           rsync -aREz \
           /etc/filebeat/ \
           /etc/postfix/ \
           /var/ossec/api/configuration/ \
           /var/ossec/etc/client.keys \
          /var/ossec/etc/sslmanager* \
          /var/ossec/etc/ossec.conf \
          /var/ossec/etc/internal_options.conf \
          /var/ossec/etc/local_internal_options.conf \
          /var/ossec/etc/rules/local_rules.xml \
          /var/ossec/etc/decoders/local_decoder.xml \
          /var/ossec/etc/shared/ \
          /var/ossec/logs/ \
          /var/ossec/queue/agentless/ \
         /var/ossec/queue/agents-timestamp \
         /var/ossec/queue/fts/ \
         /var/ossec/queue/rids/ \
         /var/ossec/stats/ \
         /var/ossec/var/multigroups/ $bkp_folder

• If present, back up certificates and additional configuration files:

           rsync -aREz \
           /var/ossec/etc/*.pem \
           /var/ossec/etc/authd.pass $bkp_folder

• Backup your custom files. If you have custom active responses, CDB lists, integrations, or wodles, kindly adapt the below commands accordingly:

           rsync -aREz \
          /var/ossec/active-response/bin/<custom_AR_script> \
          /var/ossec/etc/lists/<user_cdb_list>.cdb \
          /var/ossec/integrations/<custom_integration_script> \
          /var/ossec/wodles/<custom_wodle_script> $bkp_folder
Replace <custom_AR_script> with the  name of the AR script, <user_cdb_list> with the name of the cdb list, <custom_integration_script> with the name of the integration script and <custom_wodle_script> with the name if the wodle script.

• Stop the wazuh manager service to prevent modification attempts while copying the Wazuh databases.

           systemctl stop wazuh-manager

• Back up the Wazuh databases as they hold collected data from the agents.

           rsync -aREz \
           /var/ossec/queue/db/ $bkp_folder

• Start the Wazuh manager service

           systemctl start wazuh-manager


Elasticsearch:

• Back up the elasticsearch certificates and configuration files:

           rsync -aREz \
           /etc/elasticsearch/certs/ \
          /etc/elasticsearch/jvm.options \
          /etc/elasticsearch/jvm.options.d \
          /etc/elasticsearch/log4j2.properties \
         /etc/elasticsearch/elasticsearch.yml \
         /etc/elasticsearch/elasticsearch.keystore \
         /etc/elasticsearch/elasticsearch-plugins.example.yml \
         /etc/elasticsearch/role_mapping.yml \
         /etc/elasticsearch/roles.yml \
        /etc/elasticsearch/users \
       /etc/elasticsearch/users_roles \
       /usr/lib/sysctl.d/elasticsearch.conf $bkp_folder

  Kibana:

• Back up the Wazuh dashboard certificates and configuration files:

           rsync -aREz \
           /etc/kibana/certs/ \
           /etc/kibana/kibana.yml \
           /etc/kibana/kibana.keystore \
           /etc/kibana/node.options \
           /usr/share/kibana/data/wazuh/config/wazuh.yml \
           /usr/share/kibana/data/wazuh/config/wazuh-registry.json $bkp_folder

• Additional Kibana files backup (if present):

           rsync -aREz \
           /usr/share/kibana/data/wazuh/downloads \
           /usr/share/kibana/plugins/wazuh/public/assets/custom/images $bkp_folder

• Checking the backup:

           Check and verify that the Wazuh manager is active and list all the backed up files respectively with the commands below:
           systemctl status wazuh-manager

        find $bkp_folder -type f | sed "s|$bkp_folder/||" | less


Migrating to a new server.

Note: You need to make sure you have a new installation of Wazuh. You can use the guide to perform a fresh installation of the central components on the new server.

• Compress the files generated after performing Wazuh files backup and transfer them to the new server:

           tar -cvzf wazuh_central_components.tar.gz ~/wazuh_files_backup/

• Move the compressed file to the root / directory of your node:

           mv wazuh_central_components.tar.gz /
           cd /

• Decompress the backup files and change the current working directory to the directory based on the date and time of the backup files:

           tar -xzvf wazuh_central_components.tar.gz
           cd ~/wazuh_files_backup/<DATE_TIME>

Restoring Elasticsearch files:

• Stop the elasticsearch to prevent any modifications to the elasticsearch files during the restoration process:

           systemctl stop elasticsearch

• Restore the elasticsearch configuration files and change the file permissions and ownerships accordingly:

           sudo cp etc/elasticsearch/jvm.options /etc/elasticsearch/jvm.options
           chown elasticsearch:elasticsearch /etc/elasticsearch/jvm.options
           sudo cp -r etc/elasticsearch/jvm.options.d/* /etc/elasticsearch/jvm.options.d/
           chown elasticsearch:elasticsearch /etc/elasticsearch/jvm.options.d
           sudo cp etc/elasticsearch/log4j2.properties /etc/elasticsearch/log4j2.properties
           chown elasticsearch:elasticsearch /etc/elasticsearch/log4j2.properties
           sudo cp etc/elasticsearch/elasticsearch.yml /etc/elasticsearch/elasticsearch.yml
           chown elasticsearch:elasticsearch /etc/elasticsearch/elasticsearch.yml
           sudo cp etc/elasticsearch/elasticsearch.keystore /etc/elasticsearch/elasticsearch.keystore
           chown elasticsearch:elasticsearch /etc/elasticsearch/elasticsearch.keystore
           sudo cp etc/elasticsearch/elasticsearch-plugins.example.yml /etc/elasticsearch/elasticsearch-plugins.example.yml
          chown elasticsearch:elasticsearch /etc/elasticsearch/elasticsearch-plugins.example.yml
          sudo cp etc/elasticsearch/elasticsearch-plugins.example.yml /etc/elasticsearch/elasticsearch-plugins.example.yml
          chown elasticsearch:elasticsearch /etc/elasticsearch/elasticsearch-plugins.example.yml
          sudo cp etc/elasticsearch/role_mapping.yml /etc/elasticsearch/role_mapping.yml
          chown elasticsearch:elasticsearch /etc/elasticsearch/role_mapping.yml
          sudo cp etc/elasticsearch/roles.yml /etc/elasticsearch/roles.yml
          chown elasticsearch:elasticsearch /etc/elasticsearch/roles.yml
          sudo cp etc/elasticsearch/users /etc/elasticsearch/users
          chown elasticsearch:elasticsearch /etc/elasticsearch/users
          sudo cp etc/elasticsearch/users_roles /etc/elasticsearch/users_roles
          chown elasticsearch:elasticsearch /etc/elasticsearch/users_roles
          sudo cp usr/lib/sysctl.d/elasticsearch.conf /usr/lib/sysctl.d/elasticsearch.conf

• Start the elasticsearch service:

           systemctl start elasticsearch

Restoring Wazuh server files:

• Stop the Wazuh manager and Filebeat to prevent any modification to the Wazuh server files during the restore process:

           systemctl stop filebeat
           systemctl stop wazuh-manager

• Copy the Wazuh server data and configuration files, and change the file permissions and ownerships accordingly:

           sudo cp etc/filebeat/filebeat.reference.yml /etc/filebeat/
           sudo cp etc/filebeat/fields.yml /etc/filebeat/
           sudo cp -r etc/filebeat/modules.d/* /etc/filebeat/modules.d/
           sudo cp -r etc/postfix/* /etc/postfix/
           sudo cp var/ossec/etc/client.keys /var/ossec/etc/
           chown root:wazuh /var/ossec/etc/client.keys
           sudo cp -r var/ossec/etc/sslmanager* /var/ossec/etc/
           sudo cp var/ossec/etc/ossec.conf /var/ossec/etc/
           chown root:wazuh /var/ossec/etc/ossec.conf
           sudo cp var/ossec/etc/internal_options.conf /var/ossec/etc/
           chown root:wazuh /var/ossec/etc/internal_options.conf
           sudo cp var/ossec/etc/local_internal_options.conf /var/ossec/etc/
           chown root:wazuh /var/ossec/etc/local_internal_options.conf
           sudo cp -r var/ossec/etc/rules/* /var/ossec/etc/rules/
           chown -R wazuh:wazuh /var/ossec/etc/rules/
           sudo cp -r var/ossec/etc/decoders/* /var/ossec/etc/decoders
           chown -R wazuh:wazuh /var/ossec/etc/decoders/
           sudo cp -r var/ossec/etc/shared/* /var/ossec/etc/shared/
           chown -R wazuh:wazuh /var/ossec/etc/shared/
           chown root:wazuh /var/ossec/etc/shared/ar.conf
           sudo cp -r var/ossec/logs/* /var/ossec/logs/
           chown -R wazuh:wazuh /var/ossec/logs/
           sudo cp -r var/ossec/queue/agentless/*  /var/ossec/queue/agentless/
          chown -R wazuh:wazuh /var/ossec/queue/agentless/
          sudo cp var/ossec/queue/agents-timestamp /var/ossec/queue/
          chown root:wazuh /var/ossec/queue/agents-timestamp
          sudo cp -r var/ossec/queue/fts/* /var/ossec/queue/fts/
          chown -R wazuh:wazuh /var/ossec/queue/fts/
          sudo cp -r var/ossec/queue/rids/* /var/ossec/queue/rids/
          chown -R wazuh:wazuh /var/ossec/queue/rids/
          sudo cp -r var/ossec/stats/* /var/ossec/stats/
          chown -R wazuh:wazuh /var/ossec/stats/
          sudo cp -r var/ossec/var/multigroups/* /var/ossec/var/multigroups/
          chown -R wazuh:wazuh /var/ossec/var/multigroups/

• Restore certificates for Wazuh agent and Wazuh server communication, and additional configuration files if present:

          sudo cp -r var/ossec/etc/*.pem /var/ossec/etc/
          chown -R root:wazuh /var/ossec/etc/*.pem
          sudo cp var/ossec/etc/authd.pass /var/ossec/etc/
          chown -R root:wazuh /var/ossec/etc/authd.pass

• Restore your custom files. If you have custom active response scripts, CDB lists, integrations, or wodles, adapt the following commands accordingly:

           sudo cp var/ossec/active-response/bin/<CUSTOM_ACTIVE_RESPONSE_SCRIPT> /var/ossec/active-response/bin/
           chown root:wazuh /var/ossec/active-response/bin/<CUSTOM_ACTIVE_RESPONSE_SCRIPT>
           sudo cp var/ossec/etc/lists/<USER_CDB_LIST>.cdb /var/ossec/etc/lists/
          chown root:wazuh /var/ossec/etc/lists/<USER_CDB_LIST>.cdb
          sudo cp var/ossec/integrations/<CUSTOM_INTEGRATION_SCRIPT> /var/ossec/integrations/
          chown root:wazuh /var/ossec/integrations/<CUSTOM_INTEGRATION_SCRIPT>
          sudo cp var/ossec/wodles/<CUSTOM_WODLE_SCRIPT> /var/ossec/wodles/
          chown root:wazuh /var/ossec/wodles/<CUSTOM_WODLE_SCRIPT>

• Restore the Wazuh databases that contain collected data from the Wazuh agents:

           sudo cp var/ossec/queue/db/* /var/ossec/queue/db/
           chown -R wazuh:wazuh /var/ossec/queue/db/

• Start the Wazuh filebeat and Wazuh manager service respectively:

           systemctl start filebeat
           systemctl start wazuh-manager


Restoring Kibana files:
Perform the following steps to restore Wazuh reports and custom images on the new server if you have any from your backup.

• Restore your Wazuh reports using the following command:

           mkdir -p /usr/share/kibana/data/wazuh/downloads/reports/
           sudo cp -r usr/share/kibana/data/wazuh/downloads/reports/* /usr/share/kibana/data/wazuh/downloads/reports/
           chown -R kibana:kibana /usr/share/kibana/data/wazuh/downloads/

Navigate to Settings > Configuration > Custom branding from the Kibana dashboard and upload your custom images


Restoring old logs:
Wazuh, by default, compresses logs that are older than a day. While performing old log restoration in the Restoring Wazuh server files section, the old logs remain compressed.

Perform the following actions on your Wazuh server to decompress these logs and index them in the new Elasticsearch:

• Create a Python script called recovery.py on your Wazuh server. This script decompresses all the old logs and stores them in the recovery.py file in the /tmp directory:

           touch recovery.py

• Add the following content to the recovery.py script:

       #!/usr/bin/env python

import gzip
import time
import json
import argparse
import re
import os
from datetime import datetime
from datetime import timedelta

def log(msg):
    now_date = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
    final_msg = "{0} wazuh-reinjection: {1}".format(now_date, msg)
    print(final_msg)
    if log_file:
        f_log.write(final_msg + "\n")

EPS_MAX = 400
wazuh_path = '/var/ossec/'
max_size=1
log_file = None

parser = argparse.ArgumentParser(description='Reinjection script')
parser.add_argument('-eps','--eps', metavar='eps', type=int, required = False, help='Events per second.')
parser.add_argument('-min', '--min_timestamp', metavar='min_timestamp', type=str, required = True, help='Min timestamp. Example: 2017-12-13T23:59:06')
parser.add_argument('-max', '--max_timestamp', metavar='max_timestamp', type=str, required = True, help='Max timestamp. Example: 2017-12-13T23:59:06')
parser.add_argument('-o', '--output_file', metavar='output_file', type=str, required = True, help='Output filename.')
parser.add_argument('-log', '--log_file', metavar='log_file', type=str, required = False, help='Logs output')
parser.add_argument('-w', '--wazuh_path', metavar='wazuh_path', type=str, required = False, help='Path to Wazuh. By default:/var/ossec/')
parser.add_argument('-sz', '--max_size', metavar='max_size', type=float, required = False, help='Max output file size in Gb. Default: 1Gb. Example: 2.5')

args = parser.parse_args()

if args.log_file:
    log_file = args.log_file
    f_log = open(log_file, 'a+')


if args.max_size:
    max_size = args.max_size

if args.wazuh_path:
    wazuh_path = args.wazuh_path

output_file = args.output_file

#Gb to bytes
max_bytes = int(max_size * 1024 * 1024 * 1024)

if (max_bytes <= 0):
    log("Error: Incorrect max_size")
    exit(1)

month_dict = ['Null','Jan','Feb','Mar','Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov','Dec']

if args.eps:
    EPS_MAX = args.eps

if EPS_MAX < 0:
    log("Error: incorrect EPS")
    exit(1)

min_date = re.search('(\\d\\d\\d\\d)-(\\d\\d)-(\\d\\d)T\\d\\d:\\d\\d:\\d\\d', args.min_timestamp)
if min_date:
    min_year = int(min_date.group(1))
    min_month = int(min_date.group(2))
    min_day = int(min_date.group(3))
else:
    log("Error: Incorrect min timestamp")
    exit(1)

max_date = re.search('(\\d\\d\\d\\d)-(\\d\\d)-(\\d\\d)T\\d\\d:\\d\\d:\\d\\d', args.max_timestamp)
if max_date:
    max_year = int(max_date.group(1))
    max_month = int(max_date.group(2))
    max_day = int(max_date.group(3))
else:
    log("Error: Incorrect max timestamp")
    exit(1)

# Converting timestamp args to datetime
min_timestamp = datetime.strptime(args.min_timestamp, '%Y-%m-%dT%H:%M:%S')
max_timestamp = datetime.strptime(args.max_timestamp, '%Y-%m-%dT%H:%M:%S')

chunk = 0
written_alerts = 0
trimmed_alerts = open(output_file, 'w')

max_time=datetime(max_year, max_month, max_day)
current_time=datetime(min_year, min_month, min_day)

while current_time <= max_time:
    alert_file = "{0}logs/alerts/{1}/{2}/ossec-alerts-{3:02}.json.gz".format(wazuh_path,current_time.year,month_dict[current_time.month],current_time.day)

    if os.path.exists(alert_file):
        daily_alerts = 0
        compressed_alerts = gzip.open(alert_file, 'r')
        log("Reading file: "+ alert_file)
        for line in compressed_alerts:
            # Transform line to json object
            try:
                line_json = json.loads(line.decode("utf-8", "replace"))

                # Remove unnecessary part of the timestamp
                string_timestamp = line_json['timestamp'][:19]

                # Ensure timestamp integrity
                while len(line_json['timestamp'].split("+")[0]) < 23:
                    line_json['timestamp'] = line_json['timestamp'][:20] + "0" + line_json['timestamp'][20:]

                # Get the timestamp readable
                event_date = datetime.strptime(string_timestamp, '%Y-%m-%dT%H:%M:%S')

                # Check the timestamp belongs to the selected range
                if (event_date <= max_timestamp and event_date >= min_timestamp):
                    chunk+=1
                    trimmed_alerts.write(json.dumps(line_json))
                    trimmed_alerts.write("\n")
                    trimmed_alerts.flush()
                    daily_alerts += 1
                    if chunk >= EPS_MAX:
                        chunk = 0
                        time.sleep(2)
                    if os.path.getsize(output_file) >= max_bytes:
                        trimmed_alerts.close()
                        log("Output file reached max size, setting it to zero and restarting")
                        time.sleep(EPS_MAX/100)
                        trimmed_alerts = open(output_file, 'w')

            except ValueError as e:
                print("Oops! Something went wrong reading: {}".format(line))
                print("This is the error: {}".format(str(e)))

        compressed_alerts.close()
        log("Extracted {0} alerts from day {1}-{2}-{3}".format(daily_alerts,current_time.day,month_dict[current_time.month],current_time.year))
    else:
        log("Couldn't find file {}".format(alert_file))

    #Move to next file
    current_time += timedelta(days=1)

trimmed_alerts.close()

• Run the command below to make the recovery.py script executable:

          chmod +x recovery.py

• Execute the script using nohup command in the background to keep it running after the session is closed. It may take time depending on the size of the old logs.

       Usage example:
        nohup ./recovery.py -eps 500 -min 2023-06-10T00:00:00 -max 2023-06-18T23:59:59 -o /tmp/recovery.json -log ./recovery.log -sz 2.5 &

• Add the /tmp/recovery.json path to the Wazuh Filebeat module /usr/share/filebeat/module/wazuh/alerts/manifest.yml so that Filebeat sends the old alerts to the elasticsearch for indexing:

       module_version: 0.1

var:
  - name: paths
    default:
      - /var/ossec/logs/alerts/alerts.json
      - /tmp/recovery.json
  - name: index_prefix
    default: wazuh-alerts-4.x-

input: config/alerts.yml

ingest_pipeline: ingest/pipeline.json

• Restart Filebeat for the changes to take effect:

           systemctl restart filebeat

Verifying data restoration:
Using the Kibana dashboard, navigate to the Security events, Integrity monitoring, Vulnerabilities, and any other modules to see if the data is restored successfully.

I'm also attaching some reference links below which could be helpful:
https://documentation.wazuh.com/current/user-manual/files-backup/restoring/wazuh-central-components.html#single-node-data-restoration
https://documentation.wazuh.com/current/user-manual/files-backup/creating/wazuh-central-components.html

I hope this was helpful. Do not hesitate to get back to us on the outcome or if you have any other query.

Best regards.

--
You received this message because you are subscribed to the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/a232a76e-cd18-43a4-b660-de244a8f0c91n%40googlegroups.com.

[John Carry]

Hello   Oyebo,

Please consider our case on priority.
Have understood the provided procedure how-ever some of the steps are confusing in the sense that you have not have mentioned What Steps map to which Wazuh instance -ie Older machine or Newer Machine?  For example a particular Command or Configuration should be performed on Older instance or Newer for example.

I would request you to please mention the Wazuh instance as either Older or  Newer   where Each Step needs to be performed.

Especially the Section    Restoring old logs and the Screenshot I have attached is confusing, the Red Boxed is creating confusion , for example for the section after running the   recovery.py using  nohup (Needs to be run on Old Wazuh machine, right?)  what are the next steps like if the recover.py script is ran on older Wazuh machine then do we need Make below  filebeat changes on Older wazuh machine or newer?

• Add the /tmp/recovery.json path to the Wazuh Filebeat module /usr/share/filebeat/module/wazuh/alerts/manifest.yml so that Filebeat sends the old alerts to the elasticsearch for indexing
  
  

If  /tmp/recovery.json path needs to be added on Older wazuh machine's  Filebeat file then how-come I can test the restoration on Newly deployed wazuh machine ? because as per the provided steps we have yet not copied or moved that old logs to Newer machine of wazuh.

• 
  

[John Carry]

Hello   Oyebo,

Any update please ?

[Olusegun Adenrele Oyebo]

Dear John,

Thank you for using Wazuh and sorry for the late reply.

Apologies if any of the steps looked confusing. I actually put a heading initially just to indicate where the steps should be performed but now I have reviewed it again and edited some parts which should ease understanding. The first heading I indicated below which is for the backups should be performed on the old machine. I also indicated another heading which is for migration i.e. they should be performed on the new server after following the steps for backups.

Everything about the recover.py script needs to be run on the new machine. Also referencing the /tmp/recovery.json path to the Wazuh Filebeat module /usr/share/filebeat/module/wazuh/alerts/manifest.yml is done on the new machine having assumed that you have reinstalled the Wazuh components on the new server. You don't need to reference it on the old server.

If you check the screenshots below, the old alerts were part of what was backed up and also copied to the new server. Since they are all in the /var/ossec/log directory, they will also be backed up too:

Kindly find summary of steps below for backup and restore of wazuh files to a new server:

BACKUPS TO BE PERFORMED ON OLD MACHINE.

Note: Please note that the below steps need to be performed on the old server

MIGRATION TO THE NEW MACHINE.

Note:  Please note that the below steps are to be performed on the new server. You will also need to make sure you have a new installation of Wazuh. You can use the guide to perform a fresh installation of the central components on the new server.

• Compress the files generated after performing Wazuh files backup using the command below and transfer them to the new server. You can use SCP protocol to transfer the files to the new server:

I hope this was more detailed. Please do not hesitate to reach out again if you need further clarity or you have any other questions.

Best regards.

[John Carry]

Hello  Olusegun Adenrele Oyebo,
Thanks alot for the response, there is a request and would highly appreciate if you could re-share the the entire process once again as a new email message along with the corrections/Changes

 you made earlier on my last Query related to confusion, just ensure to mention the instance i-e which steps or set of commands need to be run on either Old-Wazuh-Instance or Newer-Wazuh-Instance.

Note: The entire process in multiple parts are some how creating confusion.
Highly regretful for the inconvenience.

[John Carry]

Dear,
Any chance?

[Olusegun Adenrele Oyebo]

Hello John,

Sorry for the late response.

I have written the steps on a new and separate mail as requested. Below is the link:

• https://mail.google.com/mail/u/0/#sent/KtbxLzGcGwxzBXlcBlqcjfCSSdpzrjHDnB

Please if you need any other clarification or have any other query, kindly write on this mail trail here for our easy tracking. We will be glad to here from you again.

Best regards.

[John Carry]

Hello Oyebo,

Really appreciate your help, unfortunately the link you provided is not loading and giving following error, you are requested to share the Ticket subject if possible.

[Olusegun Adenrele Oyebo]

Hello John,

Sorry about that. The mail was sent to you alone separately. Kindly confirm you got it. In case you didn't receive it, I have also attached a word document of it.

Kindly let us know if you need any other information.

Best regards.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/0b3a69f6-b246-4cfe-8caa-d9c84cc8f159n%40googlegroups.com.

[John Carry]

Hello Oyebo,
Really appreciate your support far, yes got your Word Document. Please confirm the below steps:

1) Restoring the ElasticSearch Files:

    In the below Snaphot where we need to copy the already backup Elastic files to /etc/elasticsearch, I just need to confirm that we will be replacing the Actual path of backup directory like in our case  /wazuh_files_backup/<DATE_TIME>/etc/elasticsearch/  correct ? and then the final command will look like below:

  sudo cp /wazuh_files_backup/<DATE_TIME>/etc/elasticsearch/ jvm.options /etc/elasticsearch/jvm.options

[Olusegun Adenrele Oyebo]

Hello John,

Thanks for reaching out again.

If you check the steps before that, you were advised to change directory to the path where you have the backed up files. Once you do that, you don't need to write the command that way. See screenshot attached.

I hope that provided clarity. Do not hesitate to get back to us again if you need further clarification.

Best regards.

[John Carry]

Thanks a lot, your prompt and detailed response is highly appreciated, will soon be planning to Migrate our environment, till then please keep this case opened as there may be need when I will ask for help if there is any.

[John Carry]

Hello Oyebo,
Have just stated the Migration activity after installing the new wazuh instance and now able to access the fresh wazuh instance.

There is a confusion:
Prior to start migration steps I want to confirm do we need to Remove the files and folders  from the New wazuh instance  inorder to prevent duplication?  I think there will duplication when we will copy the older wazuh backup  Data+configuration to new wazuh instance because those backup files, configuration, and Data will already present on new wazuh instance as it is in default state.

[John Carry]

Hello Oyebo,

Any update please ?

[Olusegun Adenrele Oyebo]

Hello John,

Sorry for the late response.

Please note that there won't be duplication as they will be replaced with the backed up file during the restoration process.

I hope this provided clarity. Do not hesitate to get back to us again if you need any other thing.

Best regards.