Simple K2 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:

  • To restore a computer to an operational state following a disaster.
  • To restore small numbers of files after they have been accidentally deleted or corrupted.

This option supports both full and incremental backups.

It is important to back up SQL Server keys and certificates separately. Not doing so can result in data loss.

Symmetric Key

K2 uses the symmetric key based on K2's use of certificates. Certificates are built into SQL Server and K2 is leveraging off the SQL Server platform. Hierarchically, it can be depicted in the following way:

  • Operating System Level: Windows DPAPI
  • SQL Server Level: Service Master Key (SMK)
  • SQL Server Level: Database Master Key (DMK)
    • K2: Certificate
      • K2: Symmetric Keys

The encryption is applied in a top down manner, so the Operating System level secures the Service Master Key (SMK), etc.

As discussed in Database Disaster Recovery Options, there are four SQL disaster recovery options which are supported by K2. In all options, the domain should be changed as the operating system level uses the service account, or SPN, to encrypt the Service Master Key.

See the Configuring MS SQL for AlwaysOn Automated Failover of the K2 Database for more information.

Backup and Restore

As long as the SQL instance is still functional, the Service Master Key and Database Master Key will still be functional. By recreating the certificate and symmetric keys, the data will be accessible.

Log Shipping

Visit the Microsoft article on creating identical keys on two different servers for additional information. Both servers should have the same Service Master Key.

Database Mirroring

The same applies as in log shipping.

Database Clustering

The same applies as in log shipping, although a Microsoft Cluster Server will not need the identical symmetric keys created as it is aware of the other nodes and will likely use the same key by design.

Visit the following articles for information on backup of certificates and keys:

Prior to a backup or restore of the database, always remember to stop the K2 service on all K2 servers first.

Backup of Databases

Depending on the specific components your organization utilizes to integrate with K2, the following databases need to be included in the backup and restoration process:

  • K2 database
  • SharePoint databases (if any)
  • Custom Application databases (if any)
  • SQL Server databases

In addition, the following SQL Server system databases should be backed up regularly:

  • Master
  • Model
  • Msdb

If you are using any SharePoint components, it is also advisable to back up any SharePoint databases. Any other custom application databases should also be backed up.

Backup of K2 Servers and IIS

Certain customizations of the K2 Servers and IIS are saved in the following files:

  • IIS configuration files
  • K2 configuration files (changes to .config or .setup files)
  • Logging files
  • Custom DLLs such as custom security providers or SmartObject services
  • Other application files

It is therefore important to backup the entire K2 installation directory. The default location is "%ProgramFiles%\K2".

SharePoint features are deployed to "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES". It is recommended that this directory be backed up as well.

It is important to note which K2 version is currently installed and all additional hotfixes or updates are installed on the system.

Restore

K2 recommends using the SQL Server user interface for restoring the K2 database and related databases.

Restoring a database will overwrite all changes since the previous backup!

For the other database disaster recovery options provided by SQL Server and supported by K2, see the Disaster Recovery Introduction.

Backup and Restore Options when the K2 Servers Cannot Be Stopped

If you are unable to stop the K2 servers for backup and restore operations, for example, organizational policy demands the servers remain started, the solution is to perform complete backups including transaction log backups which will allow you point-in-time restore.

Use Enterprise Backup software solutions which provide continuous protection. This allows you to restore to any point in time up to the hardware or software failure.

As an alternative, if you are restoring standard backups using the default SQL backup tools, you can opt to restore to a particular point-in-time to prevent database inconsistencies. For more information on this option, visit the Microsoft article titled Restore to a Point in Time (SQL Server Management Studio).