Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 2 subscribers
  • Views 4478 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 Disaster Recovery Solution

nigelBlunkell

What's the latest guidance on providing an ongoing physical DR solution for SEC?

Must we try to schedule the use of the DataBackupRestore.exe and BackupDB.bat programs as described in the "Sophos Enterprise Console server to server migration guide"?

As its DR, it needs to be as simple as possible.

Are there basic design solutions to allow this, rather than a fail over?

(DR solution must provide full control and not just an update repository)

Thoughts please...

Thanks



This thread was automatically locked due to age.
Parents
  • 0

    Hello nigelBlunkell,

    if the extent of disaster in this context is that your SEC server goes belly up, i.e. you need to install a replacement management server as quickly as possible then you'd need

    • the console installer
    • the account information (user, password for the database and the SUM user)
    • a recent DataBackupRestore.exe backup (the database backup is included if the database is local)
    • if applicable a backup of the customizations (mrinit.conf, .xml policies)

    Naturally all changes since the last backup are lost so it's a good idea to use a schedule. As DataBackupRestore.exe writes to %ProgramData% you must also move or copy the data to a secure location afterwards.

    Or is it some other kind of disaster you have in mind?

    Christian

Reply
  • 0

    Hello nigelBlunkell,

    if the extent of disaster in this context is that your SEC server goes belly up, i.e. you need to install a replacement management server as quickly as possible then you'd need

    • the console installer
    • the account information (user, password for the database and the SUM user)
    • a recent DataBackupRestore.exe backup (the database backup is included if the database is local)
    • if applicable a backup of the customizations (mrinit.conf, .xml policies)

    Naturally all changes since the last backup are lost so it's a good idea to use a schedule. As DataBackupRestore.exe writes to %ProgramData% you must also move or copy the data to a secure location afterwards.

    Or is it some other kind of disaster you have in mind?

    Christian

Children
  • 0 in reply to QC

    Christian et al,

    Thanks for your comments.

    Are we therefore saying that the regular exporting (which is clearly documented) is the only and official way to provide a recovery position for a simple deployment (2 sites - Prod and DR) or should we look to some other design?

    (This scenario is physical only and in this case excludes the obvious "full system backup and restore" or" VM replication" options)

    Thanks

    Nigel

  • 0 in reply to nigelBlunkell

    Hello Nigel,

    so it's a data-center site disaster scenario where the endpoints are (mostly) unaffected? 
    I'm not Sophos and I haven't looked into SEC in conjunction with DR scenarios. Are you thinking of database replication instead of backup/restore?

    Christian

Unfiltered HTML