Back Up and Restore Tenable Security Center
Tenable recommends performing regular backups of your Tenable Security Center in Tenable Enclave Security data and configurations to ensure you can recover your environment in the event of hardware failure or data loss. By maintaining current backups, you can quickly restore your vulnerability management operations and minimize downtime.
Important Considerations
-
You must perform a restore on the exact version used for the backup. A version mismatch might not cause immediate errors, but it can lead to application issues later.
-
The namespace you use during a restore must be the same as the original deployment. Database names are templated based on the namespace; therefore, using a different namespace results in mismatched database names.
-
Stopping Tenable Security Center inside the container causes the Kubernetes liveness probe to fail, triggering an automatic pod restart once the failure threshold is reached. To prevent interruptions during backup and restore operations, you must temporarily disable the liveness probe before stopping Tenable Security Center.
Back up Tenable Security Center in Tenable Enclave Security
Back up a Tenable Security Center in Tenable Enclave Security deployment:
-
Scale sc-job-manager to 0 replicas:
Copykubectl scale deployment sc-job-manager -n tenable-enclave-security --replicas=0 -
Stop Tenable Security Center and all running processes:
Note: These commands stop all jobs, including scans, running on Tenable Security Center.
-
Disable the liveness probe to prevent Kubernetes from restarting the pod while Tenable Security Center is stopped:
CopyNS=tenable-enclave-security
IDX=$(kubectl get statefulset tenable-security-center -n $NS -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\n"}{end}' | grep -n '^sc-runtime-container$' | cut -d: -f1 | awk '{print $1-1}')
kubectl patch statefulset tenable-security-center -n $NS --type=json -p="[{\"op\": \"remove\", \"path\": \"/spec/template/spec/containers/${IDX}/livenessProbe\"}]" -
Log in to the Kubernetes runtime container:
Copykubectl exec -it tenable-security-center-0 -n tenable-enclave-security -- /bin/sh -
Stop Tenable Security Center:
Copy/scbase/SC.sh stop -
View all running processes:
Copyps -fu tns -
If any processes are listed, run the following commands to stop them:
Copykillall -u tns
killall httpd -
If necessary, repeat step e to confirm all processes are stopped.
-
-
Create a backup .tar file:
Copytar -Ppzcf /opt/sc_backup.tar.gz /opt/scNote: The .tar file switches are case-sensitive.
Tenable Security Center creates the sc_backup.tar.gz backup file in the /opt/sc directory.
-
Exit the container:
Copyexit -
Copy the backup file to your local working directory by running the following command from your local shell:
Copykubectl cp tenable-enclave-security/tenable-security-center-0:/opt/sc_backup.tar.gz -c sc-runtime-container sc_backup.tar.gzNote: Ensure your local directory has enough space for the backup file.
Tenable Security Center is backed up to your local directory.
-
Log in to the Kubernetes runtime container again:
Copykubectl exec -it tenable-security-center-0 -n tenable-enclave-security -- /bin/sh -
Remove the backup file from the /opt directory:
Copyrm /opt/sc_backup.tar.gz -
Exit the container:
Copyexit -
Depending on your next steps, scale down or restart Tenable Security Center:
Note: Do not leave Tenable Security Center stopped inside the pod without performing one of the actions described in this step.
-
If you are planning an immediate restore, scale the tenable-security-center StatefulSet to 0 to terminate the pod and prevent Kubernetes from restarting it:
Copykubectl scale statefulset tenable-security-center -n tenable-enclave-security --replicas=0Caution: Back up your PostgreSQL database before restoring.
-
If this is a periodic backup and you are not restoring now, scale sc-job-manager back to 1 replica:
Copykubectl scale deployment sc-job-manager -n tenable-enclave-security --replicas=1Then restart the tes-operator pod to restore the liveness probe and restart the Tenable Security Center StatefulSet:
Copykubectl delete po -n tenable-enclave-security <tes-operator-pod>
-
Back Up PostgreSQL Database
After you complete the Tenable Security Center backup, back up the PostgreSQL database connected to the instance before you restart Tenable Security Center or proceed with a restore. For steps, see the PostgreSQL backup documentation.
Restore Tenable Security Center in Tenable Enclave Security
Before you begin
-
Uninstall the existing Helm chart and delete the Tenable Security Center database secret:
Copyhelm uninstall -n tenable-enclave-security tes-operator tes
kubectl delete secret -n tenable-enclave-security sc-secrets -
Perform a fresh install of Tenable Security Center using the steps in Install Tenable Enclave Security.
Caution: The freshly installed version must exactly match the version used when the backup was created.
To restore Tenable Security Center from a backup file:
-
Scale sc-job-manager to 0 replicas:
Copykubectl scale deployment sc-job-manager -n tenable-enclave-security --replicas=0 -
Stop Tenable Security Center and all running processes:
-
Disable the liveness probe to prevent Kubernetes from restarting the pod while Tenable Security Center is stopped:
CopyNS=tenable-enclave-security
IDX=$(kubectl get statefulset tenable-security-center -n $NS -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\n"}{end}' | grep -n '^sc-runtime-container$' | cut -d: -f1 | awk '{print $1-1}')
kubectl patch statefulset tenable-security-center -n $NS --type=json -p="[{\"op\": \"remove\", \"path\": \"/spec/template/spec/containers/${IDX}/livenessProbe\"}]" -
Log in to the Kubernetes runtime container:
Copykubectl exec -it tenable-security-center-0 -n tenable-enclave-security -- /bin/sh -
Stop Tenable Security Center:
Copy/scbase/SC.sh stop -
View all running processes:
Copyps -fu tns -
If any processes are listed, run the following commands to stop them:
Copykillall -u tns
killall httpdNote: These commands stop all jobs (including scans) running on Tenable Security Center.
-
If necessary, repeat step e to confirm all processes are stopped.
-
-
Exit the container:
Copyexit -
Confirm that sc_backup.tar.gz is present in your local working directory.
-
Copy the backup file into the container by running the following command from your local shell:
Copykubectl cp sc_backup.tar.gz tenable-enclave-security/tenable-security-center-0:/opt/sc_backup.tar.gz -c sc-runtime-container -
Log in to the Kubernetes runtime container:
Copykubectl exec -it tenable-security-center-0 -n tenable-enclave-security -- /bin/sh -
Restore Tenable Security Center from the backup file:
Copytar -Pxvf /opt/sc_backup.tar.gz -
Remove the backup file from the /opt directory:
Copyrm /opt/sc_backup.tar.gz -
Exit the container:
Copyexit -
Update .pgvars with the new PostgreSQL password.
The restored backup overwrites .pgvars with the old PostgreSQL password from the source instance. The freshly installed instance has a new password — update SC_PG_PASSWORD in /opt/sc/.pgvars to reflect this before starting Tenable Security Center.
Retrieve the new PostgreSQL password from the Kubernetes secrets in the deployment namespace (see Credential reference), then update the file:
Copy# Get the new Postgres password from the sc-secrets Kubernetes secret
NEW_PG_PASSWORD=$(kubectl get secret sc-secrets -n tenable-enclave-security -o jsonpath='{.data.SC_DB_PASSWORD}' | base64 -d)
# Update .pgvars inside the SC pod
kubectl exec tenable-security-center-0 -n tenable-enclave-security -c sc-runtime-container -- sed -i "s/^export SC_PG_PASSWORD=.*/export SC_PG_PASSWORD=${NEW_PG_PASSWORD}/" /opt/sc/.pgvars
# Verify
kubectl exec tenable-security-center-0 -n tenable-enclave-security -c sc-runtime-container -- grep "^export SC_PG_PASSWORD=" /opt/sc/.pgvars -
Scale the tenable-security-center StatefulSet to 0 to terminate the pod while the PostgreSQL restore completes:
Copykubectl scale statefulset tenable-security-center -n tenable-enclave-security --replicas=0
Restore PostgreSQL Database
After you restore the Tenable Security Center files and scale down the pods, restore the PostgreSQL database before restarting Tenable Security Center.
-
Always restore using the DB superuser, not the application user
The application DB user does not have superuser privileges. Running pg_restore as the app user fails when replaying SET ROLE statements used to reassign object ownership. Always use the database superuser for the restore. The superuser credentials (host, port, username, password) are stored in the Kubernetes secrets in the deployment namespace.
-
Do not use --no-owner or --no-privileges flags
Omit these flags so that pg_restore replays object ownership (ALTER ... OWNER TO) and privilege grants (GRANT) exactly as they were in the source database. Using these flags silently drops ownership assignments and access controls, which can cause application errors after the restore.
-
The application user does not need manual setup after restore
If the application DB user pre-existed on the database instance (that is, the restore process did not drop it), it retains its existing password and privileges. You do not need to run CREATE USER, ALTER USER, or GRANT manually. Verify connectivity using the application user credentials available in the Kubernetes secrets and ConfigMaps in the deployment namespace.
-
Credential Kubernetes Resource Key DB host & port
tes-pg-secrets (Secret)
pg_host
Superuser username
tes-pg-secrets (Secret)
pg_user
Superuser password
tes-pg-secrets (Secret)
pg_pass
App DB username
sc-config-map (ConfigMap)
TES_SC_USER
App DB name
sc-config-map (ConfigMap)
TES_SC_DB_NAME
App DB password
sc-secrets (Secret)
SC_DB_PASSWORD
Restart Tenable Security Center
After you complete the PostgreSQL restore, scale sc-job-manager and the tenable-security-center StatefulSet back to 1:
kubectl scale deployment sc-job-manager -n tenable-enclave-security --replicas=1
kubectl scale statefulset tenable-security-center -n tenable-enclave-security --replicas=1
Tenable Security Center starts automatically as the pod comes up.