Restore the database
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-apiand<release>-proxy. Confirm what is present withkubectl 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
For GCS backups with Workload Identity, configure the replacement deployment with access to the same
bucket and prefix. Grant bucket access to both its database and operator Kubernetes service accounts,
and use the same perconaServerMongoDB.backup and perconaServerMongoDB.serviceAccount values as
appropriate for the replacement environment. See
GCS Workload Identity.
After losing the deployment and its volumes, the old Kubernetes backup resource might no longer exist.
Use Percona’s restore-from-storage procedure rather than referencing a missing backupName. For PITR,
choose a time covered by a completed base backup and the stored oplog chunks. GKE validation included
deleting the deployment and volumes, reinstalling, and recovering to a chosen second with matching data.
Percona upgrade kit backup
For an archive taken by percona-upgrade/upgrade-percona.sh, use the matching restore script from the
installer kit after quiescing the platform. Run it from the shared directory where the kit and archive
are available:
./percona-upgrade/restore-percona-backup.sh <namespace> <release> <backup>.archive.gz
<!--NeedCopy-->
For example, with namespace default and release release:
./percona-upgrade/restore-percona-backup.sh default release <backup>.archive.gz
<!--NeedCopy-->
The script restores data only. It does not downgrade the operator, CRDs, MongoDB, or PBM. Continue with steps 3 and 4 below to bring the platform back and validate it. Once validated, remove the upgrade backup from the directory where it was created:
./percona-upgrade/delete-percona-backup.sh
<!--NeedCopy-->
For the complete upgrade sequence, see Upgrade.
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):
- MongoDB Atlas — restore a snapshot or point in time to the existing cluster or to a new cluster: https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-overview/
- Amazon DocumentDB — restore from a snapshot or point in time to a new cluster: https://docs.aws.amazon.com/documentdb/latest/developerguide/backup_restore.html
- Azure Cosmos DB for MongoDB — restore to a new account: https://learn.microsoft.com/en-us/azure/cosmos-db/restore-account-continuous-backup
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):
-
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. -
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:
- Confirm services start and connect to the database (check pod logs for MongoDB connection errors).
- Sign in and confirm organizations, projects, users, and workspaces are present.
- Confirm existing workspaces can be reattached.
- 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.