Running an on-demand backup of the portal database
Deploy the PortalBackup
CR to initiate a backup of the portal
database.
About this task
Note: If you are taking a portal database backup, you must also take a management database backup at
the same time. Management and portal databases must be kept in sync.
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.Procedure
-
Decide which type of backup you want to take:
all
: backs up the Developer Portal system and all its sites.system
: backs up the Developer Portal system only.site
: backs up a specific Developer Portal site.
Note: Developer Portal system backup includes all the portal configuration that is not specific to sites, such as IP allowlist. - Identify the name of the portal cluster that you want to backup:
kubectl -n <portal namespace> get PortalCluster
- Create a file called portalbackup_cr.yaml and
paste in the following text:
where:apiVersion: portal.apiconnect.ibm.com/v1beta1 kind: PortalBackup metadata: generateName: portal-bup- spec: type: <type> portalCluster: <portal cluster name> crType: create siteName: <site to backup> comment: "<comment>"
type
is the backup type that you decided in step 1.portalCluster
is the cluster name that you identified in step 2.siteName
is the name of the portal site that you want to backup. This property applies only when backup type ofsite
is specified. Valid settings are:- Site UUID or URL - back up the specified site only.
installed
- backups all installed sites.
comment
is a text comment to help you identify the reason for the backup, for example: "pre-upgrade backup".
- Create the
PortalBackup
CR from the portalbackup_cr.yaml file:kubectl -n <portal namespace> create -f portalbackup_cr.yaml
- Verify that the backup is running with:
$ kubectl -n <portal namespace> get portalbackup --sort-by=.status.backupId
The expected output for anall
type backup is:
For every on-demand backup triggered at least twoNAME ID TASK ID STATUS TYPE CR TYPE CLUSTER AGE COMMENT portal-record-89dgz 20200526.142449 n/a Ready system record portal 55m portal-record-89dgz 20200526.142458 n/a Ready site record portal 54m p1-bup-st4l2 n/a Ready all create portal 56m y
PortalBackup
CRs are created:Create
. Thecreate
CR type is the first CR to be created. Thecreate
CR does not create the portal database backup itself, but is responsible for creatingrecord
typePortalBackup
CRs, which are representations of individual backups.Record
. Therecord
PortalBackup
CR has two types:System
. TheSystem
record type represents one system backup file, containing the portal configuration that applies to all sitesSite
. TheSite
record type represents a backup file for one site. Site backups contain any Drupal customizations made to the site.
- You can get a detailed view of a specific backup CR by using the command:
kubectl -n <portal namespace> get portalbackup <backup name> -o yaml
Example output for acreate
type backup CR:apiVersion: portal.apiconnect.ibm.com/v1beta1 kind: PortalBackup metadata: creationTimestamp: "2020-10-01T10:00:16Z" generateName: portal-bup- generation: 1 name: portal-bup-g66gv namespace: default resourceVersion: "8940" selfLink: /apis/portal.apiconnect.ibm.com/v1beta1/namespaces/default/portalbackups/portal-bup-g66gv uid: b1d5b295-b966-48f2-b6ef-dfcd1c499741 spec: comment: test comment portalCluster: portal crType: create siteName: installed type: site status: backupId: "" commentLeft: "y" conditions: - lastTransitionTime: "2020-10-01T10:00:18Z" reason: BackupFailed status: "False" type: Error - lastTransitionTime: "2020-10-01T10:01:19Z" message: |- 2020-10-01 10:00:18: CLI task (backup:site) starting. 2020-10-01 10:00:20: Making a backup for site conor.com 2020-10-01 10:00:27: A local backup was succesfully created: /var/aegir/backups/conor.com-20201001.100021.tar.gz 2020-10-01 10:00:30: Attempting to upload backup to remote backup server 2020-10-01 10:00:30: Uploading conor.com-20201001.100021.tar.gz to s3.eu-gb.cloud-object-storage.appdomain.cloud/eu-standard:22:cq-test/ptlcq4/ using objstore 2020-10-01 10:00:33: Site with URL conor.com (conor.com-20201001.100021.tar.gz) successfully uploaded 2020-10-01 10:00:33: All installed sites have been successfully backed up 2020-10-01 10:00:33: CLI task (backup:site) completed successfully. reason: BackupComplete status: "True" type: Ready - lastTransitionTime: "2020-10-01T10:01:19Z" reason: BackupInProgress status: "False" type: Running - lastTransitionTime: "2020-10-01T10:00:18Z" reason: BackupStatusUnknown status: "False" type: Warning fullBackupName: "" id: f8t0ux7z4zfnnjnu message: "" phase: Ready state: ""
Examplerecord
CR type backup:
Observe the property showing the filename of the backup: portal_system_backup-20230922.083722.tar.gz.Name: portal-record-gxb4s Namespace: default Labels: createdBy=ibm-apiconnect Annotations: <none> API Version: portal.apiconnect.ibm.com/v1beta1 Kind: PortalBackup Metadata: Creation Timestamp: 2023-09-22T08:38:01Z Generate Name: portal-record- Generation: 1 Owner References: API Version: portal.apiconnect.ibm.com/v1beta1 Block Owner Deletion: true Controller: true Kind: PortalCluster Name: portal UID: 1318ae60-20f5-457a-aa86-7cf3961e9bf3 Resource Version: 640709 UID: 7fd18137-c77d-440f-8393-5699f6b22457 Spec: Comment: Cr Type: record Portal Cluster: portal Site Name: Type: system Status: Backup Id: 20230922.083722 Comment Left: Conditions: Last Transition Time: 2023-09-22T08:38:02Z Message: Reason: BackupStatusUnknown Status: False Type: Warning Last Transition Time: 2023-09-22T08:38:02Z Message: Record Backup CR for _portal_system_backup-20230922.083722.tar.gz Reason: BackupComplete Status: True Type: Ready Last Transition Time: 2023-09-22T08:38:02Z Message: Reason: BackupInProgress Status: False Type: Running Last Transition Time: 2023-09-22T08:38:02Z Message: Reason: BackupFailed Status: False Type: Error Full Backup Name: _portal_system_backup-20230922.083722.tar.gz Id: n/a Message: Phase: Ready State: Events: <none>