Backing Up IBM Financial Services Workbench Data

Model data and implementation code are stored in Git repositories hosted in a Git repository server like GitHub, GitLab or Atlassian Bitbucket. This is the source of truth for everything created with Solution Designer. IBM Financial Services Workbench doesn't provide an integrated service of this type and so backing up this data is the responsibility of the operator of the Git repository service. Since this is the most important data store for the design-time data a check of the backup strategy used for this or these (one can use multiple Git repository servers) services is advised. The precise ways on how to create these backups depend on the type and version of the Git repository server used and are therefore out of the scope of this document. You can find the currently configured Git repository services in Solution Designer under Administration (sprocket icon) -> Admin settings.

While working in Solution Designer, a MongoDB database is used as a convenient workspace copy of the contents of a Git repository. Any changes made to this database are written back when users of the Solution Designer or the (fss-cli for developers creating implementation code) commit their changes. This database should also regularly be backed up if you want to avoid losing changes made in between commits. This database can always be recreated from the contents of a Git repository. This MongoDB service is also not provided by IBM Financial Services Workbench - instead an existing MongoDB instance that was configured at installation time is used. Depending on the MongoDB service used (Cloud, cluster or on-prem) different backup strategies are possible - see MongoDB Backup Methods. See Pre-installation tasks for how the used MongoDB instance is configured at install time. You can find the connection string of the MongoDB instance used in your installation by reading the secret k5-designer-mongodb in the OpenShift project your Solution Designer was deployed into:

oc -n <project of Solution Designer> get secret k5-designer-mongodb -o jsonpath='{.data.connectionString}'|base64 -d; echo

oc -n <project of Solution Designer> get cm k5-designer-bundle.v1 -o jsonpath='{.data.release}'|base64 -d |gzip -cd

Search for a structure like the following:

k5-designer-backend:
  mongoDb:
    dbName: <name of the designer mongodb>
k5-Git-integration-controller:
  mongoDb:
    dbName: <name of the db used to store Git repository server configuration>

IBM Financial Services Workbench uses a built-in minio s3 object storage service to provide local marketplace functionality, i.e. sharing of solutions created in Solution Designer as templates or stencils to create new solutions amongst users of Solution Designer. To preserve these shared assets the contents of the minio service need to be backed up as well. You can explore the contents of this store by retrieving the credentials from the cluster:

# Access Key
oc -n <project of Solution Designer> get secret k5-s3-storage-credentials -o jsonpath='{.data.accesskey}'|base64 -d; echo
# Secret Key
oc -n <project of Solution Designer> get secret k5-s3-storage-credentials -o jsonpath='{.data.secretkey}'|base64 -d; echo

In order to use them you need to expose the minio service via creation of a route and then use any s3 client i.e. minio client to list, retrieve and manipulate objects there. This can be used for backup purposes - alternatively you can make sure the persistent volume requested by PVC k5-s3-storage is backed up:

oc -n <project of Solution Designer> get pvc k5-s3-storage

One way to do this is described later.

All configuration data is stored in kubernetes resources, i.e. ConfigMaps and Secrets. This is the data you create either initially at installation-time or when configuring various (runtime-)aspects via configuration management, either via API or via the configuration management UI in Solution Hub. To back up this data you need to back up all the kubernetes resources in the relevant namespaces. See "General OpenShift/kubernetes backup concepts" for a suggestion on how to achieve that.

Authentication of users for Solution Designer is handled through Keycloak. Keycloak is not part of IBM Financial Services Workbench but is a pre-requisite for installation of the product. Depending on how you are providing Keycloak there might be different ways to back up user and Keycloak configuration data. See Keycloak Documentation for further information.

Solutions developed with Solution Designer are eventually deployed to provide business value. During execution of these services, data will be created and stored. By default, this data is stored in a MongoDB. This data will in general be the most critical data as it is the business data that your enterprise depends upon. Backing up this data is therefore essential. IBM Financial Services Workbench doesn't bring this MongoDB instance but relies on you providing the connection data to a MongoDB at installation time. You can find the configured connection data for the MongoDB by obtaining the value of the k5-default-document-storage-service-binding secret in the OpenShift project that serves as the deployment target for the solutions you develop (there can be more than one of those for different stages of development, testing, staging and production)

oc -n <deployment project> get secret k5-default-document-storage-service-binding -o jsonpath='{.data.binding}'|base64 -d;echo

Asynchronous communication and messaging of solutions uses kafka as the message transport. Kafka is again a service that is not an integral part of IBM Financial Services Workbench but a service you need to (optionally) provide for the solutions you develop. The messages or events that are exchanged via kafka can also contain business data and depending on your use case might be as critical as the business data stored in MongoDB. Specific recommendations on how to back up kafka are beyond the scope of this document and the necessity to have regular backups of the data in kafka depends on your use case and whether you have activated kafka for your solutions or not. Backing up streaming data systems like kafka is non-trivial and recommended best practices vastly depend on your use case. There are many discussions in the community about this. See e.g. Comparing Kafka Backup Solutions