Product documentation
Citrix SecurSpaces™
View PDF

Restore the database

August 19, 2026
Contributed by: 
T

Restoring the Citrix SecurSpaces™ database requires a maintenance window: the platform must be quiesced so services do not write to the database mid-restore. The procedure for step 2 depends on your hosting model.

Step 1: Quiesce the platform

Scale the SecurSpaces services down so nothing writes to the database during the restore. The MongoDB deployment itself stays running.

# Stop the SecurSpaces application services (leave MongoDB running)
kubectl scale deployment \
  <release>-central-service <release>-workspace-api <release>-coordinator \
  <release>-frontend <release>-proxy \
  --replicas=0 -n <namespace>
<!--NeedCopy-->

Note These are the five service Deployments on a primary SecurSpaces platform. An external region deployment runs only <release>-workspace-api and <release>-proxy. Confirm what is present with kubectl get deploy -n <namespace> before scaling.

Step 2: Restore the data

Internal Percona MongoDB — from a PBM backup

Use the Percona Operator restore workflow: create a PerconaServerMongoDBRestore resource that references the backup by name (or a point in time) and wait for the operator to complete the restore. Save as sds-restore.yaml:

apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDBRestore
metadata:
  name: sds-restore-2026-07-02
  namespace: <namespace>
spec:
  clusterName: <release>-psmdb-db
  backupName: sds-backup-2026-07-02        # the PerconaServerMongoDBBackup to restore
<!--NeedCopy-->

kubectl apply -f sds-restore.yaml
kubectl get psmdb-restore -n <namespace>   # wait for STATUS: ready
<!--NeedCopy-->

For point-in-time restores and full options, see the Percona restore documentation: https://docs.percona.com/percona-operator-for-mongodb/backups-restore.html

Internal Percona MongoDB — from a mongodump archive

Target the primary replica-set member:

# Identify the current primary
kubectl get psmdb
kubectl exec -it <pod>-rs0-0 -- mongosh \
  --authenticationDatabase admin --username <admin-user> --password <admin-password>

# Copy the archive to the primary pod
kubectl cp strong-network-backup.gz <primary-pod>:/tmp/strong-network-backup.gz

# Restore the strong-network database into the quiesced platform
kubectl exec -it <primary-pod> -- mongorestore \
  --nsInclude='strong-network.*' \
  --username <admin-user> --password <admin-password> \
  --authenticationDatabase admin \
  --gzip --archive=/tmp/strong-network-backup.gz
<!--NeedCopy-->

If you are restoring into a freshly provisioned database (for example, after moving from a single MongoDB pod to a Percona replica set), you may also need to recreate the application database user so SecurSpaces can connect:

kubectl exec -it <primary-pod> -- mongosh \
  --authenticationDatabase admin --username <admin-user> --password <admin-password> \
  --eval "db.createUser({user: '<app-user>', pwd: '<app-password>', roles: [{ db: 'strong-network', role: 'readWrite' }], mechanisms: ['SCRAM-SHA-1']});" \
  strong-network
<!--NeedCopy-->

Hosted MongoDB — restore with the provider tooling

Restore the snapshot or point in time using the provider’s console or CLI, then note the connection endpoint of the restored deployment (it is often a new host):

Step 3: Point SecurSpaces at the restored database

SecurSpaces reads its MongoDB connection settings from Helm values, which the chart renders into MONGO_DB_HOST, MONGO_DB_PORT, MONGO_DB_NAME, MONGO_DB_USER, and MONGO_DB_PASSWORD environment variables on the service pods. You change the target database by updating those values and running helm upgrade.

If you restored to a hosted service or a new endpoint (external MongoDB):

  1. In your Helm values file, make sure SecurSpaces is in external-MongoDB mode and update the connection details:

    mongodbAuth:
  source: "external"

platform:
  deployPerconaMongoDB: false
  deployBitnamiMongoDB: false
  externalMongodb:
    hostName: "<restored-cluster-host>"     # new endpoint from the restore
    port: "27017"
    protocol: "mongodb+srv"                 # or "mongodb"
    additionalParameters: "retryWrites=true&w=majority"
    authMechanism: "SCRAM"                  # or "MONGODB-X509"
    auth:
      database: "strong-network"
      username: "<db-user>"
      password: "<db-password>"
<!--NeedCopy-->

    For certificate-based (X.509) authentication, set the certificate fields instead of username/password. See Configure external MongoDB with X.509 authentication.

  2. Apply the change:

    helm upgrade <release> <chart> -n <namespace> -f <your-values.yaml>
<!--NeedCopy-->

If you restored the internal Percona database in place:

The service endpoint is unchanged (<release>-psmdb-db-rs0.<namespace>.svc.cluster.local), so you usually do not need to change connection values. If credentials changed, update the <release>-psmdb-secrets Secret accordingly.

Step 4: Bring the platform back up and validate

# Scale the services back up (use your normal replica counts)
kubectl scale deployment \
  <release>-central-service <release>-workspace-api <release>-coordinator \
  <release>-frontend <release>-proxy \
  --replicas=1 -n <namespace>

# Or force a fresh rollout so pods pick up new connection settings
kubectl rollout restart deployment -n <namespace>
<!--NeedCopy-->

Then validate the platform:

  1. Confirm services start and connect to the database (check pod logs for MongoDB connection errors).
  2. Sign in and confirm organizations, projects, users, and workspaces are present.
  3. Confirm existing workspaces can be reattached.
  4. If you use HashiCorp Vault, confirm secrets resolve correctly.

Important A backup you have never restored is not a backup. Test your full restore procedure regularly in a non-production environment so you can rely on it during an incident.

Restore the database
August 19, 2026
Contributed by: 
T
August 19, 2026
Contributed by: 
T

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.