Liferay PaaS Experience: Backup and Restore

Backups in Liferay PaaS Experience capture two components of each environment’s state: the CloudSQL database (via a database snapshot) and the document library bucket contents (mirrored into a dedicated vault bucket in GCS).

Use backups to recover an environment from data loss or corruption, for example after a failed migration or accidental deletion.

Backups are always enabled, and Liferay manages where and how they’re stored, retained, and cleaned up. The only setting you control is when the automatic schedule runs.

Configuring the Schedule

Set the cron expression in your environment’s liferay.yaml:

backup:
    schedule: "0 5 * * *"

Field	Default	Description
backup.schedule	"0 5 * * *"	The cron expression for the scheduled backup creator, in the cluster’s timezone. Defaults to daily at 05:00.

Setting backup.schedule to the empty string ("") disables automatic backup creation. Manual, on-demand backups remain available either way, and cleanup continues to run on its own schedule, so existing backups are still removed as they age out.

After committing and pushing the change, confirm the next scheduled run on the Argo Workflows dashboard, under the backup-create-scheduler-cron-workflow cron workflow in your environment’s namespace.

Retention and Cleanup

Backups are retained for 30 days. A cleanup job runs daily at 02:00 cluster time and removes backups past that window, and the vault bucket’s lifecycle rule deletes the underlying objects two days later, after 32 days. The vault bucket uses the NEARLINE storage class. Neither the retention period nor the cleanup schedule is configurable.

Creating a Backup Manually

Submit backup and restore operations directly from the Argo Workflows UI you already access via single sign-on (see Liferay PaaS Experience). Neither operation requires CLI or cluster access.

1. In Argo Workflows, go to Workflow Templates.

2. Select backup-create-workflow-template.

3. Click Submit Workflows. No parameters are required.

The workflow creates a LiferayBackup custom resource, identifying the database instance and document library bucket to back up from your project and environment, then waits for it to report a Succeeded condition.

Each backup is named liferay-<project-id>-<environment-id>-<suffix>, where the platform generates the suffix. This is the name you supply when restoring.

Restoring from a Backup

Before You Start

Create at least one backup first, either manually or through the automatic schedule. The restore workflow reads its identifiers from the resulting LiferayBackup record, so that backup must have finished successfully before you can restore from it.

You can’t start a restore while one is already in progress. Submitting a second restore fails immediately.

Submitting a Restore

1. In Argo Workflows, go to Workflow Templates.

2. Select backup-restore-workflow-template under the namespace you’re restoring into. For example, to restore into dev, select the template under the dev namespace, which is the target of the restore.

3. Click Submit Workflows, and fill in:

   • liferay-backup-name: the name of the backup to restore, in the form liferay-<project-id>-<environment-id>-<suffix>.
   • liferay-backup-namespace: the namespace where that backup was created. This defaults to the namespace of the template you selected in step 2, so you only need to set it when restoring across environments (see below). It is not the restore’s target namespace, which is determined by the template you selected.

Restoring from a Different Environment

To restore a backup created in one environment into another, for example copying production data into staging to test a change against real data, select the workflow template under the target namespace (staging), then set liferay-backup-namespace to the source namespace where the backup was created (prod).

How Restore Works

The restore is a blue/green data-plane switch driven by an internal state machine tracking two values: the active data plane (blue or green, whichever currently receives traffic) and the restore phase (none, provisioning, or promoting).

The workflow progresses through these steps:

1. Discover state. Read the LiferayBackup, the current infrastructure state, the Liferay StatefulSet, and the blue/green document library buckets.

2. Provision the inactive plane. Set the restore phase to provisioning; wait for a new, empty CloudSQL instance on the inactive plane to become ready. The inactive document library bucket always exists already.

3. Restore in parallel. Restore the database snapshot into the newly-provisioned inactive CloudSQL instance, and mirror the backup vault’s contents into the inactive document library bucket so the destination exactly matches the backup.

4. Promote. Set the restore phase to promoting; wait for the promoted infrastructure to become ready.

5. Restart Liferay. Roll out a restart of the Liferay StatefulSet and wait for it to complete.

6. Clean up. Set the restore phase back to none; delete the old plane’s document library bucket contents and let its CloudSQL instance be removed.

If any step from provisioning through restart fails, a rollback occurs automatically: the restore phase resets to none, the active data plane reverts to the original, and the partially-populated inactive document library bucket is cleared. The infrastructure is never left in an inconsistent state.

Monitoring a Restore

Watch the workflow’s progress and logs directly in the Argo Workflows UI. This is the only place a restore’s live progress is visible. Grafana’s Central Hub links to a Backups dashboard covering backup run counts and success and failure rates over time, but it doesn’t surface restore status. See Metrics.