Citrix SecurSpaces™

Back up the database

August 19, 2026

Contributed by:

Back up the Citrix SecurSpaces™ database before upgrades, migrations, and major configuration changes, and on a recurring schedule in production. If you use HashiCorp Vault for secrets, back up Vault on the same schedule.

On-premises and self-managed (internal Percona MongoDB)

Important:

Backups are disabled by default on the internal database. If you run it in production, enabling, scheduling, and restore-testing them is your responsibility. See The SecurSpaces database.

Use Percona Backup for MongoDB (PBM) as your primary, scheduled backup mechanism. Use a manual mongodump only as a secondary, point-in-time snapshot before a specific change.

Primary: Percona Backup for MongoDB (PBM)

PBM is the backup tool built into the Percona Operator. It supports on-demand and scheduled logical and physical backups and point-in-time recovery to an external object store (Amazon S3, Azure Blob Storage, Google Cloud Storage, or any S3-compatible store).

SecurSpaces ships PBM as part of the internal Percona deployment, so backups are fully available — you just have to turn them on. In the default SecurSpaces configuration, backups are disabled (backup.enabled: false in the PerconaServerMongoDB custom resource, with the PBM image already present). Enabling PBM is a supported operation: you configure a backup storage target and set backup.enabled: true on the PerconaServerMongoDB resource. This is done at the Percona custom-resource level rather than through a dedicated SecurSpaces Helm value, and exposing these settings as Helm values is not planned — editing the custom resource is the supported method. A helm upgrade does not revert these custom-resource backup edits.

Follow the Percona Operator backup documentation for the authoritative reference:

Backups overview: https://docs.percona.com/percona-operator-for-mongodb/backups.html
Configure storage: https://docs.percona.com/percona-operator-for-mongodb/backups-storage.html
On-demand backups: https://docs.percona.com/percona-operator-for-mongodb/backups-ondemand.html
Scheduled backups: https://docs.percona.com/percona-operator-for-mongodb/backups-scheduled.html

Example: enable PBM and back up to Amazon S3

This worked example follows the Percona Operator storage guide. Replace <release> with your SecurSpaces Helm release name and <namespace> with your SecurSpaces namespace. Run kubectl get psmdb -n <namespace> to confirm your cluster name — for SecurSpaces it is <release>-psmdb-db.

1. Create a Secret with your S3 credentials. Save as backup-s3-secret.yaml (the values are base64-encoded automatically when you use stringData):

apiVersion: v1
kind: Secret
metadata:
  name: sds-backup-s3
type: Opaque
stringData:
  AWS_ACCESS_KEY_ID: "<your-access-key-id>"
  AWS_SECRET_ACCESS_KEY: "<your-secret-access-key>"
<!--NeedCopy-->

kubectl apply -f backup-s3-secret.yaml -n <namespace>
<!--NeedCopy-->

2. Enable backups and define the storage on the Percona custom resource. Edit the SecurSpaces PerconaServerMongoDB resource and set spec.backup.enabled: true and a storage entry that references the Secret:

kubectl edit psmdb <release>-psmdb-db -n <namespace>
<!--NeedCopy-->

spec:
  backup:
    enabled: true                      # was false in the default SecurSpaces deployment
    image: "percona/percona-backup-mongodb:2.8.1"
    storages:
      s3-primary:
        type: s3
        s3:
          bucket: <your-backup-bucket>
          region: <your-region>        # for example, eu-central-1
          prefix: sds/strong-network   # optional sub-folder in the bucket
          credentialsSecret: sds-backup-s3
<!--NeedCopy-->

Note On AWS EKS you can grant bucket access with an IAM role for the service account (IRSA) and omit credentialsSecret. For Azure Blob or Google Cloud Storage, use the azure or gcp storage type instead of s3 — see the Percona storage guide.

3. Take an on-demand backup. Create a PerconaServerMongoDBBackup resource that references your cluster and storage. Save as sds-backup.yaml:

apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDBBackup
metadata:
  name: sds-backup-2026-07-02
  namespace: <namespace>
spec:
  clusterName: <release>-psmdb-db
  storageName: s3-primary
  type: logical                        # logical is the default; physical is also supported
<!--NeedCopy-->

kubectl apply -f sds-backup.yaml
<!--NeedCopy-->

4. Verify the backup completed. Track the backup resource until STATUS is ready:

kubectl get psmdb-backup -n <namespace>
<!--NeedCopy-->

NAME                   CLUSTER              STORAGE      DESTINATION                          TYPE      STATUS   AGE
sds-backup-2026-07-02  <release>-psmdb-db   s3-primary   s3://<bucket>/sds/strong-network/… logical   ready    2m
<!--NeedCopy-->

5. (Recommended) Add a schedule and point-in-time recovery. For ongoing protection, add a backup task and enable PITR on the same spec.backup section:

