Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 13 replies
  • Subscribers 1 subscriber
  • Views 3923 views
  • Users 0 members are here
Options
Suggested
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

tomerb

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
  • 0

    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

    :26259
Reply
  • 0

    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

    :26259
Children
No Data