Knowledge Center Server migration

• Migrating from 8.5.2.x to 8.5.3.x Knowledge Center Server
• Migrating from 8.5.1.x to 8.5.2.x Knowledge Center Server
• Migrating from 8.5.0.x to 8.5.1.x Knowledge Center Server
• Backing up and restoring data in Knowledge Center Server 8.5.1.x and higher

Migrating Knowledge Center Server data

Before you upgrade Knowledge Center Server, create a backup of all your current knowledge space data that you will use to restore your information in the upgraded software. To backup and restore knowledge space, use one of the nodes from your GKC cluster.

Your knowledge space files are stored in the path you configured in the gks.yml configuration file (path.data option which we will refer to as %DATA%).

Important

Restrictions: Correct migration from 8.5.2.x to 8.5.3.x possible only if a list of languages in 8.5.3.x is the same as in 8.5.2.x. If in new configuration of knowledge bases languages with enabled locales used - data from base language from 8.5.2.x will be lost.

Migrating from 8.5.2.x to 8.5.3.x Knowledge Center Server

1. Replace software of version 8.5.2 of each Knowledge Center instance with software of version 8.5.3.
2. Run all but one nodes of your Knowledge Center cluster using data from 8.5.2 version.
   At this point your server API will reject all REST requests with error of 404. Your server will be not available while migration procedure will not be completed.
3. Start last Knowledge Center node (with the same data from 8.5.2 version) using batch file from command line using option of "upgrade": server upgrade.
   After starting this node and finalizing migration process your cluster will be available. Then you can stop the node you have started from command line and start it in usual way.

Migrating from 8.5.1.x to 8.5.2.x Knowledge Center Server

1. Create a backup of your knowledge data with the gks-backup-restore utility (see Creating your backup archive for Knowledge Center Server 8.5.1.x or higher with gks-backup-restore utility for more information).
2. Stop all Knowledge Center cluster nodes.
3. Remove your existing knowledge space files from %DATA% folder. Repeat this with all of the nodes in your GKC cluster.
4. Upgrade your Knowledge Center Software.
5. Run the cluster.
6. Restore the data using the gks-backup-restore and the backup file you created in step 1 (see Restoring data from a backup for more information).

Migrating from 8.5.0.x to 8.5.1.x Knowledge Center Server

1. Stop all Knowledge Center cluster nodes.
2. Remove your existing knowledge space files from %DATA% folder. Repeat this with all the nodes in your GKC cluster.
3. Upgrade your Knowledge Center software.
4. Choose one node from your upgraded cluster and replace the %DATA% folder with a backup of your old data.
5. Run the chosen Knowledge Center Server node.
6. Create a backup from an upgraded node using the gks-backup-restore utility (see Creating your backup archive for Knowledge Center Server 8.5.1.x or higher with gks-backup-restore utility for more information).
7. Stop the node.
8. Remove all the data from the %DATA% folder of your node.
9. Run the node.
10. Restore your data using the gks-backup-restore utility and the backup file you created in step 6 (see Restoring data from a backup for more information).
11. Run all the other nodes in your cluster.

Backing up and restoring data in Knowledge Center Server 8.5.1.x and higher

Creating your backup archive for Knowledge Center Server 8.5.1.x or higher with gks-backup-restore utility

In the following steps the node will be referred to as %NODE% and the URL to its GKS context will be referred to as %NODEURL%.

1. Check the archiving options for the node's application. You will use this to backup and restore knowledge space (see Knowledge Center Server Application Options for more information). Both the path and type options should be configured. We will refer to the archiving path as %ARCPATH%.
2. Make sure your directory allows you to write within the archive on behalf of the OS user that runs GKC server.
3. Ensure that your configuration contains at least one user with Knowledge.ADMINISTER privileges. Use this user account to perform all backup related procedures. We will refer to this user as %ADMIN%.
4. Use the gks-backup-restore utility to backup your knowledge space: java -jar gks-backup-restore.jar --host %NODEURL% --user %ADMIN%

The previous command creates the backup archive file, places it into %ARCPATH% backups directory and prints the name of your produced archive into the console. The console output will appear as follows:

Successful Upgrade

The output file name remains the same whether or not the backup is successful. If you receive an error message instead of complete, the backup archive (%BACKUP%) will have the same name as it would if successful so you will need to check the archive itself. To check your backup storage use the command: java -jar gks-backup-restore.jar --host %NODEURL% --user %ADMIN% -c.
You now see all the backup archives you have ever created. Each console output record shows the name of the archive, its size, and the creation date. An output execution of the command will look similar to the following example:

Example of Command Execution

Before you complete the upgrade, you need to check the consistency of your backup archive.

Checking your backup archive

1. Use any archiver utility.
2. Confirm that each backup archive at root consists of a "history" entry and an entry in the form of: <subtenant>_<knowledge base name>_<language> per each knowledge base branch of your knowledge space. In most cases the default is subtenant.

• For example: default_knowledgefaq_en is an entry for the English branch of knowledge base knowledgefaq. The root entry of history will contain exactly one activity history entry. Each knowledge branch entry must contain exactly two entries qna_category and qna_document.

Restoring data from your backup

1. Start your GKC cluster.
2. Restore the data from your backup archives using one of the following command lines:

• To restore the data from the exact archive file %BACKUP% (you may have several of them): java -jar gks-backup-restore.jar --host %NODEURL% --user %ADMIN% -r  %BACKUP%
• To restore data from the very last backup archive you made: java -jar gks-backup-restore.jar --host %NODEURL% --user %ADMIN% -r a

If successful, the console output for either of the previous commands will look similar to the following image:

Successful Console Execution Example

If unsuccessful, the failure to restore procedure console will show a message with an error description.