Does anyone know what steps would need to be taken or has anyone gone through the process of needing to restore their BigFix environment? Our root server is on a VM that we back up daily, and our database is also backed up daily. I assume we’d need to just restore the VM and database and that’d be good enough to get ourselves going again? How would it affect clients?
Because you’ll be essentially “rolling” the database back in time, you are likely to see all of your endpoints duplicate themselves as they generate and register new ComputerID’s and re-establish their Sequence numbers.
Other than that, your Relays may need some TLC when the server comes back up since they will no longer be in sync. You might have to uninstall/reinstall the Relays so that they will gather the information from the server. You might be able to get away with stopping the Relay services and deleting the beswwwroot (I think that’s the folder) under them and restarting the Relay services. I’ve had to do this with Relays that got behind the server before, but I’ve not had to deal with restoring a BES Server yet.
Keep us updated with how it goes and what you have to do.
Ditto all that (the folder name is wwwrootbes though).
I’d add that if fast restores are needed, look into a DSA (Distributed Server Architecture) to provide the redundancy of a second (third, fourth, etc.) root server. Depending on the environment, a scratch-rebuild of a new server can be faster and easier than a full system restore if DSA is in place.
Thanks for the replies already! We’re not currently in this situation where we need to restore. I’m just asking what others do. I’ve read about the DSA before and it seemed interesting but then I was wondering how much just having a recent backup of the root and SQL servers would suffice. I figured recent changes or endpoints would be rolled back because of a database restore but I wasn’t sure about endpoint re-registering. I’m not sure whey they’d generate new IDs and duplicate themselves though? I’d be just like as if BigFix was just down for a period of time, wouldn’t it?
Has anyone implemented a DSA in their DR environment?
I am curious to hear more about DSA as well… pros/cons, and time to restore services to some of the questions you’ve been asking in this thread as well to see if it’s even necessary. Our account rep was very confused when I mentioned it was something we were going to deploy, he cautioned strongly against it, but we didn’t have time to dive deeper in, will be finishing that conversation next week sometime.
We have our DB backed up in a remote/HA configuration now, but do not currently have DSA implemented. I got as far as spinning up the server in our DR environment, but put it on hold for now.
Actually, I may have the RegCount behavior reversed. Restoring the Server shouldn’t cause the Re-registration of the endpoints. That happens when you restore an End Point.
You really should look at the DSA option for long term stability. It requires a server built the same as your current server, and it replicates the SQL database and some of the other server data. Part of the idea of a DSA server is that clients will continue to report to the DSA replica if the “Primary” server goes down for an extended period. My experience has been that IBM does not recommend backing up the BigFix server with “backup software” because it can impact performance. DSA is a more reliable option. My two DSA servers replicate every 10 minutes.
New client installations won’t work while the Primary server is down because the new clients must contact the server name listed in the masthead, but a DNS change can resolve that.