Recover from Ransomware

Solved726 viewsdisaster recovery Ransomware
7
0 Comments

Hi Dojo,

We have a Dataminer System which has been impacted by a Ransomware attack.  Currently the Windows Servers were impacted, however, the Linux Cassandra and Elastic servers look to be fine.  As our backup location was also impacted, we do not have a valid backup to restore, but we do not want to lose the history in the database.  We were hoping to implement the following process to re-install and connect the elements back to the database.  Can you please review and let us know if this could work?  Is there a better procedure where we can retain the trend histories already collected?

  • Install a new Dataminer on the current platform with new hard drives (or new platform if needed) with a local database (not the current Linux database server).
  • Add the elements back in to the newly installed system (pointing to new database).
  • Make a backup of current Linux Database (for disaster recover if needed).
  • Sync element IDs (DMA ID from above) to previous IDs from original system export.
    • I am not sure if this would be by editing numerous xml files on the new system for the different elements.
    • or by updating different tables to match the new IDs created on the newly installed system.
  • Point new Dataminer to old Linux Cassandra Database.
  • At this point we should have the historical trend data back and visible in the system as we always have.
  • Rebuild the DMPs
    • Not as concerned here with historical trend data, as this is already handled in the main system.
    • Need to identify if the element IDs need to match or not to continue to sync with the main DMA.
  • Verify connectivity.
  • Test
Steve Purcell [SLC] [DevOps Advocate] Selected answer as best 23rd May 2023

1 Answer

5
8.12K 1 Comment

Hi Steve,

I guess this should work, it all sounds logical. If you make sure the DMA ID and Element ID is back to what it was before, it should link back to that history in the old database... Just a small sidenote, it the latest version they've been adding a GUID to identify DMAs and elements, but not sure if this is already the case in your version and if it's actually relevant for the history or not.

To get the Element IDs correct, I believe editing the element.xml file is the safest option compared to modifying the database. Although you have to keep in mind the element ID might also be used in other config files like the views.xml and many other files...

About the DMP, if you use standard DataMiner replication, then it doesn't matter what the Element ID (or DMA ID) is of the DMP. The central DMS just fetches raw data from the DMP without a DMA or Element ID.

Bert

Steve Purcell [SLC] [DevOps Advocate] Selected answer as best 23rd May 2023
Steve Purcell [SLC] [DevOps Advocate] commented

Thank you for the feedback Bert, we are trying this next week, will update the post on the success or difficulties.
Update on the recover – After restoring the system and adding the elements back in so they name matched the DMA ID before the ransomware attack worked. I then updated the element XML files for the Spectrum elements as we were using Measurement Points and Monitors for data collection and visuals. Once all edits were completed, system was back up and running with the existing Visio drawings being used. Thanks for the assistance.