EDB Postgres supports
the restoration of the database from a backup. You can recover a backup at any point in time from
the first available base backup in your system.
Before you begin
Determine the type of recovery that you want to enable.
- Option 1: Full recovery from the last available backup.
- Option 2:
Point in time recovery (PITR) by using the following recovery
target criteria.
- targetTime
-
The timestamp from which to start the recovery, which is expressed in the RFC 3339 format.
- targetXID
-
The transaction ID of the point in time to start the recovery. Transaction IDs are assigned
sequentially at a transaction start, but they can complete in a different order. The recovered
transactions are the transactions that are committed before (and optionally including) the specified
ID.
- targetName
-
The name of the point in time (restore point
) from which to start a
recovery.
- targetLSN
-
The closest completed backup to the write-ahead log location target from which to start the
recovery.
- targetImmediate
- Start a recovery as soon as possible. If you are restoring from an online backup, the recovery
starts immediately after the backup finished.
Procedure
-
If you do not have a copy of the cert-kubernetes repository, then go ahead
and download it to your client machine.
-
Log in to the target cluster as the
<cluster-admin>
user.
Using the OpenShift CLI:
oc login https://<cluster-ip>:<port> -u <cluster-admin> -p <password>
On ROKS, if you are not already logged in:
oc login --token=<token> --server=https://<cluster-ip>:<port>
- Change the directory to the extracted cert-kubernetes/scripts
folder.
cd ${PATH_TO_EXTRACTED_FILES}/cert-kubernetes/scripts
- Run the backup script and follow the prompts in the command window.
./cp4a-edb-production-backup-restore.sh
- Select "2" to generate the necessary restore files.
- Continue to answer the questions with the information about the type of recovery that you want,
and the credentials to access your storage device. For more information, see Backing up EDB Postgres.
Verify that the script generated the secret and YAML files in
/{WORKING_DIRECTORY}/cert-kubernetes/scripts/EDB.
- If required: If you need to, re-create the secret with the credentials that you
stored for your chosen storage provider.
For AWS, apply the following YAML file.
oc apply -f /{WORKING_DIRECTORY}/cert-kubernetes/scripts/EDB/aws-creds.yaml
For Microsoft Azure, apply the following YAML file.
oc apply -f /{WORKING_DIRECTORY}/cert-kubernetes/scripts/EDB/azure-creds.yaml
For Google Cloud, apply the following YAML file.
oc apply -f /{WORKING_DIRECTORY}/cert-kubernetes/scripts/EDB/create-google-secret.sh
- Scale down the CP4BA multi-pattern and CP4BA FileNet Content Manager operators
by running the following command.
oc scale deployment ibm-cp4a-operator ibm-content-operator --replicas=0
- Scale down the CP4BA deployments that use EDB Postgres by running a command that gets
all the deployments with the default name
icp4adeploy
.
for i in `oc get deploy -o name |grep icp4adeploy`; do oc scale $i --replicas=0; done
for i in `oc get sts -o name |grep icp4adeploy`; do oc scale $i --replicas=0; done
Remember: The following capabilities support
EDB Postgres.
- FileNet Content Manager
- Automation Document Processing
- Business Automation Workflow
- Business Automation Studio
- Operational Decision Manager
- After you scaled down all the CP4BA deployments, delete the EDB Postgres deployment
(
postgres-cp4ba
).
oc delete -f /{WORKING_DIRECTORY}/cert-kubernetes/scripts/EDB/postgres-cp4ba.yaml
- Re-create the EDB Postgres deployment by running the YAML file
/{WORKING_DIRECTORY}/cert-kubernetes/scripts/EDB/postgres-cp4ba.yaml, which
contains a new
recovery
section.
oc apply -f /{WORKING_DIRECTORY}/cert-kubernetes/scripts/EDB/postgres-cp4ba.yaml
The new section that is created for the recovery in the EDB Postgres custom resource includes the
following YAML:
bootstrap:
recovery:
source: clusterBackup
Wait for the recovery process to complete. Only when the pod postgres-cp4ba-1
is
in a running state is the recovery process complete.
- Scale up all the CP4BA operators that you scaled down in Step 6.
oc scale deployment ibm-cp4a-operator ibm-content-operator --replicas=1
Note: After the EDB Postgres
deployment is re-created, the EDB Postgres operator generates new
certificates. The CP4BA operators also regenerate a new client certificate for the applications to
use. It can take up to two reconciles of the operators to update the deployments with the latest
client certificate.