You may find it helpful to begin your disaster recovery plan by asking yourself a few simple questions (which may have very complex answers):

These three questions serve as an excellent starting point for beginning your disaster recovery planning and should also be considered during your initial deployment planning (discussed in Chapter 5).

Mitigation planning primarily revolves around determining potential failure points within your business process and determining what (if any) steps need to be taken to mitigate those potential failures. Within a K2 blackpearl environment, some common failure points to consider might be:

Each issue has a potential mitigation strategy, which may or may not be justified based on your organizations' requirements. Take planning for natural disasters, for example. An example mitigation strategy might be:

Such a mitigation strategy will ensure that, at most, one week of data is lost in the event that the system and all local tapes are destroyed. A mitigation strategy targeted toward no data loss might look something like:

This second mitigation strategy will ensure very limited data loss and very good continuity, but the costs associated with such an approach are significant and may not be justified by the processes deployed.

Continuity planning is focused on how the business will continue to operate while the system is down in the event that your mitigation strategies have been ineffective. Common approaches to continuity are:

There is not necessarily a one-size-fits-all continuity plan, and in many cases, a hybrid approach may also be required. For example, the work involved in bringing a backup system online, switching all users to it, and then migrating the data back into the primary system upon recovery may only be justified for outages lasting long periods of time.

Recovery planning focuses on restoring the system to a working state after a disaster. For simple failures, such as a single drive in a RAID array, this might be as simple as swapping a drive out, while for more severe failures it could involve completely rebuilding a machine or an entire server farm and restoring the data.

It is also important to consider how to merge work that was performed according to your continuity plan back into the system when it is brought back up. This should not be overlooked and can require considerable effort.

Once your plan has been established and your disaster recovery procedures are in place, it is extremely important to also test those procedures periodically. No software system is static, and it is very important that the recovery plan be reviewed and tested periodically to ensure that it adequately addresses the needs of the organization.

The sections that follow will focus on the individual K2 blackpearl components and provide DR recommendations for each, but it is also critical to have plans in place to be able to restore each server utilized within your install to a clean state (such as restoring the server from a previous backup or a drive image) prior to restoring K2 blackpearl.

K2's databases are really the heart of your disaster recovery strategy since so much of K2 lives inside of the databases, including workflow instances, process definitions, SmartObject definitions, and environment variables just to name a few. Disaster recovery planning for K2's databases is very similar to the disaster recovery planning one would do for any set of SQL databases.

SQL Server 2005 provides several different disaster recovery options, which can be used for K2 disaster recovery, and those are outlined in the following table:

Each solution has strengths and weaknesses, and it will be up to you to determine which option is the best fit for your needs. In almost all scenarios, you will always perform periodic backups and then may additionally utilize one of the other options. For high-availability scenarios, K2 blackpearl supports both clustering and mirroring.

The following discussion focuses on the tools that come with SQL Server 2005; however, there are a variety of third-party backup solutions on the market that make database maintenance and backup significantly easier. Though the steps might vary slightly if you are using one of these third-party tools, the information should still be very applicable.

BACKUP DATABASE [Categories] TO DISK = N'C:BACKUPK2Categories.bak'
WITH NOFORMAT, NOINIT, NAME = N'Categories-Full Database Backup', SKIP,
NOREWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE [Dependencies] TO DISK =
N'C:BACKUPK2Dependencies.bak' WITH NOFORMAT, NOINIT, NAME =
N'Dependencies-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS =
10
GO
BACKUP DATABASE [EnvironmentSettings] TO DISK =
N'C:BACKUPK2EnvironmentSettings.bak' WITH NOFORMAT, NOINIT, NAME =
N'EnvironmentSettings-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,
STATS = 10
GO
BACKUP DATABASE [EventBus] TO DISK = N'C:BACKUPK2EventBus.bak' WITH
NOFORMAT, NOINIT, NAME = N'EventBus-Full Database Backup', SKIP,
NOREWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE [EventBusScheduler] TO DISK =
N'C:BACKUPK2EventBusScheduler.bak' WITH NOFORMAT, NOINIT, NAME =
N'EventBusScheduler-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,
STATS = 10
GO

