Managing your remote portal database backups

How to manage your remote portal database backup resources.

Note: For OpenShift users: The steps that are detailed in this topic use the Kubernetes kubectl command. On OpenShift, use the equivalent oc command in its place.

When you run the command kubectl get portalbackup -o wide, you see a list of all the backups that ran during the past 30 days:

NAME                  ID                TASK ID      STATUS   TYPE     CR TYPE   CLUSTER   AGE   COMMENT   FILENAME
my-backup-f91ms       n/a               20b47fe090f5 Ready    all      create    portal    58m
portal-record-2vcgs   20231105.181212   n/a          Ready    system   record    portal    55m             _portal_system_backup-20231105.181212.tar.gz
portal-record-9j8lt   20231104.095949   n/a          Ready    system   record    portal    55m             _portal_system_backup-20231104.095949.tar.gz
portal-record-c4d5s   20231106.121946   n/a          Ready    site     record    portal    25m             portal.fyre-ci-162245-master.fyre.ibm.com@ibm@api-connect-catalog-2-20231106.121946.tar.gz
portal-record-c7p5q   20231106.110330   n/a          Ready    system   record    portal    55m             _portal_system_backup-20231106.110330.tar.gz
portal-record-f5h2h   20231106.115701   n/a          Ready    system   record    portal    55m             _portal_system_backup-20231106.115701.tar.gz

PortalBackup CRs with CR TYPE of create can be ignored. Create type CRs are generated when a backup is triggered manually, they are used to generate the record type PortalBackup CRs that hold the actual portal database backup. You can delete create type CRs after its corresponding record type CRs are created.

You can filter out create type CRs from

kubectl get
portalbackup

output with grep:

kubectl get portalbackup | grep record

When you create a backup of type 'all', the following PortalBackup CRs are created:

PortalBackup CR of type 'system' that contains the portal system data, which is everything in the portal database that applies to all sites.
For each site, a PortalBackup CR of type 'site' that contains all the data that is related to the site, such as Drupal site customizations.

For example if your portal has three sites, you get 4 PortalBackup CRs:


portal-record-222cg   20230108.010033                Ready    system   record  
portal-record-22xdc   20230108.010035                Ready    site     record  
portal-record-245j7   20230108.010037                Ready    site     record    
portal-record-246hm   20230108.010040                Ready    site     record

The portalBackupRecordDays property defines how many PortalBackup CRs are shown in the output of kubectl get portalbackup. The default is the last 30 days of CRs.

Portal performance can be negatively impacted if you have too many PortalBackup CRs, particularly during an upgrade. If you are taking backups more frequently than once a day, or have many sites, then it is recommended to reduce the portalBackupRecordDays property to a lower value. You can still keep as many backups as you want on your remote server, but if they don't have a corresponding PortalBackup CR then you must restore them using the .tgz file name or timestamp, see: Restoring from a portal database backup.

Portal backup .tgz files

For most operations that involve portal database backups, you work with a backup ID or a datestamp of the backup you want to restore, but some operations might require identifying the backup file name.

Portal database backups are contained in compressed archived files (TGZ), the name of the file is shown in the last column of the kubectl get portalbackup -o wide output:

kubectl -n <portal namespace> get portalbackup -o wide

Example output:

NAME                  ID                TASK ID      STATUS   TYPE     CR TYPE   CLUSTER   AGE   COMMENT   FILENAME
portal-record-2vcgs   20231105.181212   n/a          Ready    system   record    portal    55m             _portal_system_backup-20231105.181212.tar.gz