Got a question from a customer, what measures do you have in place for a catastrophic failure of your monitoring, like a virtual collector is accidently erased in azure or a physical failure of a "hardware collector" ,or mailicious activity by a disgruntled employee. any suggestions / answers?
For catastrophic failures of a Collector, it's pretty easy to recover, assuming you have a place where you can reinstall the Collector. Just get your Collector VM back up and running, then go to LM and download the Collector installer for that Collector:
Run the installer and it'll reestablish connection to LM platform, platform will reassign devices back to it (assuming you have failover/ABCG setup) and it'll start running. The Collector itself is a very, very smart goldfish. It does very complex things, but doesn't have a "memory" of its own. It's just a proxy for the platform.
As for a disgruntled employee, there is quite a lot they could mess up that wouldn't make sense to restore, except historical data. There's no mechanism to load data into LM that isn't happening right now, so you wouldn't really have the ability to restore historical data yourself. You should reach out to support to ask what their options are for doing data restores.
As for how LM is configured, the best option would be to use something like Ansible to define LM as code (IaC). Our Ansible module will help with that a little. It needs to be built out more. What it lacks could be pulled using the SDK and stored. I'm talking all theoretical here as the scripts would need to be built. I have used the SDK to build a portal reset script, the opposite of what you're looking for. But you should be able to pull users (sans passwords), roles, api tokens (sans keys), netscans, groups, etc. It's just a matter of cycling through all the GET endpoints in the API to back it all up. Restoring it would be a bit of work. Netscans could bring the devices back in by generating a CSV given the exported devices' properties. Would be doable, but a huge effort.
