Concepts for Cold Standby
Unlike a Hot Standby System, a Cold Standby System does not automatically activate replacement systems. Instead, the replacement systems must be started manually by a system administrator. Due to the associated downtime, a cold standby system is not used for applications that must be available at all times. However, if this does not absolutely have to be guaranteed, Cold Standby systems are more cost-effective.
There are several possibilities to keep a Cold Standby system up to date and then switch over if necessary. All of them include changing the network interface or at least the IP address. If only the IP address is changed but not the (identical) network interface, the license file must remain unchanged on the target system (the system you switch to).
The main difference comes into play with data storage. Depending on whether data is stored on the Lobster_data server itself or on an external share, the data has to be copied or can simply be reused.
Internal Lobster_data
Standalone
If the entire installation (including the installation and backup directories and the necessary database) runs on the local server, we call this a standalone system.
In this case, the installation and backup directories regularly have to be copied to the Cold Standby server. The best way to do this is by using a tool that is capable of merely copying the differences (which includes removing deleted files and directories on the target server as well).
Many affected directories are static and only a few are dynamic. Nevertheless, the synchronisation traffic can be substantial for heavily used Lobster_data installations.
The database has to be synchronised on a regular basis as well. But most of the content (apart from the log and comm_log tables) is static, so not all the tables have to be synchronised in short intervals. If the used database provides a synchronisation function itself, it can be used.
The Cold Standby server itself (including the database) can run in parallel, but not the Lobster_data application on that server. Fortunately, that is technically impossible anyway.
External Database and Common Share Directory
This kind of installation uses an installation and backup directory that is not located on the server itself. The database is also located on an another server and is contacted via TCP/IP.
In this case, the installation and backup directories are always up to date. If the network interface is changed, the license file has to be replaced with a new one. The database is not affected by a switchover.
Lobster_data DMZ
Standalone
The entire installation (installation and backup directory) including the necessary database runs on the local server.
In this case, the same comments as for the corresponding scenario for the internal Lobster_data system are valid. However, the database is not taken into account.
Common Share Directory
The installation uses installation and backup directories that are not on the server itself.
In this case, the same comments as for the corresponding scenario for the internal Lobster_data system are valid. However, the database is not taken into account.