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.

About this task

Important: In running these steps, you might be at risk of losing your data unless you take the mentioned precautions.
Note: The LDAP service provided by Db2®/Db2 Warehouse is only used if enabled. If you are not using the LDAP service provided by Db2/Db2 Warehouse, you do not need to run any commands involving LDAP_DEPLOY.

Procedure

  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.
  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