Disaster Recovery

One of the key components of keeping your company running successfully is insuring that business can continue seamlessly when a disruption occurs. An interrupting event does not need to be a disaster to negatively impact the most basic systems. Loss of power, hardware failure, or in extreme instances, a natural disaster or act of war can all wreak havoc on business continuity. Planning and preparation for keeping your data and systems protected and limiting any downtime during disruptions is the ultimate goal.
 
The purpose of this document is to assist you in planning for backing up and recovery of the Cloud Migrator system. Cloud Migrator has two main components:
 
SQL Server Database- where all the Cloud Migrator data is stored.
Agent Server- a Windows service that can be installed and configured to run on the IIS server or on a third utility or application server.

 
SQL Server Backup and Maintenance Plans
SQL Server maintenance plans are not only useful for disaster recovery but are also strongly recommended to keep the database optimized and backed up regularly. SQL Server provides several options for creating maintenance plans, including a wizard in SQL Management Studio or via Transact-SQL scripting.
Note: Please refer to Microsoft's website for instructions and best practices for constructing maintenance plans: Maintenance plans - SQL Server
Tip: Regardless of your company's preferred disaster recovery methodology, maintenance plans should always be created and scheduled on the database.
Disaster Recovery (DR) Plans
There are multiple ways DR plans can be implemented. The right choice of plan depends on a firm's SLA, budget, location, and other business requirements.

Option I: Real-Time Replication

SQL Server Database
In addition to maintenance plans for backing up the SQL database, there are other options for failing over the environment. The option with the optimum up time is through either database mirroring or use of SQL Server's AlwaysOn Availability Groups for replication. In either case, there is a replica of the system sitting in an offsite location where data from the firm's production data center is synchronized automatically and in real-time with the replica system. In the event of a disaster, the firm can switch users' access of data from the production data center to the DR data center. Normally this is seamless to the end-user.
Note: Please refer to Microsoft support for information regarding use of the AlwaysOn feature: Getting Started with availability groups - SQL Server Always On
 
Cloud Migrator Agent Server
In a replicated or mirrored DR environment, an CM agent server(s) would also be installed and configured using the same installer version as that which is installed on the production agent server. The configuration file for the CM Windows agent service would be configured to point to the replicated database in the DR site. The location of this file is in the installation directory: .DriveLetter \Program Files\Prosperoware.UCloudMigrator\Agent\CalibanAgent.config.
This file needs to be configured if the firm utilizes the Agent Service on the application server within the firm. The file is located in the installation directory: .DriveLetter\Program Files\Prosperoware.CloudMigrator\Agent\CalibanAgent.exe.config.
Within the file, you will see the name of the SQL server and the name of the Cloud Migrator database. If you have a full CM setup in DR, you will need to make sure these two values are pointing to the correct server and database.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="caliban" type="Caliban.Configuration.CalibanSection, Caliban.Core" allowDefinition="Everywhere" allowLocation="true" />
</configSections>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<caliban>
<database>
<connectionStrings>
<connectionString name="CalibanCore" value="Data Source=[SQLServerName];Initial Catalog=CloudMigrator1;Integrated Security=true;MultipleActiveResultSets=True" />
<connectionString name="CalibanLog" value="Data Source=[SQLServerName];Initial Catalog=CloudMigrator2;Integrated Security=true;MultipleActiveResultSets=True" />
</connectionStrings>
</database>
</caliban>
<runtime>
<gcServer enabled="true" />
</runtime>
</configuration>
This option offers real‐time fail over for Cloud Migrator. Using this option, most single points of failure may be eliminated by incorporating mirrored agent and SQL servers such that Cloud Migrator capabilities are always available. This option is a recommended approach for large sites.
Cloud Migrator on a Virtual Environment
There are a number of firms who utilize virtual servers and store their data on a high-speed SAN infrastructure, which has the capability to take immediate snapshots of the stored data. These hardware-level snapshots can provide better throughput and may be more efficient than standard backup procedures. If you have a SAN in your environment, please speak to your firm's infrastructure specialist for details on how to utilize snapshots for redundancy.

Option II: Standby Cloud Migrator Environment

This option can be configured to sit in your disaster recovery location with nightly or periodic refreshes of the data. This may be a good option for a firm that does not have the resources to invest in a real-time mirrored system. The firm would have at least a SQL server configured in the DR location. As with real time replication, you would use the config files to point to the database that is located in the DR site. If using a virtual environment, you are able use that technology to take snapshots of servers that can be stored in the DR environment.

Option III: Simple Backups

This option does not offer real‐time failover and would require more downtime in order to stand up and restore the alternate environment. This option may be more compelling to firms with more limited resources. If utilizing this mode of redundancy, it is important to backup the program files separately.
 
Service Monitoring
It is strongly recommended, to have system monitoring on the system, for services. Sometimes with system updates, server failures and reboots, services for umbria might not start.
For monitoring, you can use the SCOM Windows Server monitoring platform, or another third party tool.
 
Agent Server (App/Windows Service):
A monitoring alert can be set on this server against the Cloud Migrator Agent Service in the Windows Services panel in Windows Server. Additionally, the service should set to start the service if a failure occurs.
 
SQL:
SQL can be configured to notify if the SQL services are stopped. If these are stopped and the database is unaccessible, the Cloud Migrator login will bring the user to the install page.