Backup and Restore

Back up and restore Policy Workbench data on AWS.

1: Backing up the Policy Workbench
2: Restoring the Policy Workbench

This section describes how to back up Policy Workbench data on AWS and restore it from an existing backup.

1 - Backing up the Policy Workbench

Back up Policy Workbench data for AWS to an encrypted AWS S3 bucket using a scheduled or manual Velero backup.

By default, the Policy Workbench data is backed up on a daily basis using a scheduled backup, after the Policy Workbench has been installed. The backed-up data includes the Kubernetes object state and the persistent volume data. The backed-up data is automatically stored in the encrypted AWS S3 bucket that you created when you deployed PPC.

For more information about the AWS S3 bucket, refer to Creating AWS KMS Key and S3 Bucket.

You can also choose to manually back up the data to the AWS S3 bucket using Velero.

Important: Before you manually back up the data, ensure that Velero CLI version 1.18 or later is installed.

To manually back up the data:

Run the following command on the jump box:

velero backup create --from-schedule workbench-backup-schedule -n <Namespace where data is backed up>

For example:

velero backup create --from-schedule workbench-backup-schedule -n pty-backup-recovery

The following output appears:

INFO[0001] No Schedule.template.metadata.labels set - using Schedule.labels for backup object  backup=pty-backup-recovery/workbench-backup-schedule-20260331094735 labels="map[app.kubernetes.io/managed-by:Helm deployment:policy-workbench]"
Creating backup from schedule, all other filters are ignored.
Backup request "workbench-backup-schedule-20260331094735" submitted successfully.
Run `velero backup describe workbench-backup-schedule-20260331094735` or `velero backup logs workbench-backup-schedule-20260331094735` for more details.

For more information about the velero backup command, refer to Backup Reference in the Velero documentation.

Run the following commands to monitor the backup status.

Run the following command to retrieve the list of existing backups:

velero backup get -n pty-backup-recovery

The following output appears:

NAME                                               STATUS                       ERRORS   WARNINGS   CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
authnz-postgresql-schedule-backup-20260331093017   Completed                    0        0          2026-03-31 09:30:18 +0000 UTC   59d       default            app.kubernetes.io/persistence=enabled
workbench-backup-schedule-20260331094735           WaitingForPluginOperations   0        0          2026-03-31 09:47:38 +0000 UTC   59d       default            <none>
workbench-backup-schedule-20260331094704           WaitingForPluginOperations   0        0          2026-03-31 09:47:04 +0000 UTC   59d

Run the following command to obtain details of a specific backup:

velero backup describe <backup-name> -n pty-backup-recovery

The following code block shows a snippet of the output:

Name:         workbench-backup-schedule-20260331094735
Namespace:    pty-backup-recovery
Labels:       app.kubernetes.io/managed-by=Helm
            deployment=policy-workbench
            velero.io/schedule-name=workbench-backup-schedule
            velero.io/storage-location=default
Annotations:  meta.helm.sh/release-name=policy-workbench
            meta.helm.sh/release-namespace=policy-workbench
            velero.io/resource-timeout=10m0s
            velero.io/source-cluster-k8s-gitversion=v1.35.2-eks-f69f56f
            velero.io/source-cluster-k8s-major-version=1
            velero.io/source-cluster-k8s-minor-version=35

Phase:  WaitingForPluginOperations

Run the following command to obtain the log details for a specific backup:

velero backup logs <backup-name> -n pty-backup-recovery

The following code block shows a snippet of the output:

time="2026-03-31T09:47:38Z" level=info msg="Setting up backup temp file" backup=pty-backup-recovery/workbench-backup-schedule-20260331094735 logSource="pkg/controller/backup_controller.go:690"
time="2026-03-31T09:47:38Z" level=info msg="Setting up plugin manager" backup=pty-backup-recovery/workbench-backup-schedule-20260331094735 logSource="pkg/controller/backup_controller.go:697"
time="2026-03-31T09:47:38Z" level=info msg="Getting backup item actions" backup=pty-backup-recovery/workbench-backup-schedule-20260331094735 logSource="pkg/controller/backup_controller.go:701"

2 - Restoring the Policy Workbench

Restore the Policy Workbench data for AWS using an existing backup.

Before you begin

Before starting a restore, ensure that the following prerequisites are met:

