Performing a snapshot restore with Db2 or Db2 Warehouse container commands - Db2uCluster

You can restore a snapshot backup of your Db2 or Db2 Warehouse database by putting your database in maintenance mode and restoring your volume snapshots.

1. Put your cluster in maintenance mode:

   DB2U_CLUSTER=$(oc get db2ucluster --no-headers | head -n1 | awk '{print $1}'); echo $DB2U_CLUSTER

   oc annotate db2ucluster $DB2U_CLUSTER db2u.databases.ibm.com/maintenance-pause-reconcile=true --overwrite

2. Scale down your deployment:
   Db2 Warehouse

   Attention: The tools pod is only used in Db2 Warehouse where more than one node (multinode massively parallel processing or MPP) is being used for a deployment. If you are using a one-node Db2 Warehouse deployment (single-node symmetric multiprocessing or SMP), you do not need to run any commands involving TOOLS_DEPLOY.

   NUM_REPLICAS=$(oc get sts ${DB2U_STS} -ojsonpath={.spec.replicas})

   DB2U_STS=$(oc get sts --selector="app=${DB2U_CLUSTER},type=engine" --no-headers | awk '{print $1}'); echo $DB2U_STS

   ETCD_STS=$(oc get sts --selector="app=${DB2U_CLUSTER},component=etcd" --no-headers | awk '{print $1}'); echo $ETCD_STS

   oc scale sts ${DB2U_STS} --replicas=0

   oc scale sts ${ETCD_STS} --replicas=0

   LDAP_DEPLOY = $(oc get sts --selector= "app= ${DB2U_CLUSTER},role=ldap" --no-headers | awk '{print $1}'); echo $LDAP_DEPLOY

   oc scale deploy ${LDAP_DEPLOY} --replicas=0

3. Copy the existing persistent volume claim (PVC) definitions:

   oc label pvc c-${DB2U_CLUSTER}-meta app=${DB2U_CLUSTER}

   oc label pvc c-${DB2U_CLUSTER}-backup app=${DB2U_CLUSTER}

   oc label pvc c-${DB2U_CLUSTER}-share app=${DB2U_CLUSTER}

   for PVC in $(oc get pvc -l app=$DB2U_CLUSTER --no-headers | awk '{print $1}'); do oc get pvc $PVC -oyaml > ${PVC}_copy.yaml ; done

4. Set your existing persistent volume (PV) reclaim policy to retain in case something goes wrong:

   for PV in $(oc get pv --no-headers | grep $DB2U_CLUSTER | awk '{print $1}'); do oc patch pv $PV -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}" ; done

   Important: Manually verify that each PV is set to retain or you are at risk of losing your data.
5. Delete the existing PVCs:

   oc delete pvc -l app=${DB2U_CLUSTER}

   CAUTION:

   Do this step only if you are confident that you are able to restore your volume snapshots, and your PV reclaim policies are set to retain. If you are unsure, try the next step instead by restoring your volume snapshots to dummy PVCs with different names first.
6. If you are using Native Cloud Object Storage (NCOS), restore from your continuous backup of cloud object storage at the corresponding point in time to the snapshot backup of your traditional storage.
7. Restore your volume snapshot to PVCs with the same name and namespace that you copied in step 3.
   The steps will differ depending on your provider:

   • OpenShift® Data Foundation
   • Portworx
   • IBM Spectrum® Scale CSI
   • IBM® Cloud File Storage
8. Scale up your deployment:

   oc scale sts ${ETCD_STS} --replicas=1

   oc scale sts ${DB2U_STS} --replicas=${NUM_REPLICAS}

   oc scale deploy ${LDAP_DEPLOY} --replicas=1

9. Bring the database out of write-suspend after restoring:

   CATALOG_POD=$(oc get po -l name=dashmpp-head-0,app=${DB2U_CLUSTER} --no-headers | awk '{print $1}')

   oc exec -it ${CATALOG_POD} -- manage_snapshots --action restore

   Run this command against the catalog pod if you have NCOS enabled:

   manage_snapshots --action resume -cos

10. Exit maintenance mode:

    oc annotate db2ucluster $DB2U_CLUSTER db2u.databases.ibm.com/maintenance-pause-reconcile- --overwrite