Configuring backup settings for Analytics
apicup utility to configure backup settings for the Analytics
database in your VMware environment.
About this task
The Analytics database can be backed up and restored from an S3 repository. S3-compatible object storage is required; for example, IBM Cloud Object Storage.
apicuputility to configure the backup settings.
Configure each setting by running the following command with the key and value from Table 1 that you want to apply:
apicup subsys set <analytics_subsystem> <key> <value>
Table 1 shows the supported backup settings with the default value (if any) and a description of each setting.
Table 1. Analytics backup settings Key Default value Description
Server password for Analytics backups.
Server user name for Analytics backups.
The S3 endpoint with the corresponding S3 region in the format:
s3.eu-gb.cloud-object-storage.appdomain.cloudAttention: A path style host value (formatted as
S3endpoint/S3region) is not supported for AWS.
The name of a custom certificate that contains your upstream custom S3 CA certificate. Supported beginning with 10.0.2.
This field accepts name of the Kubernetes secret containing your upstream custom S3 CA certificate. The key of the secret must be
ca.crtand the value is the base64-encoded value of the CA certificate.
If the server certificate that is presented by your S3/object-store endpoint is signed by a well known CA and includes any intermediate certificates in the chain, then you do not need to provide the CA certificate using this feature because the Portal subsystem already trusts the server certificate. You can test this by configuring the Portal backup to your S3/object-store server without providing the CA certificate.If you do need to provide the CA certificate then you must provide the entire chain in the
ca.crtmember of the secret, as follows:
intermediate-certificate-1 intermediate-certificate-2 . . . intermediate-certificate-n root-certificate
Where the first certificate in the
ca.crtmember (intermediate-certificate-1) is the issuer of the S3/object-store server certificate, and each subsequent certificate in the
ca.crtmember is the issuer of the preceding certificate. The root certificate in the
ca.crtmember must be self-signed.
If there are no intermediate certificates involved, then the
ca.crtmember contains only the root certificate.The following sample bash script creates a Kubernetes secret:
cat >customs3ca.yaml <<EOF apiVersion: v1 data: ca.crt: $(base64 <path-to-ca-certificate> | tr -d '\n' ) kind: Secret metadata: name: custom-server-ca type: generic EOF kubectl apply -f customs3ca.yaml -n <namespace>
A combination of the S3 bucket and the base path within the bucket, using the format:
1GB (Optional) Specifies how large files are stored. Large files can be stored as chunks when the snapshot is created. This setting specifies the size of the chunks as GB, MB, or KB.
0 2 * * * (Optional) Determines how often backups will be invoked automatically. The format for the schedule is any valid
The timezone for backups is UTC. Backing up once a day is probably sufficient; remember that the more frequently you run backups, the more storage space you need.
true (Optional) Determines whether metadata files are stored in compressed format.
false (Optional) Determines whether files are encrypted. When set to true, files are encrypted on the server side using AES256.
Validate the backup settings by running the following command:
apicup subsys get <analytics_subsystem> --validate
Apply the backup settings to the Analytics subsystem by reinstalling with the following
apicup subsys install <analytics_subsystem>Note: The
apicup subsys installcommand automatically runs
apicup health-checkprior to installing the new configuration. An error is displayed if a problem is found that will prevent successful reconfiguration.
In some scenarios, after you fix the problem, the health check might continue to fail. In this case, you can use the
--skip-health-checkflag to suppress the automatic health check:
apicup subsys install <subsystem_name> --skip-health-check
Verify that the backup settings were successfully applied by running the following
apicup subsys health-check <analytics_subsystem>