Sophos SafeGuard 6.0 - Recovering Server

Doing so is beyond the normal documentation scope that could be expected, plus there's other issues involved such as how to do the fail-over and/or load balancing that require more expertise than can be reasonably communicated to customers. FYI most big companies have teams of people managing this stuff and it takes some trial and error to get a fully redundant and load balanced setup in place to do LARGE enterprise scale
Here is what it took for me:
WARNING!! Unless you're prepared to go all in and do whatever it takes or how much it costs for this sort of setup, stick with the active/passive failover SQL cluster and regular backups with a failover IIS frontend configuration.

This assumes you want load balanced and High Availability on an enterprise scale:

Two more Servers running Windows Server 2008 R2 x64 Enterprise

SQL Server 2008 R2 x64 Enterprise

Redundant replicative SANS (we use 3PAR and NetApp)

Knowing how to send up single instance passive/active failover of the SQL server. This requires 3 volumes, to be configured on each server and the SANS supporting failover along with the server 2008 SANS block level driver detecting disk/sans failure and being able to mount a backup store. So each server has a primairy store volume, backup store volume, and a witness disk volume.

Do not EVER use multi-instance SQL database clusters for this application or you'll be sorry, and it's not IF it's WHEN!

You will need an isolaited NIC on each server with a static IP and no route out to anywhere on an isolated switch and/or subnet for multi-cast traffic, this is how the "heartbeat" of the SQL server works in detecting failures and caching SQL queries to send to the failover instance.

When setting up failover for the shortest times make sure you have relatively new servers with the fastest ram available and MORE than enough RAM to quickly load your database on your server. Also on your SAN I recommend solid state HBA's or high performance 15K RPM hybrid drives of some kind, this will dramatically reduce your database failover times and backup times.

Setting up IIS with SSL mode, each IIS server has to have a verifyable PUBLICLY SIGNED CERT that your browser can verify easily with additional certificate install.  I can verify that wildcart publicly signed certs from an accepted certificate authority do work, I'm using this now in production.

Each IIS instance on each server must be configured to use the same cert, same hostname, same active directory user credentials for the IIS instance.

The same AD username used for the IIS instance(s) MUST have read/write access to the SafeGuard database

IIS with SSL must NOT EVER be configured to use compression... however the Load Balancer CAN be configured to use compression to save bandwidth and it won't break anything.

A note about visualization, on the enterprise level I don't care how great you think ESX or OpenStack is, DO NOT EVER put enterprise level systems like this in your VM cluster, you'll be sorry later after your I/Ops for your database host

A load balancer must be set up to rounte your LAN and/or WAN traffic appropriately. The BEST types to use do not change servers in the middle of the TCP/XML/SOAP conversation. This means USE ROUND ROBIN FOR LOAD BALANCING. Anything else and you risk breaking the TCP/HTTPS stream and failing the connection during say something vital like a cert transfer and causing local cache corruption issues or weird data in your database

Each load balancer in place if you use seperate ones say for internal and external MUST be set up EXACTLY the same except for public facing vs DMZ/LAN based IP addressing.

Do not put your load balancer for this behind any kind of nat based firewall with SPI and DPI (layer 7 deep packet inspection), the load balancer needs to be have the public IP address terminated on it. You can use routed DPI layer 7 systems but make sure you aren't using paranoid settings, when transfering backup coppies of the MBR over the net sometimes they create false positives in your HTTPS virus scan for incoming or outgoing traffic from these server and/or load balancer(s).

make sure your clients all use the same hostname for internal and external load balancing (i.e. the hostname of the actual LOAD BALANCER(s), NOT the server names behind them in the network scheme. Also be sure to use the FQDN, not just th e hostname of the server or load balancer.

Make sure to actually write out and test your failure scenarios so you KNOW everything works, this one is SUPER important, if you don't know or understand how to write and test failure scenarious I suggest you consult someone who does, this just isn't unplugging a server, there's simulating service crashes, networking issues, load balancer failures (if you cluster your load balancers which if you have good ones they'll support it), making sure your public and private DNS is set up correctly, etc..

As you can see setting this sort of thing up not just with SQL but with the whole enterprise level redundant clustering is a BIG DEAL with a lot of steps involved, it's not something that most single IT guys could do end to end let alone readily be supported by helpdesk or most SMB IT departments for that matter, the expense unless you have these types of systems in place already to handle this for other stuff is high.
Even SGN pro-services would have to be on-site and probably call in the big guns to assist with troubleshooting this sort of thing if you couldn't at least do most of the isolation yourself figuring out what the real issue is and in big complex environments. The bigger and more complex your IT setup is the more unexpected things happen, sometimes without any kind of reasonable explanation.
This isn't just a "does safeguard support this" issue, there's WAY more to it than that on the OS and network level that has to be done for this sort of thing to work.

