Dev operations (beta)

The Dev operations (beta) feature is temporarily unavailable due to maintenance to improve the feature. The feature may still be visible on the Cockpit for some users, but it is currently not functioning as expected. Please bear with us while we work hard to improve DX Cloud for you.

The DX Cloud Dev operations section allows you to restore, copy, or download your project’s content database(s). You can also perform full backups in this part of the Cockpit.

dev operations overview

Backup & Restore

DX Cloud provides automatic Automatic backups as defined in your values.yml file in your project. You can easily use and manage these backups via the Cockpit by going to Dev Operations and selecting Backup & Restore. Here, you can choose to:

  • Restore: Restoring your backup from a point-in-time allows you to ensure that no content is lost and keeps things running smoothly in case you need to retrieve content from a specific point in time.

  • Copy: You can also copy a backup from one environment to another, creating a seamless development and deployment process.

  • Download: If needed, you can also download a backup in case you need it locally.

Prerequisites

To ensure that the Backup & Restore feature functions properly, the connected cluster and target environments need to meet certain prerequisites. Check out the following sections to ensure you can meet those prerequisites.

1. Install the Backup Manager

To trigger backup and restore actions via the Cockpit, it’s required that you run a central-backup server in the cluster that is connected to the object storage storing all your environments' backups. Commonly, it’s a AWS S3 Bucket that is used to store the database backups.

The following yaml file could be used to install the backup-central server, after modifying the S3 Bucket parameters:

backupcentral.yaml

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backup-central
  labels:
    app: backup-central
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: backup-central
  template:
    metadata:
      labels:
        app: backup-central
    spec:
      containers:
        - name: backup-central
          image: registry.gitlab.com/mironet/magnolia-backup:v0.5.7 # May replace with a more recent version
          imagePullPolicy: Always
          ports:
            - containerPort: 9999
          command:
            - /app
            - "dump"
            - "--mode"
            - "server"
            - "--readonly"
            - "--ignore-heritage"
          env:
            - name: MGNLBACKUP_ADDRESS
              value: :9999
            - name: MGNLBACKUP_PG_DATA
              value: /db/data
            - name: MGNLBACKUP_USE_PG_WAL
              value: "true"
            - name: MGNLBACKUP_SYNC_DIR
              value: /archive
            - name: MGNLBACKUP_NO_STDOUT
              value: "true"
            - name: MGNLBACKUP_LOGLEVEL
              value: debug
            - name: MGNLBACKUP_BUCKET (1)
              value: mymagnolia-backup-bucket
            - name: MGNLBACKUP_S3_ENDPOINT (1)
              value: s3.eu-west-2.amazonaws.com
            - name: MGNLBACKUP_S3_REGION (1)
              value: eu-west-2
            - name: MGNLBACKUP_S3_ACCESSKEY (1)
              valueFrom:
                secretKeyRef:
                  key: accesskey
                  name: s3-backup-key
            - name: MGNLBACKUP_S3_SECRETKEY
              valueFrom:
                secretKeyRef:
                  key: secretkey
                  name: s3-backup-key
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
---
apiVersion: v1
kind: Service
metadata:
  name: backup-central-svc
  labels:
    app.kubernetes.io/name: backup-central-svc
spec:
  clusterIP: None
  ports:
    - name: http
      port: 9999
      protocol: TCP
      targetPort: 9999
  selector:
    app: backup-central
  sessionAffinity: None
  type: ClusterIP
---
1 Configure parameters on your demand. More here
Secret s3-backup-key required to be defined on K8s Cluster to access accesskey and secretkey in target Namespace.
Install the server

To install the server, use the following command:

# Create new namespace (assign namespace to a "project" when using Rancher later)
$ kubectl create namespace backup

# Deploy customized Deployment and Service
$ kubectl apply -n backup -f backupcentral.yaml
deployment.apps/backup-central created
service/backup-central-svc created
It’s recommended to run backup-central in a separate namespace.
Uninstall the server

To uninstall the server, you could run:

$ k delete deployments.apps backup-central && k delete service backup-central-svc
deployment.apps "backup-central" deleted
service "backup-central-svc" deleted
Testing

For testing, you could enable port-forwarding and run a simple cURL command:

$ k get pods | grep backup
backup-central-54cff99759-xbm8f        1/1     Running       0          3m20s

$ k port-forward backup-central-54cff99759-xbm8f 9999
Forwarding from 127.0.0.1:9999 -> 9999
Forwarding from [::1]:9999 -> 9999

# Use cURL or visit URL with Browser:
$ curl -sH 'Accept: application/json' http://localhost:9999/list |jq

2. Magnolia deployment requirements

If you are using Magnolia-Helm for deploying your DX Cloud environment, it’s necessary and recommended to ensure that you have the following parameters set up.

Those changes are usually documented and set in the values.yaml files, used for the Helm Deployment. An example can be found here.

