Disaster Recovery - Introduction
Disaster recovery is described as the process, policies and procedures put in place to deal with potential natural or human-induced disasters. A disaster is an event that creates chaos and could prevent the continuation of normal functions. A disaster recovery plan forms part of a business continuity plan (BCP) or business process contingency plan (BPCP), and is essential to any organization that wants to either maintain or quickly resume mission-critical functions after such a disaster. The disaster recovery plan should typically include an analysis of business processes and continuity needs, and especially planning for resumption of applications, data, hardware, communications (such as networking) and other IT infrastructure. Attention should also be given to disaster prevention. As K2 blackpearl interacts with other external systems such as SharePoint or other line-of-business (LOB), it is important to include all related systems in your disaster recovery planning for K2.
- Scenario 1: Simple K2 backup and restore
- Scenario 2: Running a K2 Standby Server within the same environment
- Scenario 3: Restoring a K2 blackpearl environment
- Scenario 4: SQL Mirroring - manual failover
Disaster Recovery - K2 blackpearl Disaster Recovery
Specific components need to be addressed when creating a Disaster Recovery Plan (DRP) for K2 blackpearl.
K2 Components
 |
Note that since K2 blackpearl 4.6 RTM, the databases have been consolidated and a fresh install of K2 blackpearl will only have one database. Upgrades from previous versions will still have multiple databases. In general, this document reflects a fresh install. |
The following K2 Components need to be considered:
- K2 database
- K2 Web Components
- K2 blackpearl Server
- K2 for Reporting
- K2 for SharePoint
Non K2-specific Components
The following non K2-specific Components need to be considered in addition:
- Forms (ASP.NET/ InfoPath)
- External databases utilized by your K2 processes
If any ASP forms generation client events are used in the K2 processes, it is important to backup these pages. By default, K2 deploys these forms to C:\Program Files\K2 blackpearl\Workspace\ClientEventpages
Any ASP pages/sites or InfoPath design files that are used with K2 processes, should also be backed up.
Windows Server Machine
It is assumed that you have a working baseline Windows 2008 Server
Disaster Recovery - SQL Server 2008 Disaster Recovery Options
It is of the utmost importance to back up K2 databases as this forms the core of the K2 functionality and data related information. The following presents a short description of the different options catered for by SQL Server 2008 when backing up the K2 database.
| SQL Disaster Recovery Options | |
|---|---|
| Backup and Restore |
Backup refers to the copying of data so that these additional copies may be restored after a data loss event. Backups differ from archives and backup systems differ from fault-tolerant systems. Backups are useful primarily for two purposes:
|
| Log Shipping | Log shipping allows you to automatically send transaction log backups from a primary database on a primary server instance to one or more secondary databases on separate secondary server instances. The transaction log backups are applied to each of the secondary databases individually. An optional third server instance, known as the monitor server, records the history and status of backup and restore operations and, optionally, raises alerts if these operations fail to occur as scheduled. There is however no guarantee that the various databases will be in sync after restoration due to the fact that K2 blackpearl server is writing entries from the K2Server database to K2ServerLog database as the backup of the logs for each database occurs. This method is therefore not the preferred disaster recovery option for K2 blackpearl. |
| Database Mirroring | Database mirroring is a primarily software solution for increasing database availability. Mirroring is implemented on a per-database basis and works only with databases that use the full recovery model. The simple and bulk-logged recovery models do not support database mirroring. Database mirroring is supported in SQL Server Standard and Enterprise. Database mirroring offers substantial availability and provides an easy-to-manage alternative or supplement to failover clustering or log shipping. When a database mirroring session is synchronized, database mirroring provides a hot standby server that supports rapid failover with no loss of data from committed transactions. During a typical mirroring session, after a production server fails, client applications can recover quickly by reconnecting to the standby server. As this method is similar to Log Shipping mentioned above, and could result in databases being slightly out of sync, it is not the preferred disaster recovery method for K2 blackpearl. |
| Database Clustering | A failover cluster is a combination of one or more physical disks in a Microsoft Cluster Service (MSCS) cluster group, known as a resource group, that are participating nodes of the cluster. The resource group is configured as a failover clustered instance that hosts an instance of SQL Server. A SQL Server failover clustered instance appears on the network as if it were a single computer, but has functionality that provides failover from one node to another if one node becomes unavailable. Failover clusters provide high-availability support for an entire Microsoft SQL Server instance, in contrast to database mirroring, which provides high-availability support for a single database. It is however recommended to not change the cluster names with restoration as the K2 worklist tables will be out of sync and this will result in errors related to the client events. |
For in-depth technical information on SQL Server disaster recovery, visit the following website https://support.microsoft.com/en-us/kb/822400
|
The SQL Server disaster recovery option, Replication, is not supported by K2. |
Disaster Recovery - SQL Server 2008 R2 Support
Support has been added for the following SQL Server 2008 R2 feature. Note that K2 4.6 or later is required:
- Mirroring – provided for single database scenarios
Disaster Recovery - SQL Server 2012 Support
Support has been added for the following SQL Server 2012 feature. Note that K2 4.6 or later is required:
- Database Services – provided for multiple databases and single database
- AlwaysOn – provided for single database scenarios (be sure to point to the correct SQL Server Always on Listener/Instance)
- Mirroring – provided for single database scenarios
Support has been added for the following SQL Server 2012 feature. Note that K2 4.6.1 or later is required:
- Reporting Services integration – provided for multiple databases and single database scenarios
