1. Concepts Guide
  2. Appliance Administration Overview
  3. Backup and Restore

Backup and Restore

The integrated Private Cloud Appliance backup service is intended to protect the system configuration against data loss and corruption. It does not create backups of the customer environment; instead, this backup service stores the data required for system and service operation so that any crucial service or component can be restored to its last known healthy state.

The following filesystems are backed up:

  • PCA project: obj_share and MGMT_ROOT

  • public_ostore_project: Filesystems related to each tenancy created on the rack (for COS operations)

  • private_ostore project: Filesystem in private_ostore_project

In line with the microservice-based deployment model, the backup service orchestrates the various backup operations across the entire system and ensures data consistency and integrity, but it does not define the individual component backup requirements. That logic is part of the component backup plugins.

The backup plugin is the key element that determines which files are backed up for a given system component or service, and how the data is collected. For example, a simple file copy may work for certain files while a snapshot is required for other data, or in some cases a service may need to be stopped to allow the backup to be created. The plugin also determines the backup frequency and retention time. Each plugin registers with the backup service so that the backup service is aware of the active plugins and can schedule the required backup operations in a consistent manner as Kubernetes CronJobs. Plugins are aggregated into a backup profile; the backup profile is the task list that the backup service executes when a backup job is launched.

The backup data collected through the plugins is then stored by the backup service in a dedicated NFS share on the internal ZFS Storage Appliance, using ZFS encryption to ensure that the data at rest is secure. If required, the backup files can optionally be replicated to an external storage location.

When restoring a service or component from a backup, the service again relies on the logic provided by the plugin. A component restore process has two major phases: verification and data management. In the verification phase, the backup is evaluated for completeness and appropriateness in relation to the current condition of the component. In the data management phase, the required actions are taken to stop or suspend a component, replace the data, and restart or resume normal operation. As with backup, the operations to restore the data are specific to the component in question.

The default backup and restore implementation is to execute a global backup profile that covers the MySQL cluster database, the ZFS Storage Appliance configuration, a snapshot of the ZFS projects on the storage appliance, and all registered component backup plugins. The default profile is executed daily at midnight UTC and has a 14-day retention policy. Backups are stored in /nfs/shared_storage/backups/backup_*. All restore operations must be performed manually on a per-component basis.

Note:

In release 3.0.1 of Private Cloud Appliance, the Backup and Restore service is not available through the Service Web UI or Service CLI. Administrators cannot configure the backup schedule.

Automated restore operations based on the backup plugins are not possible. If a manual restore from a backup is required, contact Oracle for assistance.