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>"typeis the backup type that you decided in step 1.portalClusteris the cluster name that you identified in step 2.siteNameis the name of the portal site that you want to backup. This property applies only when backup type ofsiteis specified. Valid settings are:- Site UUID or URL - back up the specified site only.
installed- backups all installed sites.
commentis a text comment to help you identify the reason for the backup, for example: "pre-upgrade backup".
- Create the
PortalBackupCR 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.backupIdThe expected output for analltype 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 yPortalBackupCRs are created:Create. ThecreateCR type is the first CR to be created. ThecreateCR does not create the portal database backup itself, but is responsible for creatingrecordtypePortalBackupCRs, which are representations of individual backups.Record. TherecordPortalBackupCR has two types:System. TheSystemrecord type represents one system backup file, containing the portal configuration that applies to all sitesSite. TheSiterecord 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 yamlExample output for acreatetype 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: ""ExamplerecordCR 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>