Recover data on a separate /nsm RAID array after catastrophic crash and fresh reload

[pimpernoni]

I crashed my SO 2.3.220 while trying to load the honeypot (not sure what happened). Suffice to say could not recover using the SO .iso recover methods, and copied my /opt/so/* files and /etc/pki/* files for recover.

Consequently, I did a fresh reload of SO 2.3.220 onto the production box (manager), No apparent issues when running so-status at the end. But this was using the same disk as the core OS where /dev/mapper/system-nsm is mounted on /nsm.

In my preferred set up, I have /nsm mounted using a RAID 1 1-TB array, which had a full supply of logs, pcaps, etc prior to the crash. I followed the "Adding a new disk; Method 2" to originally mount the /nsm. Using my prior RAID1 array, I have mounted it to /nsm, but I notice that there are more directories then the fresh installed /nsm (now marked /nsm.old), and a few of the directory/file ownership names have been lost and converted to group numbers, without corresponding /etc/shadow usernames to match. (eg. zeek, suricata, wazuh, etc)

Now so-status reports all systems green except so-fleet and so-playbook, but I am not able to get into the SOC via my analyst, and trying to restart the fleet and playbook report, I get an error "MySQL Error 1045: Access denied for user 'root'@'10.0.1.6' (using password: YES)", similarly the restart shows failed for 5 items, all related to this password issue.

I know I can move (rename) the /nsm.old to the /nsm, utilizing the fresh install and probably be able to move forward collecting new data, but I wonder if there is any way to reconnect my former /nsm loaded with historical data to be available on the fresh SO 2.3.220 manager?

If I've lost data, so be it, but before I burn 900GB of data, I wanted to see if any alternative exists

Thanks for the advice.

P

[cm-ops]

If you run salt-call pillar.get secrets:mysql to get the password, are you able to then run docker exec -it so-mysql mysql -u root -p and login with that password?