Doing so is beyond the normal documentation scope that could be expected, plus there's other issues involved such as how to do the fail-over and/or load balancing that require more expertise than can be reasonably communicated to customers. FYI most big companies have teams of people managing this stuff and it takes some trial and error to get a fully redundant and load balanced setup in place to do LARGE enterprise scale
Here is what it took for me:
WARNING!! Unless you're prepared to go all in and do whatever it takes or how much it costs for this sort of setup, stick with the active/passive failover SQL cluster and regular backups with a failover IIS frontend configuration.

This assumes you want load balanced and High Availability on an enterprise scale:

Two more Servers running Windows Server 2008 R2 x64 Enterprise

SQL Server 2008 R2 x64 Enterprise

Redundant replicative SANS (we use 3PAR and NetApp)

Knowing how to send up single instance passive/active failover of the SQL server. This requires 3 volumes, to be configured on each server and the SANS supporting failover along with the server 2008 SANS block level driver detecting disk/sans failure and being able to mount a backup store. So each server has a primairy store volume, backup store volume, and a witness disk volume.

Do not EVER use multi-instance SQL database clusters for this application or you'll be sorry, and it's not IF it's WHEN!

You will need an isolaited NIC on each server with a static IP and no route out to anywhere on an isolated switch and/or subnet for multi-cast traffic, this is how the "heartbeat" of the SQL server works in detecting failures and caching SQL queries to send to the failover instance.

When setting up failover for the shortest times make sure you have relatively new servers with the fastest ram available and MORE than enough RAM to quickly load your database on your server. Also on your SAN I recommend solid state HBA's or high performance 15K RPM hybrid drives of some kind, this will dramatically reduce your database failover times and backup times.

Setting up IIS with SSL mode, each IIS server has to have a verifyable PUBLICLY SIGNED CERT that your browser can verify easily with additional certificate install.  I can verify that wildcart publicly signed certs from an accepted certificate authority do work, I'm using this now in production.

Each IIS instance on each server must be configured to use the same cert, same hostname, same active directory user credentials for the IIS instance.

The same AD username used for the IIS instance(s) MUST have read/write access to the SafeGuard database

IIS with SSL must NOT EVER be configured to use compression... however the Load Balancer CAN be configured to use compression to save bandwidth and it won't break anything.

A note about visualization, on the enterprise level I don't care how great you think ESX or OpenStack is, DO NOT EVER put enterprise level systems like this in your VM cluster, you'll be sorry later after your I/Ops for your database host

A load balancer must be set up to rounte your LAN and/or WAN traffic appropriately. The BEST types to use do not change servers in the middle of the TCP/XML/SOAP conversation. This means USE ROUND ROBIN FOR LOAD BALANCING. Anything else and you risk breaking the TCP/HTTPS stream and failing the connection during say something vital like a cert transfer and causing local cache corruption issues or weird data in your database

Each load balancer in place if you use seperate ones say for internal and external MUST be set up EXACTLY the same except for public facing vs DMZ/LAN based IP addressing.

Do not put your load balancer for this behind any kind of nat based firewall with SPI and DPI (layer 7 deep packet inspection), the load balancer needs to be have the public IP address terminated on it. You can use routed DPI layer 7 systems but make sure you aren't using paranoid settings, when transfering backup coppies of the MBR over the net sometimes they create false positives in your HTTPS virus scan for incoming or outgoing traffic from these server and/or load balancer(s).

make sure your clients all use the same hostname for internal and external load balancing (i.e. the hostname of the actual LOAD BALANCER(s), NOT the server names behind them in the network scheme. Also be sure to use the FQDN, not just th e hostname of the server or load balancer.

Make sure to actually write out and test your failure scenarios so you KNOW everything works, this one is SUPER important, if you don't know or understand how to write and test failure scenarious I suggest you consult someone who does, this just isn't unplugging a server, there's simulating service crashes, networking issues, load balancer failures (if you cluster your load balancers which if you have good ones they'll support it), making sure your public and private DNS is set up correctly, etc..

As you can see setting this sort of thing up not just with SQL but with the whole enterprise level redundant clustering is a BIG DEAL with a lot of steps involved, it's not something that most single IT guys could do end to end let alone readily be supported by helpdesk or most SMB IT departments for that matter, the expense unless you have these types of systems in place already to handle this for other stuff is high.
Even SGN pro-services would have to be on-site and probably call in the big guns to assist with troubleshooting this sort of thing if you couldn't at least do most of the isolation yourself figuring out what the real issue is and in big complex environments. The bigger and more complex your IT setup is the more unexpected things happen, sometimes without any kind of reasonable explanation.
This isn't just a "does safeguard support this" issue, there's WAY more to it than that on the OS and network level that has to be done for this sort of thing to work.