BACKUP DATABASE [HostServer] TO DISK = N'C:BACKUPK2HostServer.bak'
WITH NOFORMAT, NOINIT, NAME = N'HostServer-Full Database Backup', SKIP,
NOREWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE [K2Server] TO DISK = N'C:BACKUPK2K2Server.bak' WITH
NOFORMAT, NOINIT, NAME = N'K2Server-Full Database Backup', SKIP,
NOREWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE [K2ServerLog] TO DISK = N'C:BACKUPK2K2ServerLog.bak'
WITH NOFORMAT, NOINIT, NAME = N'K2ServerLog-Full Database Backup',
SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE [K2SQLUM] TO DISK = N'C:BACKUPK2K2SQLUM.bak' WITH
NOFORMAT, NOINIT, NAME = N'K2SQLUM-Full Database Backup', SKIP,
NOREWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE [SmartBox] TO DISK = N'C:BACKUPK2SmartBox.bak' WITH
NOFORMAT, NOINIT, NAME = N'SmartBox-Full Database Backup', SKIP,
NOREWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE [SmartBroker] TO DISK = N'C:BACKUPK2SmartBroker.bak' WITH
NOFORMAT, NOINIT, NAME = N'SmartBroker-Full Database Backup', SKIP,
NOREWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE [SmartFunctions] TO DISK =
N'C:BACKUPK2SmartFunctions.bak' WITH NOFORMAT, NOINIT, NAME =
N'SmartFunctions-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS
= 10
GO
BACKUP DATABASE [WebWorkflow] TO DISK =
N'C:BACKUPK2WebWorkflow.bak' WITH NOFORMAT, NOINIT, NAME =
N'WebWorkflow-Full Database Backup',
SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE [Workspace] TO DISK = N'C:BACKUPK2Workspace.bak'
WITH NOFORMAT, NOINIT, NAME = N'Workspace-Full Database Backup', SKIP,
NOREWIND, NOUNLOAD, STATS = 10
GO

C:> SQLCMD -s <servername> -i <script file name>

The K2 blackpearl Web Components consist of the Worklist, Management Console, Report Designer, and Notification Event Designer. Generally, these components serve as the "face" of K2 to administrators and users of the system.

There are two primary approaches which can be taken for DRP around the Web Components:

The K2 blackpearl server(s) handle processing of workflows, SmartObject requests, SmartObject Services, and so on. Unlike the Web Components, there are some customizations of the server that do not live in the server. These customizations are primarily limited to:

Therefore, it is important to back up the entire K2 blackpearl installation directory (the default is C:Program FilesK2 blackpearl).

There are two primary scenarios for restoring a K2 blackpearl environment:

Restoring to a cold standby is fairly straightforward

The K2 for Reporting Services components are installed on your SQL Reporting Services server and are required for the reporting functionality within K2 blackpearl. These components contain no customizations, so can safely be reinstalled after a disaster.

An additional consideration however, is any customized reports which may have been created. These reports are stored within the SQL Reporting Server databases and any backup strategy must also include these databases. The Reporting Service databases are:

Similarly to the main K2 databases, you should frequently perform backups of these databases.

K2 for SharePoint components are installed on the servers in your SharePoint farm and provide integration between SharePoint and K2 blackpearl. The K2 components do not require any specialized backup considerations outside of your organization's SharePoint disaster recovery procedures. A complete discussion of SharePoint disaster recovery is outside the scope of this book, but SharePoint provides several mechanisms to perform backups and restores including through Central Admin or the command line.

This sample command will perform a farm-level backup of your SharePoint farm:

Stsadm.exe -o backup -directory c:ackuplocation -backupmethod full

Similarly, this sample command will perform a farm-level restoration:

Stsadm.exe -o restore -directory c:ackuplocation -restoremethod overwrite

Additionally, you should also perform backups of your SharePoint directory on the file system.

Many K2 blackpearl workflows are designed to interact with external systems such as Active Directory, SharePoint, LOB databases, or external Web services. These systems are often overlooked as part of the K2 blackpearl disaster recovery plan, since they are likely covered by their own disaster recovery plan/SLA, but it is very important to also factor these systems in to your continuity planning.

This can be a challenge for administrators, especially since the systems your organization's processes interact with may be extremely fluid. Any new process that is published to the K2 servers might introduce a new external dependency. It is very important, therefore, to have good procedures in place for deployment so that you can understand which external systems could potentially impact your workflows.

For example, imagine that you have a workflow that accesses lookup data from a list in SharePoint in order to determine routing. If SharePoint goes offline, what will happen to workflow process instances that attempt to access this list data? The answer to this question largely depends on the process design, but the likely outcome is that all processes which attempt to access the SharePoint resource will error out and will need to be repaired once SharePoint comes back online. By knowing ahead of time that this workflow has a dependency on SharePoint, you can warn users or take alternative action so that workflows of this type are not started or actioned during the outage.