This article describes how to migrate all the data from a FortiSIEM to another machine.
Scope
FortiSIEM.
Solution
When there are issues with an initial FortiSIEM machine, the appliance has been replaced because of hardware issues or other reasons, it is necessary to migrate all the data from the original machine to the new one.
Follow the next steps to migrate all the data:
Step 1: Context: Next steps can be applied in the next conditions:
-
- From Hardware machine to New Hardware machine.
- From VM to new VM.
- From Hardware to new VM and vice-versa.
Step 2: Requirements: Targeted FortiSIEM requires to be in the same:
-
- Version (ex: v7.1.4).
- Mode (Enterprise or Service Provider).
- Online storage has to be EventDB or NFS
Step 3: Building the FortiSIEM target: Install the new FortiSIEM Super and follow all the steps till the FortiSIEM is licensed and running stable.
Step 4: Transferring the data: Here is the list of valuable FortiSIEM data:
-
- /cmdb => database where all discovered devices are listed with their credentials, FortiSIEM configuration, incidents.
- /svn => devices configurations.
- /data => devices events received.
Step 5: Restoring the CMDB and SVN: On the original FortiSIEM, take the /data/archive/cmdb/phoenixdb_202X-XX-XXTXX-XX-XX file and transfer it to the targeted FortiSIEM on /tmp directory.
Example from new (or targeted) FortiSIEM CLI:
rsync -az root@ORIGINAL_FortiSIEM_IP:/data/archive/cmdb/phoenixdb_202X-XX-XXTXX-XX-XX /tmp
Stop all the services except the database service from the targeted FortiSIEM:
systemctl stop phxctl.service phxctl stop Stopping phoenix ... @Fri Jun 28 11:29:27 CEST 2024, Stopping backend process ... @Fri Jun 28 11:29:53 CEST 2024, Stopping apache ... @Fri Jun 28 11:29:54 CEST 2024, Stopping phAnomaly master... Stopping phAnomaly master... Terminated @Fri Jun 28 11:29:57 CEST 2024, Stopping phAnomaly worker... Stopping phAnomaly worker... Terminated @Fri Jun 28 11:30:03 CEST 2024, Stopping phGenerativeAI... Stopping phGenerativeAI... @Fri Jun 28 11:30:07 CEST 2024, Stopping phClickHouseMonitor... @Fri Jun 28 11:30:07 CEST 2024, Stopping application server ... @Fri Jun 28 11:30:32 CEST 2024, Stopping postgres ... Stop the Api Nodejs Sevice.. Cleaning the Redis for API Stopping the Redis for API systemctl start postgresql-13
Run the restoration command (this may take some time along the amount of data) :
/opt/phoenix/deployment/db_restore.sh /tmp/phoenixdb_202X-XX-XXTXX-XX-XX Restore database phoenixdb from /tmp/phoenixdb_202X-XX-XXTXX-XX-XX ... Successfully restored phoenixdb from /tmp/phoenixdb_202X-XX-XXTXX-XX-XX
Update the hardware ID:
hardware_id=`phgetUUID` psql -U phoenix phoenixdb -c "update ph_sys_conf set value='$hardware_id' where property = 'hardware_id';"
Update the IP address if it’s not the same as the original FortiSIEM:
new_ip='type_your_new_ip_here'
psql -U phoenix phoenixdb -c "update ph_sys_server set ip_addr='${new_ip}' where mode=2 and ( role is NULL or role = 0 );"
psql -U phoenix phoenixdb -c "update ph_sys_conf set value = 'https://${new_ip}/svn' where property = 'svn_url';"
psql -U phoenix phoenixdb -c "update ph_health_status set host_ip='${new_ip}' where nodetype=0;"
Restore SVN:
rsync -az root@ORIGINAL_FortiSIEM_IP:/svn/ /svn reboot
From that moment, FortiSIEM can be used and receive new events.
Step 6: Restoring the EventDB/NFS: After the online storage is configured and mounted, run the next command from the new FortiSIEM super CLI as root to start transferring the events:
nohup rsync -az --progress root@ORIGINAL_FortiSIEM_IP:/data/eventdb/ /data/eventdb > /tmp/transfered_files.txt 2>&1 &
Follow the transfer with:
tail -f /tmp/transfered_files.txt