It is important to back up your data so that you can resume work as quickly and
effectively as possible.
Before you begin
For all mentions of fncmdeploy
in the provided examples, replace it with
the value you set for metadata.name
in the custom resource (CR) file.
Before you
start to back up your environment, stop your environment to prevent changes in your persistent
volumes (PVs) and database. If you do not stop your environment, your PV data and databases might
not be backed up properly.
- You can scale down all your environment pods to 0 by running the following
commands:
kubectl scale deploy ibm-fncm-operator --replicas=0
for i in `kubectl get deploy -o name |grep fncmdeploy`; do kubectl scale $i --replicas=0; done
About this task
Note: You can use the
mustgather.py
script to gather information such as
configmaps, pods, secrets, and log files about the FNCM resources in the target namespace. For more
information, see the topic
Must Gather.
Tip: Back up each environment in your multiple-zone clusters regularly. The shorter the
time in between two backups the less data you can potentially lose. Configure the
container-samples
to set up the TLS key and certificate secrets.
Use the following steps to back up your container components in a multiple-zone environment.
Procedure
-
Make copies of the custom resource (CR) files that are used in the primary and secondary
environments. The custom resource (CR) file for a secondary environment has a different hostname
from the primary environment.
-
Back up the security definitions in the following table. For more information, see Creating secrets to
protect sensitive configuration data.
Table 1. Secrets to back up
Secrets |
Example secret name |
Images pull secret. Not present in an airgap environment. |
ibm-entitlement-key |
Lightweight Directory Access Protocol (LDAP) secret |
ldap-bind-secret |
Identity provider and SCIM secrets |
ibm-idp-oidc-secret
ibm-scim-secret
|
Trusted certificates for external applications. Required if any additional certificates have
been added. |
trusted-cert-1-secret |
LDAP SSL certificate secret. Required if you enabled SSL connection for LDAP. You must also
back up the certificate file. |
ldap-ssl-cert |
Database SSL certificate secret. Required if you enabled an SSL connection for the database.
You must also back up the certificate file. |
ibm-gcd-ssl-secret
ibm-os-ssl-secret
ibm-icn-ssl-secret
|
Shared encryption key secret |
fncm-root-ca |
Navigator secret |
ibm-ban-secret |
FNCM secret |
ibm-fncm-secret |
IER secret |
ibm-ier-secret |
ICCSAP secret |
ibm-iccsap-secret |
- Back up your PVC definitions and PV definitions based on your type of provisioning:
- If you are using static provisioning, back up your PVC definitions, PV definitions, and the
content in the PV.
- If you are using dynamic provisioning, the operator creates the PV and PVC definitions
automatically, so you need to back up the PVC definition and the content in the PV. To back up the
PVC definitions, get each definition and modify the format so that the PVC can be deployed. The
following sample script gets all the PV and PVC definitions. Reference the list of PVC definitions
that are related to their capabilities and remove the ones that you do not
need.
#!/bin/sh
NS=ibm-fncm
pvcbackup() {
kubectl get pvc -n $NS --no-headers=true | while read each
do
pvc=`echo $each | awk '{ print $1 }'`
echo "---" >> pvc.yaml
kubectl get pvc $pvc -o yaml \
| yq eval 'del(.status, .metadata.finalizers, .metadata.resourceVersion, .metadata.uid, .metadata.annotations, .metadata.creationTimestamp, .metadata.selfLink, .metadata.managedFields, .metadata.ownerReferences, .spec.volumeMode, .spec.volumeName)' - >> pvc.yaml
done
}
pvcbackup
Back up the content in the PV. When you restore the environment, you can
create the PVC by using the backup definition and by copying the content to the corresponding
PV.
-
Back up all the content in the PVs. You can choose which files to restore on your environment
later. The generated folder names for dynamically provisioned PVs are not static. For example, the
folder name might look similar to
fncm-cmis-cfgstore-pvc-ctnrs-pvc-e5241e0c-3811-4c0d-8d0f-cb66dd67f672
. The folder
name is different for each deployment, so you must use a mapping folder to back up the content. The
following script can be used to create backups of your PVs.
#!/bin/sh
NS=fncm
SOURCE_DIR=/home/pv/560
BACKUP_DIR=/home/backup
pvbackup() {
kubectl get pvc -n $NS --no-headers=true | while read each
do
pvc=`echo $each | awk '{ print $1 }'`
pv=`echo $each | awk '{ print $3 }'`
if [ -d "$SOURCE_DIR/$NS-$pvc-$pv" ]
then
echo "copying pv $pv "
mkdir -p $BACKUP_DIR/$pvc
cp -r -a $SOURCE_DIR/$NS-$pvc-$pv/. $BACKUP_DIR/$pvc
echo ""
else
echo "NOT FOUND for $pvc"
fi
done
}
pvbackup
- Make copies of the following files:
- JDBC drivers that depend on your database type. For more information, see the following links:
- Customized files that you put in the components PV for runtime. For example, customized font
files.
- The configuration files that you use to set up your persistent storage, and your database
server.
- If you have a database, back up the secure definition that is used to store the database
username and password, and the configuration files that you used to set up your database
server.
- If you have a database, back up the data in your database by using your preferred method.
The following table shows databases that need to be backed up.
Table 2. Databases that need to
be backed up for each capability
Capability |
Databases that need to be backed up |
IBM FileNet Content Manager |
The databases for the Global Configuration Database and your object store. |
IBM Content Navigator |
The database for Content Navigator. |
To configure backup and recovery for PostgreSQL, see Backup
and Recovery.
If you are using Db2, you can complete an online or offline backup by
completing the following steps.
Run the following commands to complete an offline backup. If you
want to do an online backup, you must also complete this step.
mkdir -p /home/db2inst1/backup/560
db2 backup db OSDB to /home/db2inst1/backup/560 WITH 2 BUFFERS BUFFER 1024
db2 backup db GCDDB to /home/db2inst1/backup/560 WITH 2 BUFFERS BUFFER 1024
db2 backup db ICNDB to /home/db2inst1/backup/560 WITH 2 BUFFERS BUFFER 1024
If
you want an online backup, complete the following steps.
- Enable archival logging for each database in the environment. You can also configure
the interval between each backup.
mkdir -p /home/db2inst1/archive/OSDB
db2 update db cfg for OSDB using LOGINDEXBUILD on
db2 update db cfg for OSDB using LOGARCHMETH1 disk:/home/db2inst1/archive/OSDB
mkdir -p /home/db2inst1/archive/GCDDB
db2 update db cfg for GCDDB using LOGINDEXBUILD on
db2 update db cfg for GCDDB using LOGARCHMETH1 disk:/home/db2inst1/archive/GCDDB
mkdir -p /home/db2inst1/archive/ICNDB
db2 update db cfg for ICNDB using LOGINDEXBUILD on
db2 update db cfg for ICNDB using LOGARCHMETH1 disk:/home/db2inst1/archive/ICNDB
- Terminate your database connections to prevent errors during the backup.
db2 force applications all
- Complete the online backup by running the following commands.
mkdir -p /home/db2inst1/backup/560/online
db2 backup db OSDB online to /home/db2inst1/backup/2401/online
db2 backup db GCDDB online to /home/db2inst1/backup/2401/online
db2 backup db ICNDB online to /home/db2inst1/backup/2401/online
- If necessary, back up the Lightweight Directory Access Protocol (LDAP) files. Different
types of LDAP servers have different backup methods. Make sure that the restored data in the LDAP
database is the same as the source LDAP.
For IBM Security Directory Server see IBM
Security Directory Server backup and restore.
- Complete the backup procedures for the following components that you configured in your
environment.
What to do next
When the back up is complete, scale up your environment pods by running the following
commands.
for i in `kubectl get deploy -o name |grep fncmdeploy`; do echo " start $i" ; kubectl scale $i --replicas=1; done
echo " start operators ..."
kubectl scale deploy ibm-fncm-operator --replicas=1