Backing up Guardium Data Security Center
Use the following procedure to back up Guardium Data Security Center.
Before you begin
If you are backing up to a remote destination, review the requirements for External storage allocation for backups.
Procedure
Finding your backup files
Verify that your files are backed up by checking your persistent volume claim.
gdsc-backup-<guardium_data_security_center_host>-<guardium_data_security_center_namespace>-<guardium_data_security_center_instance>-<timestamp>
. For
example:gdsc-backup-sys-qa-rtp02-staging-staging-2022-01-20-2325
File naming conventions are outlined in this table:
Directories and files | Description |
---|---|
Info.yaml | Process information, including the date, version, and number of modules that are backed up. |
data | Application data |
data/DB2 | Db2 data |
data/MongoDB | MongoDB memory dump |
meta | Metadata for the restore process |
meta/ backupInternalCRs.yaml | Internal CR |
meta/configurations-backup | GUC-manager file system |
meta/guc-config-backup | GUC-manager file system |
meta/DB2_Label_<gdsc-version>_<instance-name>.info | Db2 label information |
meta/DB2_Tables_<gdsc-version>_<instance-name>.info | Db2 tables information |
meta/Tenant_IDs_<gdsc-version>_<instance-name>_.info | Db2 tenant information |
meta/LDAP_Config_<gdsc-version>_<instance-name>.info | LDAP information |
meta/Mongo_Tables_<gdsc-version>_<instance-name>.info | MongoDB tenant information |
meta/<cluster-name> | Cluster data directory |
meta/<cluster-name>/DB2/keystore_<gdsc-vervion>_ORG | Directory that contains the keystores |
meta/<cluster-name>/ DB2/keystore_<gdsc-vervion>_ORG/keystore/keystore.p12 | Original keystore for db2 for cluster |
meta/<cluster-name>/ DB2/keystore_<gdsc-vervion>_ORG/keystore/keystore.sth | Original keystore for db2 for cluster |
meta/<cluster-name>/ DB2/tmpkeystore | Directory that holds the temporary keystore |
meta/<cluster-name>/ DB2/tmpkeystore/temp_keystore.p12 | The master key is held in the temp_keystore.p12 |
The following example shows backup files in a PVC:
gdsc-backup-sys-gdsc-rtp02-staging-staging-2022-09-29-1955
├── [ 12K] backup-2022-09-29-1955.log
├── [ 6.0K] backup-2022-09-29-2003.log
├── [ 6.0K] backup-2022-09-29-2006.log
├── [ 1.1K] backup_info.yaml
├── [ 4.0K] data
│ ├── [ 4.0K] DB2
│ │ ├── [ 13M] DB2.delta.20220929200405.tar.gz
│ │ ├── [ 13M] DB2.delta.20220929200714.tar.gz
│ │ └── [ 969M] DB2.full.20220929200009.tar.gz
│ └── [ 4.0K] Mongodb
│ │ ├── [ 9.5K] Mongodb.20220929195747.gz
│ │ ├── [ 9.5K] Mongodb.20220929200501.gz
│ │ └── [ 9.5K] Mongodb.20220929200812.gz
│ └── [ 4.0K] PG
│ ├── [ 3.6M] riskmanager_backup_20220929_195843.tar
│ ├── [ 3.6M] riskmanager_backup_20220929_200601.tar
│ └── [ 3.6M] riskmanager_backup_20220929_200910.tar
├── [ 4.0K] meta
├── [ 760] backupInternalCRs.yaml
├── [ 4.0K] datamart-backup
├── [ 4.0K] TNT_SH83ZQZVNYFKDHJBPRW76I
└── [ 0] watchedFiles
├── [ 56] DB2_Label_v3.2.0_staging.info
├── [ 140K] DB2_Tables_v3.2.0_staging.info
├── [ 4.0K] guc-config-backup
├── [ 2.7K] insightsMigrationSecrets.csv
├── [ 462] LDAP_Config_v3.2.0_staging.info
├── [ 2.6K] Mongo_Tables_v3.2.0_staging.info
├── [ 4.0K] staging
│ └── [ 4.0K] DB2
│ ├── [ 4.0K] keystore_3.0_ORG
│ │ ├── [ 3.4K] keystore.p12
│ │ └── [ 193] keystore.sth
│ └── [ 4.0K] tmpkeystore
│ └── [ 3.4K] temp_keystore.p12
└── [ 103] Tenant_IDs_v3.2.0_staging.info
Stopping the backup process
The backup process is a cronjob
, and unless you explicitly stop it by
deleting the backup resource, it runs continuously. Before you consider stopping a backup process,
verify that the backup data on the PV or PVC can remain after the cronjob
is
removed. The system recycles dynamically allocated PV or PVC, and all data is lost.
Procedure
Creating a custom resource file for backups
Before you install Guardium Data Security Center, enable backups with a Network File System (NFS) storage class by using a YAML custom resource (CR) file. To configure backups, you must provision your own Persistent Volume (PV) and Persistent Volume Claim (PVC).
The back up process
Backups for Guardium Data Security Center run as CronJobs and can be activated by using a YAML file.
The YAML file defines the frequency, schedule, and the retention days for a backup. A pod that contains the backup scripts is created, and the top-level script runs. The default location of the backup directory is in the backup pod unless it is configured differently.
During a full backup, the configuration files (such as LDAP information and oc secrets) and internal databases (Db2, MongoDB, and PostgreSQL) are backed up. During an incremental backup, the configuration files are not backed up.
oc apply -f backup.yaml
YAML CR file definition
Create a YAML CR file by using the code in the following example:
apiVersion: gi.ds.isc.ibm.com/v1
kind: Backup
metadata:
name: guardiumdatasecuritycenter
spec:
gdsc-backup:
cronjob:
# schedule of jobs
schedule: "0 23 * * *"
insightsEnv:
#How many days to keep the full backups, default 0, never remove
RETENTION_FULL_BACKUP_IN_DAYS: 30
#How frequent (in days) the full backup should be. (Default 7)
FREQUENCY_FULL_BACKUP_IN_DAYS: 15
#After X times of DB2 incremental backup, the next round of job
#will perform a system full backup. (Default 6)
FREQUENCY_FULL_BACKUP_IN_INC_COUNT: 14
#Resume the full backup process from where it failed before if
#failure occurred in previous full backup job run. (Default true)
RESUME_FULL_BACKUP_ON_FAILURE: true
persistentVolumesClaims:
backup:
name: gdsc-custom-named-pvc
size: 500Gi
storageClassName: <storage class on your system>
targetGIInstance: gdsc-sample
Attribute | Description |
---|---|
schedule: "0 23 * * *" |
"0 23 * * *" is the schedule of the CronJob that begins everyday at 23:00
(Coordinated Universal Time time zone). You can customize the schedule based on your needs. Note: If the backup runs longer than anticipated, the next task might be out of schedule. |
insightsEnv |
The settings of your environment. They can be customized to suit your needs. |
name: gdsc-custom-named-pvc |
The name of the PVC for your NFS. |
size: 500Gi |
The minimum size of the PV for your NFS. |
storageClassName |
The storage class on your system. Select the rwx file storage type. For more information, see Validated storage options. |
Based on the required frequency of full and incremental backups, define your
cronjob
by using the following examples:
Schedule name | Aggressive | Frequent | Common | Historical |
---|---|---|---|---|
Full backup schedule | Once daily | Once weekly (7 days) | Once every 2 weeks (15 days) | Once every 30 days |
Incremental backup schedule | 1 incremental 12 hours later in between | 6 increments in between | 14 increments in between | 29 increments in between |
CRON schedule | "* 0-23/12 * * *" |
"* 23 * * *" |
"0 23 * * *" |
"* 23 * * *" |
FREQUENCY_FULL_BACKUP_IN_DAYS |
1 | 7 | 15 | 30 |
FREQUENCY_FULL_BACKUP_IN_INC_COUNT |
1 | 6 | 14 | 29 |
Configuring backup after Guardium Data Security Center installation
Create a PVC for installation to run a successful backup.
Before you begin
When you apply the patch, the "claimName":
in the oc patch
command must match the name of the PVC that you create.