spec:
  backup:
    enabled: true
    pitr:
      enabled: true                    # continuous point-in-time recovery
    tasks:
      - name: daily-s3
        enabled: true
        schedule: "0 2 * * *"          # every day at 02:00 (cron)
        storageName: s3-primary
        keep: 7                        # retain the 7 most recent scheduled backups
<!--NeedCopy-->

Apply the change with another kubectl edit psmdb (or kubectl apply) and confirm new backups appear on schedule. As a best practice, store backups in a different failure domain from the cluster — a separate cloud region or account — so that a cluster or region failure does not also destroy your backups.

Note The SecurSpaces chart does not expose these backup settings as Helm values, and exposing them is not planned. You configure PBM directly on the PerconaServerMongoDB custom resource as shown above. A helm upgrade does not revert these custom-resource backup edits, so your PBM configuration persists across SecurSpaces upgrades.

Secondary: logical snapshot with `mongodump`

mongodump / mongorestore are the official MongoDB database tools, and SecurSpaces uses them in its own replica-set migration procedure, so this is a supported method — not a workaround.

It is safe for ad hoc, quiesced snapshots (for example, immediately before an upgrade) when you follow these rules:

Quiesce writes before you dump, or dump from a secondary member. mongodump is only guaranteed consistent across collections when the database is not being written to. The simplest way to get a clean snapshot is to scale the SecurSpaces services to 0 first (the same quiesce step used in the restore procedure), then dump. mongodump cannot produce a cross-collection point-in-time snapshot of a single database on a live system — for online, point-in-time backups, use PBM instead.
Store the archive off-cluster and protect it (it contains encrypted secrets unless you use Vault).
Restore only into a quiesced platform (see the restore section), and never use destructive flags such as --drop against a live, in-use database.

It is not a replacement for scheduled, point-in-time disaster recovery — PBM (internal) or your managed service’s backups remain the primary strategy. Use mongodump to capture a known-good snapshot before a risky change.

# Identify the Percona pods
kubectl get psmdb
kubectl get pods -l app.kubernetes.io/name=percona-server-mongodb

# Confirm which pod is primary (look for "[direct: primary]" in the prompt)
kubectl exec -it <pod>-rs0-0 -- mongosh \
  --authenticationDatabase admin --username <admin-user> --password <admin-password>

# Dump the strong-network database from the primary (quiesce writes first)
kubectl exec -it <primary-pod> -- mongodump \
  --db strong-network \
  --username <admin-user> --password <admin-password> \
  --authenticationDatabase admin \
  --gzip --archive=/tmp/strong-network-backup.gz

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

For tool reference, see the MongoDB documentation for mongodump: https://www.mongodb.com/docs/database-tools/mongodump/

Hosted MongoDB services

When you use a managed MongoDB service, the provider supplies the backup tooling. Enable and configure it according to your recovery objectives (RPO/RTO).

SecurSpaces supports hosted MongoDB services on all three major hyperscalers (AWS, Azure, and Google Cloud). MongoDB Atlas is available on all three and is the option the SecurSpaces deployment guides reference. Use Atlas Cloud Backups with continuous (point-in-time) backup enabled:

Atlas Cloud Backups overview: https://www.mongodb.com/docs/atlas/backup/cloud-backup/overview/
Atlas restore overview: https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-overview/

If you use a cloud-native, MongoDB-compatible service instead of Atlas, enable its backup feature using the provider documentation below.

Platform	Service	Official backup documentation
AWS	Amazon DocumentDB, or MongoDB Atlas on AWS	Backing up and restoring in Amazon DocumentDB · Atlas Cloud Backups
Azure	Azure Cosmos DB for MongoDB, or MongoDB Atlas on Azure	Online backup and on-demand restore (Cosmos DB) · Reliability in Azure Cosmos DB for MongoDB (vCore)
GCP	MongoDB Atlas on Google Cloud	Atlas Cloud Backups. Google Cloud has no first-party managed MongoDB.

General guidance for hosted services:

Turn on continuous / point-in-time backup, not just daily snapshots, to minimize data loss.
Set a retention period that meets your compliance and recovery requirements.
Periodically test restoring a snapshot into a non-production cluster.

The official version of this product documentation is in English. Any non-English version is solely provided for your convenience and may include machine-translated content. For more information, please refer to the Machine Translation Disclaimer on Cloud Software Group home.

Was this helpful

Back up the database

August 19, 2026

Contributed by:

August 19, 2026

Contributed by:

Back up the database

On-premises and self-managed (internal Percona MongoDB)

Primary: Percona Backup for MongoDB (PBM)

Example: enable PBM and back up to Amazon S3

Secondary: logical snapshot with mongodump

Hosted MongoDB services

Related information

In this article

Secondary: logical snapshot with `mongodump`