Overview of the Developer Portal backup resources
How to manage your Developer Portal remote backup resources.
The Developer Portal uses
two types of portal backup resources. When you run the command kubectl get
portalbackup
, you see a list of backups, for example:
NAME ID TASK ID STATUS TYPE CR TYPE CLUSTER AGE COMMENT
my-backup-f91ms n/a 20b47fe090f5 Ready system create portal 78m
portal-record-222cg 20220108.010033 Ready system record portal 94m
portal-record-22xdc 20220702.010339 Ready site record portal 9m49s
portal-record-245j7 20221002.010340 Ready site record portal 5m
portal-record-246hm 20221218.010103 Ready site record portal 32m
portal-record-24h44 20220509.010037 Ready site record portal 68m
portal-record-24wb4 20221003.010029 Ready site record portal 60m
portal-record-264mh 20221119.010453 Ready system record portal 78m
CR TYPE
column; create
or record
types.create
: This resource is a representation of aportalbackup
task that was created manually. See Backing up and restoring the Developer Portal in a Kubernetes environment, Backing up Developer Portal on OpenShift and Cloud Pak for Integration, or Backing up the Developer Portal subsystem on VMware, for information about how to create a manual portal backup.record
: This resource is generated by the operator, and it's a representation of a backup file that's stored on the remote backup server. A record listing can be modified only to add a comment to it. You can describe each record to understand which file it is referring to by running the following command:
For example:kubectl describe portalbackup portal-record-name
kubectl describe portalbackup portal-record-zmmfw . . Name: portal-record-zmmfw Namespace: apic Labels: createdBy . . Full Backup Name: my-portal-s3-hostname@my-porg@catal-20220604.010302.tar.gz
Record rows are generated and updated on a schedule, according to the backups that exist on your remote backup server. If you have 10 backup files stored on your remote server, then there will be 10 record rows; one row for each file.
The Developer Portal doesn't have a retention policy for remote backups. Therefore, it's your responsibility to ensure that you're keeping the number of backups that are stored remotely under control. An excessive number of portal backups results in delays administrating and upgrading the Developer Portal. This is due to the operator needing to maintain the excessive number of record rows that correspond to each remote portal backup.