1 Reply Latest reply on Jul 29, 2015 9:44 AM by wluther

    Orion Server Backup questions


      So we had our homegrown network monitoring server die with it's backups being saved to itself...


      Anyway, we have since implemented Orion and want to make sure the same thing that happened to our other server doesn't happen to our Orion server. My question is, which folders do we need to backup on the Orion/Polling server? Do we need to have any backups created for it, or could we get by with just backing up the Orion DB which is on a physically separate SQL server.


      Can anyone share their method in backing up the Orion/Polling server and the Orion DB or any experiences with a DR situation where your server crashed and you had to restore it?




        • Re: Orion Server Backup questions

          jacob.decker I think, if you do not have any custom modifications to your orion site/install, everything you need should be stored in the db now.

          Depending on how quickly you need to have a server restored, up, and running again, should tell you what you need to do in regards to backing up the actual server(s).




          Okay, having said that, this is what I do with our servers.

          Our servers are all VM. (Yes, even the database... I know...)

          Before I installed any Solarwinds products on any of the servers, I cloned each server/type into a template, for future use.

          This gives me the ability to turn up a "ready-to-go" database server, or IIS server, or polling server, in a matter of minutes.

          Then, I do all of my SolarWinds installs, and get my Orion environment up and working, as it should be.

          After everything is working as it should be, I clone each of the servers again, but leave them as a cloned VM instead of converting them into another template.


          Now, I have a template of each type of server (DB, IIS, additional poller/nothing special), fresh off the press, with no SolarWinds products installed.

          I also have a production environment, which will be in use, as well as a clone of the environment, powered off, or on standby, to be used for upgrades, testing, or whatever is needed.


          I have my DB server backup the db every night, and saving the backup to 3 different locations. One of these locations is actually another VM, used to restore the db to test that it will work, when that day comes.


          When I do upgrades, I start my maintenance window as soon as the db has successfully completed the nightly backup (12am), and restore that backup to my cloned environment. (I disable NIC on alt environment just in case)

          After the alt env. has the most recent backup restored, I upgrade the various modules and, when ready, shutdown production environment, and enable NIC on upgraded env.

          This allows me to minimize downtime and loss of data, as my Orion env. is never actually offline, though there is a small gap of data loss. My production servers stay online all the way until the alt env. is fully upgraded. I figure, there is going to be data loss either way, so, at least I have my system up and running, monitoring, config backups, etc. while I upgrade.


          If all goes well, my previous alt environment becomes my new production, and I make new clones of the recently upgraded servers to replace my old production. On the other hand, if we find we are having problems, such as with the infamous 11.5RC/11.5/11.5.1/11.5.2 upgrades, I shutdown the newly upgraded servers, and power on the previous production servers, and we are back in business. In that case, we will definitely have a loss of data, however, I will take a little bit of data loss over complete system failure, anyday.



          If we were on physical servers, I would still do my best to prove the case of having at least 1 additional physical server for each production server, as I think a direct image of identical machines will prove to be the most efficient way to work, when that time comes. Fortunately, though, I have the ability to take snapshots (for temporary testing/backups), as well as clone the entire server(s), which just make things so much easier to work with, not to mention save time.



          Well, I doubt I actually provided any useful information, but I do hope you find a better way that works for you.






          1 of 1 people found this helpful