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

  1. 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.
  2. Identify the name of the portal cluster that you want to backup:
    kubectl -n <portal namespace> get PortalCluster
  3. Create a file called portalbackup_cr.yaml and paste in the following text:
    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>"
      
    where:
    • 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 of site 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".
  4. Create the PortalBackup CR from the portalbackup_cr.yaml file:
    kubectl -n <portal namespace> create -f portalbackup_cr.yaml
  5. Verify that the backup is running with:
    $ kubectl -n <portal namespace> get portalbackup --sort-by=.status.backupId
    The expected output for an all type backup is:
    NAME                   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
    
    For every on-demand backup triggered at least two PortalBackup CRs are created:
    • Create. The create CR type is the first CR to be created. The create CR does not create the portal database backup itself, but is responsible for creating record type PortalBackup CRs, which are representations of individual backups.
    • Record. The record PortalBackup CR has two types:
      • System. The System record type represents one system backup file, containing the portal configuration that applies to all sites
      • Site. The Site record type represents a backup file for one site. Site backups contain any Drupal customizations made to the site.
  6. 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 a create 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: ""
    Example record CR type backup:
    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>
    Observe the property showing the filename of the backup: portal_system_backup-20230922.083722.tar.gz.

What to do next

Take a database backup of the management subsystem that your portal is registered with. You must have management and portal database backups that are in sync with each other: Running an on-demand backup of the management database.