This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SEC 5.0 Backup/Restore

First of all, I have read

http://www.sophos.com/en-us/support/knowledgebase/114299.aspx

and this seems to be exactly what I'm looking for. However, I was once in error assuming that a plain database backup (SEC 4.5) was enough so this time I do not want to "assume", but to make sure before something goes wrong. I'm not worried about policies, because setting them is not too much effort. What concerns me is that after a complete server crash I'm able to re-install SEC and get the clients back to work without having to touch all of them.

So for a backup I'd run

DataBackupRestore -action=backup

and copy SOPHOS50.bak, SOPHOSPATCH.bak and the contents of C:\ProgramData\Sophos\ManagementServer\backup\ to a (hopefully) safe place.

I do have knowledge of the credentials of the 'database' user but not for the SophosUpdateMgr as in almost all cases they were generated automatically during SEC 4.x installation which has been upgraded by now. Do I need those credentials for a recovery or are they part of the backup anyway. If I need them, is there any way to recover them in an existing installation?

:25297


This thread was automatically locked due to age.
Parents
  • 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

    :26205
Reply
  • 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

    :26205
Children
No Data