SEC 5.0 Backup/Restore

Hello tomerb,

I can only hope the author assumed that both servers will at some time be in the same network

Yes, the document - as it is a Migration Guide - assumes (second and fourth point in chapter 3) All components of Enterprise Console 5.1 (Management Console, Management Server, and Database) are installed on a single server, the old server, and are operational. and Enterprise Console will be migrated to the new server with a new identity.

I assume (forgive the pun) they are assuming the most likely case.

May I ask how many "disasters" with subsequent restores (successful or not) you have gone through :smileyhappy:?

Actually you have first to decide what "restore" means. In one extreme case you "just" take a snapshot of a working system, ensure that appropriate hardware (real or virtual) is available (or can be obtained within an acceptable time) and that you can resume this snapshot on the new hardware. Now we all know this is much easier said than done.

You should not concentrate on restoring function as quickly as possible necessary but maintaining the highest possible level of service. So what's service in this context? Probably the protection of endpoints. If you don't need a secondary on-site update location for your endpoints you can set it to Sophos. If your server goes belly-up your clients will still get the latest updates (admittedly "only" in hourly intervals). Of course the management server is not just a convenience - if your site is hit by malware you'll have a much harder time without it, so you should (be able to) get it working (as fast as possible).  

The migration guide lists all the items you need from the "old" system. Your best course of action is to actually play it through - in case "it happens" you've been there and done it. And do this for each new version. In my experience a simple "back up this and if you need to restore just run that program" (or "... read there and do that") seldom works and gives a false sense of security.

That's not to say that a concise guide or an easy to use ("automatic") tool wouldn't be helpful (and won't come). But consider you can't install the same OS and/or SQL server version as on the old server. Quite a lot of combinations the tool would have to cover.

Sorry for the rant

Christian

Hi Christian,

we're managing around 80 servers and so far had just one "restore situation", which of course was the most troublesome possible: One server, three buildings, something around 100 Clients spread over different rooms, having different (physical) keys and so forth. (Did I mention laptops that get locked away by different people?)

There were data backups so we did a new installation (same OS, same name, same IP), restored the backups and just about everything was fine - until we came to Sophos: The clients simply didn't communicate with the new server. In order to solve the issue we had to re-protect all clients, which was a pain. (In 60 out of 80 scenarios this would have been one or two hours work, in 15 cases we'd need a day at the most...)

The idea of setting a secondary update server is quite a good one, actually. We can live with hourly updates and the bandwidth will be stressed a bit, but this is a very rare scenario, so what...

I understand that the tool I'm dreaming of won't come - that's why I was talking about "dreams" instead of "feature requests". ;-)

So what I take from this conversation is that the only sensible way of "snapshotting" a running Sophos installation in order to restore it after a server crash is to snapshot the whole (virtual) server. Some servers are virtualized already and chances are there will be more of them in the future, so this is indeed an option.

Giving the whole issue another thought: Maybe it's enough to simply _know_ the credentials for SophosUpdateMgr - which I didn't in the crash scenario we had. If the identity of the server doesn't change, the clients won't exchange messages with the (restored) server, but they will get their updates without any warning messages popping up all the time.

As you suggested: We can live without the ability to actually _manage_ clients for weeks or even more as long as they get updates and the users working at them won't be bothered with warnings, that aren't intended for them, anyways.

Thanks a lot for your time and patience - I must admit that I could have figured out this myself...

Thomas

Hello Thomas,

in fact the database backup and the few registry exports (as described in the MigGuide) are all you need:

In order to be able to continue using (and editing) your existing groups/group structure and policies you need the database. Some policies (AV,  AU, TP) are easy to retype, other can be a pain. If you employ a strict naming convention it might be rather easy to set up groups and distribute the clients but it can quickly get tedious to recreate the setup  

In order to keep protection running you need a live CID with the desired subscription and the credentials the clients use to access it. Could be on another server - you can set up an alias so that clients usually updating from ServerGone can temporarily update from ServerStillHere  

In order to be able to manage the clients "all" you need are the certificates and a CID where they update from (i.e. one which matches their updating policies)

As I have the certificate registry keys around since day one I've been able to "rope in" 2000 clients when the then management server started to behave erratically (for whatever reason and not directly related to Sophos, however management and even download was no longer reliable as the server decided to crash every few hours) but for some reason could not be replaced immediately. As we can't use Protect computers with the majority of clients this was not an option.

The details were complex (they involved using a share other than InterCheck for EM Library, setting up an alias for the old server and configuring both \sau and \rms to make all the clients to update from and talk to the new server), further complicated due to the fact that I was on paternal leave then :smileyhappy: (they only contacted me when they were about to install SEC but had already decided on the identity of the server and set it up - just in time so I could tell them about the certificates). I decided to not migrate the database (didn't really need alerts and events and took the opportunity to redo the group structure, also there weren't that many policies). Took them  two days to set up the new server including SEC and EM (during which time updates more or less worked from the old server) and then I came in for half a day to make the necessary configurations. During the rest of the day almost all clients successfully switched over to the new server (I let others assign the clients to the new groups :smileywink:).

Sounds perhaps scary - it wasn't: You have the certificates, you have the database, you have the credentials for the update user - that's all you need. As I said - if you want a 1:1 replacement an integrated tool would be handy, a snapshot another option (unless the problem is already contained in it). Otherwise a manual restore is not that much work compared to the other steps.

I must admit that I could have figured out this myself

It took me years .... :smileyvery-happy:

Christian