It’s sufficient to ensure the following parameters for both Magnolia Instances, Author and Public instances.
values.yaml
# Settings for magnoliaAuthor
magnoliaAuthor:
  db:
    contentsync: (1)
      enabled: true
    persistence: (2)
      size: 20Gi
    backup:
      enabled: true (3)
      env:
      - name: MGNLBACKUP_ADDRESS (4)
        value: 0.0.0.0:9999
      - name: MGNLBACKUP_CRON (5)
        value: "0 3 * * *"
      - name: MGNLBACKUP_CYCLE (6)
        value: "90,0,0" # Use only days for WAL archiving.
      - name: MGNLBACKUP_KEEPDAYS
        value: "30" # Cleanup Files in Object Storage
      - name: MGNLBACKUP_USE_PG_WAL (7)
        value: "true"

# Settings for magnoliaPublic
magnoliaPublic:
  db:
    contentsync: (1)
      enabled: true
    persistence: (2)
      size: 20Gi
    backup:
      enabled: true (3)
      env:
      - name: MGNLBACKUP_ADDRESS (4)
        value: 0.0.0.0:9999
      - name: MGNLBACKUP_CRON (5)
        value: "0 3 * * *"
      - name: MGNLBACKUP_CYCLE (6)
        value: "90,0,0" # Use only days for WAL archiving.
      - name: MGNLBACKUP_KEEPDAYS
        value: "30" # Cleanup Files in Object Storage
      - name: MGNLBACKUP_USE_PG_WAL (7)
        value: "true"
1 Enable contentsync pod. Contentsync Pod is required to perform restore. More details can be found here.
2 persistence size. persistence size determines the size of the database volume (default 10Gi).

If the volume size is to small for the target environment the restore will fail (WAL files will be temporarily restored to /db/data/pg_wal). The interval of basebackups (<6>) and rotation (<7>) will also have a high influence on the required amount of space. In that case, it’s required that you resize the volume by changing this value, redeploy, and possibly clean up the existing volumes/environments.

As a rule of thumb, the persistence.size should be at minimum 2-3x the size of the actual database to have enough space during a temporary restore action.
3 Enable backup. Make sure you have ongoing backups and a backup pod for the Magnolia Instance.
The parameters to set up the Backup Target are not displayed here, but need to be set up properly.
4 Enable Proxy for backup.
To trigger full backup dumps from the cockpit, it’s required to ensure proxy communication is possible.
5 Cron for basebackups. Set the Cronjob to perform full Backups to be uploaded to the Object Storage. Ongoing transactional backups will continuously be written and uploaded to the object store (after reaching 16MiB Chunksize).
6 Frequent Cleanup of WAL Files and Object Storage.

As the S3 Buckets may be slow down in response (and may timeout) when having too many Backups and or Backup Bundle files present, it’s highly recommended to set up the S3 Object Storage to maintain automatically with backup rotation and cleanup.

We recommend the following settings on MGNLBACKUP_CYCLE and MGNLBACKUP_KEEPDAYS for orientation.

  • MGNLBACKUP_CYCLE = Backup retention cycle in the format [daily,weekly,monthly].

  • MGNLBACKUP_KEEPDAYS = Keep this many days of backups as a maximum. If keepdays is set to 0 (default), backups are kept forever. If keepdays is set to a positive integer i, this is the same as i,0,0 for MGNLBACKUP_CYCLE.
7 Enable PG_WAL.

Fundamental setup to use Postgres Write-ahead-Logging to perform database backups and restore

General recommendations

Please always follow the recommendations from the latest magnolia-cloud-project-archetype which is hosted on Magnolia Nexus. This comes with a default values.yaml which can be used for orientation.

Backup & Restore will require using magnolia-helm in version 1.5.6 or higher. Older releases or using other versions for the inherited sub-components are neither tested nor supported.

Restore

To restore content from a backup from a point-in-time:

First, make sure you are at Dev operations > Backup & Restore.

  1. Choose the Restore action from the dropdown menu.

  2. Choose the environment and instance from which you want to restore content.

    The environment is typically production or integration. The instance is usually either all, public, or author.

  3. Choose the point-in-time (date/time) from which you want to restore content.

  4. Click Restore.

Copy

To copy content from a backup from one environment to another:

First, make sure you are at Dev operations > Backup & Restore.

  1. Choose the Copy action from the dropdown menu.

  2. Choose the environment and instance from which you want to copy content.

    The environment is typically production or integration. The instance is usually either all, public, or author.

  3. Choose the point-in-time (date/time) from which you want to copy content.

  4. Choose the environment to which you want to copy content.

  5. Click Copy.

Download

To download a backup:

First, make sure you are at Dev operations > Backup & Restore.

  1. Choose the Download action from the dropdown menu.

  2. Choose the environment and instance from which you want to download content.

    The environment is typically production or integration. The instance is usually either all, public, or author.

  3. Choose the point-in-time (date/time) from which you want to download content.

  4. Click Download.

    Downloads come as a JSON file known as a "Backup Bundle", including a time-limited download link to all required files needed to restore the status into a Postgres database. For more on restore bundles, see here.

Full backups

Creating a full backup of your content creates a copy of all content for your DX Cloud project in one operation.

To create a full backup:

  1. Go to Dev operations > Full backups.

  2. Select the environment you want to back up.

  3. Select the component (all, public, author).

  4. Click Create full backup.

This might take a while and is a great time to grab a nice cup of coffee.

Feedback

PaaS

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the Magnolia PaaS docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules