PowerConnect for SAP Solutions
Auto Light Dark
Auto Light Dark

KB 243 - Backup and Restore PowerConnect Cloud on SAP Cloud Foundry

KB 243 (CLOUD): Backup and Restore PowerConnect Cloud on SAP Cloud Foundry


Category: Information

Priority: Normal

Platform: Cloud

Version: 1 from 05.08.2026

Backing up PowerConnect Cloud on SAP Cloud Foundry

Applies to: 9.2.0 · Category: Operations

For installs running on Cloud Foundry with an objectstore service bound, on any version.

On SAP Cloud Foundry the container filesystem is ephemeral, so everything durable already lives in the object store. A backup is a copy of those objects - no PowerConnect tooling is involved.

You will need:

  • the cf CLI, logged in to the org and space the application runs in;

  • a client for your object store - aws (AWS CLI), gsutil or gcloud storage (Google Cloud SDK), or az (Azure CLI), matching the bound service's plan. Any S3/GCS/Azure-compatible client will do; the commands below use the vendor CLIs. The provider's web console works for a one-off, but scripted copies are easier to verify and to repeat.

Before you start

Collect three things. The objects alone are not a usable backup.

cf env powerconnect-cloud > pc-env.txt

What

Where it comes from

Bucket / container name

VCAP_SERVICES.objectstore[0].credentials (see the table below)

Object store credentials

the same credentials block

POWERCONNECT_SECRET

the app's env: block - not in the bucket

POWERCONNECT_SECRET unlocks the keystore. Every input/output credential, client
certificate and private key in the install is encrypted with it. Without it the
restored keystore cannot be opened and every credential has to be re-entered by hand.
Store it with the backup, protected to the same standard.

The provider and bucket come from the bound service, not from environment variables - the objectstore plan determines both:

Plan

Provider

Bucket / container

Credentials

s3-standard

AWS S3

credentials.bucket

access_key_id, secret_access_key

gcs-standard

Google Cloud Storage

credentials.bucket

base64EncodedPrivateKeyData

azure-standard

Azure Blob

credentials.container_name

account_name, sas_token, container_uri

The prefix is separate and comes from the DATASTORE_PREFIX environment variable. If it is unset, the objects sit at the root of the container.

What should be in the bucket

Under the prefix, or at the container root if there is no prefix:

engine.edn           inputs.edn        outputs.edn       routes.edn
sso.edn              lookups.edn       connections.edn   plugins.edn
auth.edn             api-clients.edn
secrets.edn          powerconnect.keystore
checkpoints.edn
drivers/*.jar

Not all are guaranteed present - api-clients.edn exists only if API clients have been created, and drivers/ only if a JDBC driver has been uploaded. But if inputs.edn,outputs.edn, secrets.edn or powerconnect.keystore is missing, the prefix is wrong.
Check it before treating the copy as a backup.

Back up

Set these from the values gathered above. Leave PREFIX empty if the app has noDATASTORE_PREFIX.

export BUCKET=<bucket or container name>
export PREFIX=
export DEST=./pc-backup-$(date -u +%Y%m%dT%H%M%SZ)

AWS S3

aws s3 sync "s3://$BUCKET/$PREFIX" "$DEST/"

Google Cloud Storage

mkdir -p "$DEST" && gsutil -m cp -r "gs://$BUCKET/$PREFIX*" "$DEST/"

Azure Blob

az storage blob download-batch -s "$BUCKET" -d "$DEST" --pattern "$PREFIX*"

Then check what you got against the inventory above:

find "$DEST" -type f | sort

For a guaranteed-consistent copy, cf stop powerconnect-cloud first

Restore

1. Stop the application - all instances.

cf stop powerconnect-cloud

This is not optional. Running instances hold the configuration in memory and write it back to the object store as they start, so objects restored underneath a running app are overwritten within seconds.

2. Copy the objects back.

aws s3 sync "$DEST/" "s3://$BUCKET/$PREFIX"                          # AWS S3
gsutil -m cp -r "$DEST/*" "gs://$BUCKET/$PREFIX"                     # GCS
az storage blob upload-batch -d "$BUCKET" -s "$DEST" --destination-path "$PREFIX"

3. Confirm POWERCONNECT_SECRET matches the backup. If the app's secret has changed since the backup was taken, the restored keystore will not open. Set it back to the value recorded with the backup.

4. Start the application.

cf start powerconnect-cloud

Check the log for the inputs and outputs you expect to see loaded.

Two decisions to make before restoring

Poll positions (checkpoints.edn)

checkpoints.edn records how far each input has polled. A bulk copy restores it along with everything else, which rewinds every input and re-sends events already delivered to Splunk or Dynatrace.

To restore configuration only and leave poll positions where they are:

aws s3 sync "$DEST/" "s3://$BUCKET/$PREFIX" --exclude "*checkpoints.edn"

Objects added since the backup

sync does not delete by default, so anything created after the backup survives the restore. That is usually what you want. For a clean revert to exactly the backed-up state, add --delete - but confirm first that the prefix contains nothing but PowerConnect data.

aws s3 sync "$DEST/" "s3://$BUCKET/$PREFIX" --delete
  • Take a backup before every upgrade, with the application stopped, and keep it until the new version has run cleanly for long enough to trust it.

  • Keep POWERCONNECT_SECRET with the backup, protected accordingly. A backup without it restores configuration but no credentials.

From 9.3.0 onward, backup, verify and restore are built in and produce a single verifiable archive with checksums, so the procedure above becomes a fallback rather than the primary method.