Migrating an ESX Local Disk-based Deployment Using an rsync Tool

Migrating an ESX Local Disk-based Deployment Using an rsync Tool

Overview

This migration process is for an FortiSIEM deployment with a single virtual appliance and the CMDB data stored on a local VMware disk, and where you intend to run the 4.2.1 version on a different physical machine as the 3.7.x version. This process requires these steps:

Overview

Prerequisites

Copy the 3.7.x CMDB to a 4.2.1 Virtual Appliance Using rsync

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

Assigning the 3.7.x Supervisor’s IP Address to the 4.2.1 Supervisor Registering Workers to the Supervisor

Prerequisites

Contact AccelOps Support to reset your license

Take a snapshot of your 3.7.x installation for recovery purposes if needed

Make sure the 3.7.x virtual appliance has Internet access

Download the 4.2.1 migration scripts (ao-db-migration-4.2.1.tar). You will need the Username and Password associated with your AccelOps license to access the scripts.

  1. Log in to the 4.2.1 virtual appliance as root.
  2. Check the disk size in the remote system to make sure that there is enough space for the database to be copied over.
  3. Copy the directory /data from the 3.7.x virtual appliance to the 4.2.1 virtual appliance using the rsync tool.
  4. After copying is complete, make sure that the size of the event database is identical to the 3.7.x system.

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

  1. Log in over SSH to your running 3.7.x virtual appliance as root.
  2. Change the directory to /root.
  3. Move or copy the migration script ao-db-migration-4.2.1.tar to /root.
  4. Untar the migration script.
  5. Run ls -al to check that root is the owner of the files ao-db-migration.sh and ao-db-migration-archiver.sh.
  6. For each AccelOps Supervisor, Worker, or Collector node, stop all backend processes by running the phtools
  7. Check the that archive files phoenixdb_migration_* and opt-migration-*.tar were successfully created in the destination directory.
  8. Copy the opt-migration-*.tar file to /root.

This contains various data files outside of CMDB that will be needed to restore the upgraded CMDB.

  1. Run the migration script on the 3.7.x CMDB archive you created in step 7.

The first argument is the location of the archived 3.7.x CMDB, and the second argument is the location where the migrated CMDB file will be kept.

  1. Make sure the migrated files were successfully created.
  2. Copy the migrated CMDB phoenixdb_migration_xyz file to the /root directory of your 4.2.1 virtual appliance This file will be used during the CMDB restoration process.

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

  1. Log in to your 4.2.1 virtual appliance as root.
  2. Change the directory to /opt/phoenix/deployment/.
  3. Run the post-ao-db-migration.sh script with the 3.7.x migration files phoenixdb_migration_xyz and opt-migration-*.ta r.
  4. When the migration script completes the virtual appliance will reboot.

Assigning the 3.7.x Supervisor’s IP Address to the 4.2.1 Supervisor

  1. In the vSphere client, power off the 3.7.x Supervisor.

The IP Address for the 3.7.x Supervisor will be transferred to the  4.2.1 Supervisor.

  1. Log in to the 3.7.x Supervisor as root over SSH.
  2. Run the vami_config_net

Your virtual appliance will reboot when the IP address change is complete.

Registering Workers to the Supervisor

  1. Log in to the Supervisor as admin.
  2. Go to Admin > License Management.
  3. Under VA Information, click Add, and add the Worker.
  4. Under Admin > Collector Health and Cloud Health, check that the health of the virtual appliances is normal.

Setting the 4.2.1 SVN Password to the 3.7.x Password

  1. Log in to the 4.2.1 Supervisor as root over SSH.
  2. Change the directory to /opt/phoenix/deployment/jumpbox.
  3. Run the SVN password reset script ./phsetsvnpwd.sh
  4. Enter the following full admin credential to reset SVN password

Organization: Super

User: admin

Password:****

Migration is now complete – Make sure all devices, user created rules, reports, dashboards are migrated successfully

 

This entry was posted in Administration Guides, FortiSIEM on by .

About Mike

Michael Pruett, CISSP has a wide range of cyber-security and network engineering expertise. The plethora of vendors that resell hardware but have zero engineering knowledge resulting in the wrong hardware or configuration being deployed is a major pet peeve of Michael's. This site was started in an effort to spread information while providing the option of quality consulting services at a much lower price than Fortinet Professional Services. Owns PacketLlama.Com (Fortinet Hardware Sales) and Office Of The CISO, LLC (Cybersecurity consulting firm).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.