Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 13 replies
  • Subscribers 1 subscriber
  • Views 3912 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

    Hello Thomas,

    a chicken-egg-problem

    I always take the knowledge of the architecture as granted. I'll try to make it short without omitting the essential details:

    RMS

    Whether you use protect computers, install manually (might also be scripted) from the share/CID or use a package built from the share the RMS component is configured from mrinit.conf. From this RMS gets the management server's "address" (one or more of IPv4, IPv6, FQDN or NetBIOS name), the "address" of the (RMS)router it should connect to (which is the same as the server unless you use message relays) and several keys which are used to verify and set up the communication partners. Once RMS has been initialized the client will only communicate with the server which presents the correct certificate (more on this later). RMS is used to pass policies and requests to and messages from the client - no credentials (e.g. SophosUpdateMgr) are involved. For further reading see Explanation of Sophos Endpoint Security and Control exceptions required for PCI compliance and Remote Management System: components and significant files.  

    Updating

    The client updates from the UNC or HTTP location (which is not necessarily the management server) specified in the policy. The host can be identified by FQDN, NetBIOS name or IP address. Usually credentials are required. They can either be set locally on the client or sent with an updating policy. 

    New (or restored) server

    • Clients can update from a new server if the applicable attribute matches the host identifier in the updating policy and the credentials allow access to the share. If they are different a new policy must be sent to the clients.
    • Clients can communicate with the server if it has the same "address" and "identity" as the old one. For the latter it is important that you import the certificate registry keys (DataBackupRestore exports them to CertificationManager.reg) before you install SEC (see chapter 7 in the migration guide). 

    (the following applies to Windows clients only)

    If the clients can update and the server has the same identity but a different "address" RMS can be "redirected" by configuring the CID.

    Whether the clients can update or not - if the new server has a different "identity" you have to reprotect (or otherwise reinstall RMS on) them in order to establish RMS communication (please see also How to redirect Windows endpoints to a new management server).

    So, to answer your original question:

    Read the Server to server migration guide carefully - a restore is in principle a migration (provided you have a valid backup) - and don't skip chapter 7! Some steps could be omitted if you are using domain accounts and/or the server has been set up with the same name. Nevertheless you should review them.

    If you are familiar with SEC installation and the various file system and registry locations it probably takes less time to get SEC on the server up and running (including client communication) than it took for writing this post :smileywink: - but it isn't just install/restore/run.

    Does this answer your question?

    Christian

    :25333
Reply
  • 0

    Hello Thomas,

    a chicken-egg-problem

    I always take the knowledge of the architecture as granted. I'll try to make it short without omitting the essential details:

    RMS

    Whether you use protect computers, install manually (might also be scripted) from the share/CID or use a package built from the share the RMS component is configured from mrinit.conf. From this RMS gets the management server's "address" (one or more of IPv4, IPv6, FQDN or NetBIOS name), the "address" of the (RMS)router it should connect to (which is the same as the server unless you use message relays) and several keys which are used to verify and set up the communication partners. Once RMS has been initialized the client will only communicate with the server which presents the correct certificate (more on this later). RMS is used to pass policies and requests to and messages from the client - no credentials (e.g. SophosUpdateMgr) are involved. For further reading see Explanation of Sophos Endpoint Security and Control exceptions required for PCI compliance and Remote Management System: components and significant files.  

    Updating

    The client updates from the UNC or HTTP location (which is not necessarily the management server) specified in the policy. The host can be identified by FQDN, NetBIOS name or IP address. Usually credentials are required. They can either be set locally on the client or sent with an updating policy. 

    New (or restored) server

    • Clients can update from a new server if the applicable attribute matches the host identifier in the updating policy and the credentials allow access to the share. If they are different a new policy must be sent to the clients.
    • Clients can communicate with the server if it has the same "address" and "identity" as the old one. For the latter it is important that you import the certificate registry keys (DataBackupRestore exports them to CertificationManager.reg) before you install SEC (see chapter 7 in the migration guide). 

    (the following applies to Windows clients only)

    If the clients can update and the server has the same identity but a different "address" RMS can be "redirected" by configuring the CID.

    Whether the clients can update or not - if the new server has a different "identity" you have to reprotect (or otherwise reinstall RMS on) them in order to establish RMS communication (please see also How to redirect Windows endpoints to a new management server).

    So, to answer your original question:

    Read the Server to server migration guide carefully - a restore is in principle a migration (provided you have a valid backup) - and don't skip chapter 7! Some steps could be omitted if you are using domain accounts and/or the server has been set up with the same name. Nevertheless you should review them.

    If you are familiar with SEC installation and the various file system and registry locations it probably takes less time to get SEC on the server up and running (including client communication) than it took for writing this post :smileywink: - but it isn't just install/restore/run.

    Does this answer your question?

    Christian

    :25333
Children
No Data