An existing backup is available. Backups are taken automatically as part of the default installation of the Policy Workbench using scheduled backup mechanisms. The backups are available in the encrypted AWS S3 bucket that you created when you deployed Policy Workbench. You can also manually back up the data.
For more information about the AWS S3 bucket, refer to Creating AWS KMS Key and S3 Bucket.
For more information about manually backing up the data, refer to Backing up the Policy Workbench for AWS.
A restored PPC cluster is required for both module-managed and self-managed Workbench resources. For information about restoring the PPC, refer to Restoring the PPC for AWS.
Note: You can restore the Policy Workbench without first restoring the PPC if only the Policy Workbench is corrupted.
Important: Before you restore the data, ensure that Velero CLI version 1.18 or later is installed.

Restore the Policy Workbench data

To restore the data:

Ensure that the main.tf file in the root module, which is the working directory for executing the OpenTofu commands, contains the following code block. If the root module is not available, create a root module with the main.tf file:

module "policy_workbench" {
  source = "oci://<Container_Registry_Path>/policy-workbench/opentofu/modules/policy-workbench/<cloud>?tag=<version>"

  cluster_name = var.cluster_name
}

variable "cluster_name" {
  type        = string
  description = "EKS cluster name."
  nullable    = false

  validation {
    condition     = length(trimspace(var.cluster_name)) > 0
    error_message = "cluster_name must be provided and cannot be empty."
  }
}

Note: For the Protegrity Container Registry, set <Container_Registry_Path> to registry.protegrity.com:9443. For a local registry, set it to the local registry endpoint.

This code block adds the Policy Workbench OpenTofu module.

Run the following commands on the jump box.
Note: You do not need to run these commands if you only uninstall Policy Workbench and delete the namespace. These commands are required if you destroy the Policy Workbench cluster using tofu destroy. They are also required if you are restoring to a new PPC cluster where Policy Workbench was not previously installed.
```
tofu init
tofu plan -var="cluster_name=<Restored-PPC-cluster-name>"
tofu apply -var="cluster_name=<Restored-PPC-cluster-name>" 
```
Specify the name of the restored PPC cluster as the value of the cluster_name variable.
For information about restoring the PPC, refer to Restoring the PPC for AWS.

Run the following command on the jump box:

velero restore create workbench-restore-$(date +%Y%m%d-%H%M%S) \
 --from-backup <backup-name> \
 -n pty-backup-recovery --wait

For example:

velero restore create workbench-restore-$(date +%Y%m%d-%H%M%S) \
 --from-backup workbench-backup-schedule-20260331094735 \
 -n pty-backup-recovery --wait

For more information about the velero restore command, refer to Restore Reference in the Velero documentation.

Run the following command to list all the restore operations in the specific namespace:
```
velero restore get -n pty-backup-recovery
```
Ensure that the status of the restore operation is WaitingForPluginOperations.

Run the following command to annotate the Kubernetes resources:

kubectl annotate productconfiguration workbench -n pty-admin kopf.zalando.org/last-handled-configuration- --overwrite

The following output appears if the annotation is added successfully:

productconfiguration.pty.com/workbench annotated

Run the following commands to monitor the restore status.
1. Run the following command to retrieve the list of existing restores:
```
velero restore get -n pty-backup-recovery
```
2. Run the following command to obtain details of a specific restore:
```
velero restore describe workbench-restore-<timestamp> -n pty-backup-recovery
```
3. Run the following command to obtain the log details for a specific restore:
```
velero restore logs workbench-restore-<timestamp> -n pty-backup-recovery
```
  Note: Verify that the log output contains no entries with level=error. Entries with level=warning are acceptable and do not indicate a restore failure.

Uninstall Policy Workbench before restoring on the same cluster

Note: Perform these steps only if you are restoring the Policy Workbench on the same cluster where it was previously installed. If you are restoring to a new cluster, skip this section.

Uninstall the policy-workbench module from the existing PPC cluster by running the following command on the jump box:
```
helm uninstall policy-workbench -n <namespace>
```
For example:
```
helm uninstall policy-workbench -n policy-workbench
```
The following output appears if the module is uninstalled successfully:
```
release "policy-workbench" uninstalled
```
Delete the namespace where the Policy Workbench is installed by running the following command on the jump box:
```
kubectl delete namespace <namespace>
```
For example:
```
kubectl delete namespace policy-workbench
```
The following output appears if the namespace is deleted successfully:
```
namespace "policy-workbench" deleted
```