Configuring backup settings for the Developer Portal subsystem

You can use the apicup utility to configure backup settings for the Developer Portal subsystem

1. Open your API Connect installation project directory.
2. Run the following commands to set the location and timing of your backups:

   apicup subsys set <subsystem_name> <setting>=<value>

   apicup subsys set ptl site-backup-host=mybackuphost.com
   apicup subsys set ptl site-backup-port=22
   apicup subsys set ptl site-backup-auth-user=mybackupauthusername
   apicup subsys set ptl site-backup-auth-pass=mybackupauthpassword
   
   apicup subsys set ptl site-backup-path=/site-backups
   apicup subsys set ptl site-backup-protocol=sftp
   apicup subsys set ptl site-backup-certs=<custom-s3-server-CA-cert>
   apicup subsys set ptl site-backup-s3-uri-style=<host-or-path>
   apicup subsys set ptl site-backup-schedule="0 2 * * *"
   apicup subsys set ptl site-priority-list=portal.a1.example.com/test-1/spacecatalog,portal.a1.example.com/test-4/cat3,portal.a1.example.com/test-3/cat1

   Use apicup certs instead of apicup subsys to configure ssh-key authentication for SFTP:

   apicup certs set ptl site-backup-auth-ssh-key <ssh-key-file-path>

   The backup parameters are detailed in the following table.

   Table 1. Portal backup parameters

   Parameter	Description
   site-backup-host	The fully qualified domain name of the backup server, in lowercase only. For objstore type backup, specify S3 endpoint with the corresponding S3 region in the format <S3endpoint>/<S3region> apicup subsys set ptl site-backup-host=s3.eu-gb.cloud-object-storage.appdomain.cloud For sftp type, the SFTP server hostname apicup subsys set ptl site-backup-host=my.sftp.backup.domain.example.com
   site-backup-port	The port for the protocol to connect to the site-backup-host. Defaults to 22 if not explicitly set. The backup port is not required for object storage. apicup subsys set ptl site-backup-port=22
   site-backup-auth-user	The user name for the server specified in site-backup-host. If using object storage, the user name is the S3 Secret Key ID. apicup subsys set ptl site-backup-auth-user=<user_name>
   site-backup-auth-pass	The password for the server specified in site-backup-host. If using object storage, the password is the S3 Secret Access Key parameter. The password is stored in Base64 encoded format, and must not be edited directly in the apiconnect-up.yml file. apicup subsys set ptl site-backup-auth-pass=password
   site-backup-auth-ssh-key	Version 10.0.1.4-ifix1-eus or later: OpenSSH key for database backups using SFTP. Important: Use apicup certs to set this value. Do not use apicup subsys. Only OpenSSH keys are supported.1 apicup certs set ptl site-backup-auth-ssh-key=<ssh-key-file-path>
   site-backup-path	The location of where the backups are stored: S3 - the name of your S3 bucket to store backup data, optionally followed by a / and then any subdirectories inside the bucket. Valid examples: bucket bucket/path bucket/lots/of/paths Example: apicup subsys set ptl site-backup-path=apic-backup SFTP - the full absolute path of the folder on the SFTP server, beginning with /. apicup subsys set ptl site-backup-path=</folder>
   site-backup-protocol	The protocol that is used to communicate with your remote backup endpoint. Specify one of the following values: sftp - for secure file transfer protocol local - for local storage objstore - for S3 compatible object storage Starting in 10.0.1.4-ifix1-eus, the default protocol is local (earlier releases used sftp as the default). For example: apicup subsys set ptl site-backup-protocol=local
   site-backup-certs	The name of a custom certificate that contains your upstream custom S3 CA certificate. Supported beginning with 10.0.1.2-eus. This field accepts name of the Kubernetes secret containing your upstream custom S3 CA certificate. The key of the secret must be ca.crt and 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.crt member of the secret, as follows: intermediate-certificate-1 intermediate-certificate-2 . . . intermediate-certificate-n root-certificate Where the first certificate in the ca.crt member (intermediate-certificate-1) is the issuer of the S3/object-store server certificate, and each subsequent certificate in the ca.crt member is the issuer of the preceding certificate. The root certificate in the ca.crt member must be self-signed. If there are no intermediate certificates involved, then the ca.crt member 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>
   site-backup-s3-uri-style	Optional. Indicates whether URIs to your S3 backup should use specify a host or a path value. When not specified, defaults to host. Supported beginning with 10.0.1.2-eus. Valid values: host and path. Some custom S3 providers require URI style to be set to path. For example, MinIO supports both host and path style setup. You can create a MinIO S3 server to only accept path style client communications. Important: Contact your custom S3 administrator before configuring this field. If not properly configured, an upstream custom S3 can reject connections from the client, such as the API Connect Management subsystem.
   site-backup-schedule	The schedule for how often automatic Portal backups are run. The format for the schedule is any valid cron string, as follows: * * * * * - - - - - | | | | | | | | | +----- day of week (0 - 6) (Sunday=0) | | | +------- month (1 - 12) | | +--------- day of month (1 - 31) | +----------- hour (0 - 23) +------------- min (0 - 59) For example: 30 22 * * 1 performs backups at 10:30 pm on Mondays. The default backup schedule is 0 2 * * * (runs every day at 2 am). The timezone for backups is UTC. apicup subsys set ptl site-backup-schedule="0 2 * * *"
   site-priority-list	Optional list of prioritized sites to restore. Default: empty. apicup subsys set <portal-subsystem-name> site-priority-list <comma-separated-list-of-sites> For example: apicup subsys set ptl site-priority-list portal.a1.example.com/e2etest-1/spacecatalog,portal.a1.example.com/e2etest-4/cat3,portal.a1.example.com/e2etest-3/cat1

3. At any time you can view the current Portal subsystem values:
   • For most values:

     apicup subsys get ptl

     where ptl is the name that you assigned to your Portal service. The output from this command lists all of the subsystem settings, including backup, and indicates whether there are any errors. You must fix any errors before continuing.

   • Version 10.0.1.4-ifix1-eus or later: For ssh-key authentication for SFTP:

     apicup certs get ptl site-backup-auth-ssh-key

4. Activate the backup settings by running the following command:

   apicup subsys install ptl

   where ptl is the name that you assigned to your Portal service.
   Note: The apicup subsys install command automatically runs apicup health-check prior 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-check flag to suppress the automatic health check:

   apicup subsys install <subsystem_name> --skip-health-check

5. Validate the installation with the new backup parameters by running the following command:

   apicup subsys get ptl --validate

   where ptl is the name that you assigned to your Portal service. The output from this command lists all of the subsystem settings, including backup, and indicates whether the values are valid or invalid. You must correct any invalid values before continuing.
6. Ensure that the changes were applied successfully:

   apicup subsys health-check <subsystem_name>