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
-
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
- Scale down your deployment:
Db2 WarehouseAttention: 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
- 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
- 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.
- 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.
- 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.
- 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:
- 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
- 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
- Exit maintenance mode:
oc annotate db2ucluster $DB2U_CLUSTER db2u.databases.ibm.com/maintenance-pause-reconcile- --overwrite