Skip to main content

Backup and restore

This page explains where design-time data lives in IBM DevOps Solution Workbench, what the product database is for, and how to plan backups and restore. The sections below on Git, the designer’s database, Kubernetes configuration, and Keycloak are the single place to read about what to back up in design time.

How design-time data is stored​

LayerRoleYour responsibility
GitSource of truth for project content: models, implementation, and project configuration committed by usersOperate and back up your Git server(s) as for any development platform. Commit changes regularly—the same habit as with a local IDE: small, frequent commits limit how much work exists only in a working copy.
Product databaseStores administrative design-time data for project baselines and OML profiles (metadata, lifecycle, and content managed in Admin Settings)Backups are required if you must recover baseline and profile configuration without re-importing from archives.

What the database stores (design-time): administrative records for baselines and OML profiles uploaded and managed in the workbench, plus the working MongoDB-style databases the designer uses (still design-time: uncommitted work until users push to Git).

Do not use the product’s database as a separate integration point for unrelated systems, analytics, or ad-hoc access outside IBM DevOps Solution Workbench. The contract is use through the product only.

Options for storing design-time data​

The following options refer to the product database used for the design-time data of workbench.

Option 1: The product internal database​

By default, the Helm chart deploys a single StatefulSet (k5-database-postgresql) that runs PostgreSQL (with document capabilities) and FerretDB together. Applications that speak the MongoDB wire protocol connect through FerretDB; physical persistence and backup operations are PostgreSQL at the data directory level. The binding used by the product is the k5-designer-mongodb secret—see Product database.

FerretDB can be treated as a black box for standard use: you do not need a dedicated database administrator to operate the product. Day-to-day operation and optimization is usually not necessary.

⚠warning

It is not a general-purpose datastore for your own applications or reporting.

⚠warning

The product internal database deployment is not an out-of-the-box highly available cluster

Option 2: Bring your own FerretDB and PostgreSQL​

This option is the right one, if you have further requirements like high-availability or operating in a separate cluster, multi-cluster, that exceed the default capabilities. For this option, you have to run and tune your own instance and operate the service yourself.

Disable the built-in product database, provide the k5-designer-mongodb secret, and use your backup, monitoring, and recovery procedures. That service is not part of the IBM DevOps Solution Workbench deliverable; you remain responsible for the full lifecycle.

Option 3: Bring your own mongoDB​

As alternative top option 2 you can also bring your own mongoDB and re-use e.g. an already existing service. For this option, you have to run and tune your own instance and operate the service yourself.

Disable the built-in product database, provide the k5-designer-mongodb secret with the connection string , and use your backup, monitoring, and recovery procedures. That service is not part of the IBM DevOps Solution Workbench deliverable; you remain responsible for the full lifecycle.

Backup and restore​

IBM DevOps Solution Workbench does not ship a built-in feature that schedules database backups and writes them to a chosen external destination (for example NFS, S3 or another object store, or a specific backup appliance). Implementing scheduled dumps or snapshots—and where those files live—is your operational decision. Each backup target is a separate dependency: you must supply and maintain the share, bucket, object store, or platform backup tooling, in addition to the product itself. The sections below are procedural examples (for example pg_dump, CronJob, OADP/Velero) that you can wire to the storage and automation your site already uses.

Why Git and the database both matter​

  • Git is where committed design and code must live for long-term recovery and team collaboration. Backup Git according to your enterprise standards.
  • The product database holds design-time baseline and OML profile administration and in-flight designer state (until committed to Git). Losing it without backup can mean rebuild work: re-upload baselines/profiles and, for uncommitted work, data that existed only in the database until the last Git push.

Configuration in Kubernetes (ConfigMaps, Secrets) for the installation also needs a backup strategy. This also applies to the OIDC provider, which is used for workbench.

Sample maintenance: backup PostgreSQL (default stack)​

The built-in stack persists data in PostgreSQL. A common approach is to run pg_dump on a schedule from a Job or CronJob in the same namespace, or to use your platform backup tooling (for example the OADP Operator).

Example: one-off logical dump (adjust namespace, pod name, container name, and credentials to match your release)

# Replace with your product namespace, e.g. workbench
NAMESPACE=<product-namespace>
# Pod for the built-in DB usually follows the StatefulSet name from the installation (see the StatefulSet in your namespace)
oc get pod,statefulset -n "$NAMESPACE" | grep -E 'k5-database|NAME'
# Run pg_dump in the running PostgreSQL pod; pick POD and CONTAINER from "oc get pod -o wide" / "oc describe pod"
POD=$(oc get pod -n "$NAMESPACE" -o name | grep k5-database-postgresql | head -1 | cut -d/ -f2)
CONTAINER=$(oc get pod -n "$NAMESPACE" "$POD" -o jsonpath='{.spec.containers[0].name}')

oc exec -n "$NAMESPACE" "$POD" -c "$CONTAINER" -- \
  sh -c 'pg_dump -U "${POSTGRES_USER:-postgres}" -d "${POSTGRES_DB:-postgres}" -Fc' \
  > "k5-postgres-backup-$(date +%Y%m%d).dump"
ℹ️note

The StatefulSet is documented as k5-database-postgresql in a default install. If your release adds a name prefix, adjust the grep pattern. Inspect the pod if pg_dump fails (user/database env vars, extra containers).

Scheduling the same pg_dump

  • Automation outside the cluster: a nightly CI job, Ansible, or cron on a bastion that runs the one-off oc/kubectl exec commands and uploads the file to object storage. No extra workload in the cluster; uses credentials you already have for oc login.
  • Automation inside the cluster: a CronJob with an image that includes oc or kubectl (for example a Red Hat UBI-based image with the OpenShift CLI, or a corporate “toolbox” image), a ServiceAccount that has pods/pods/exec on the product namespace, and a script that mirrors the one-off example; write the stream to a mounted volume, then curl/CLI-upload to S3, or use an object-storage CSI sidecar. Keep retention and network egress under your org’s rules.
  • Storage-level backup: snapshot the PostgreSQL PVC with OADP / Velero so the data directory is restorable without running pg_dump (test restore: filesystem consistency for PostgreSQL still applies; prefer application-consistent backup procedures from your DBA or vendor).

If you run pg_dump from a PostgreSQL client image in-cluster, point it at the ClusterIP Service in front of k5-database-postgresql and supply the database user, password, and name from the Secrets created by the Helm release (inspect the StatefulSet/Secret in your namespace; do not use placeholder credentials).

Restore​

Restore is the inverse: pg_restore (or your snapshot restore process) into a clean volume per PostgreSQL’s documentation, followed by a coordinated product rollout. Always test in a non-production namespace first.

See also​