About the Backup service

The Backup operation of the Data Recovery Service performs a backup of the entire Cloudera Data Services on premises cluster.

Backup operation is initiated from the primary cluster. Backing up the data includes the K8s resources and Persistent Volumes (PV) that are required to restore services as-is on the secondary cluster. Cloudera Control Plane is a required entity for every backup process, irrespective of which Data Services that are involved as part of backing up the data is concerned. Additionally, backup and restore support for only the Cloudera Control Plane entity is available.

When Data Services are deployed, they register their backup entities, which is a logical unit of recovery and its associated namespaces. The registration process will be completed during the respective service creation lifecycle.

In Cloudera Data Engineering, a backup entity consists of a combination of one ‘CDE service’ + one or more ‘CDE Virtual Clusters’. This expands to a ‘dex-base-***’ namespace + one ‘dex-app-***’ namespace for each virtual cluster.

The backup metadata is the sole basis which implies that it is the definitive evidence for initiating the recovery process. By using the backedup metadata, the secondary cluster inspects the contents of a backup and executes restore operations with full context of the original cluster’s state.

The Backup Execution Lifecycle

This flow illustrates the sequential orchestration from trigger to external S3 persistence.

Understanding the backup operations

The end-user manages the end-to-end flow of the backup processes which comprises fine grain details of the data, storage entities, and governance capabilities.

Based on the backup entities registered by data services, the end user will be able to pick and choose the candidates for each configured backup. The default part of all the backup operations is managed by the Cloudera Control Plane entity. Users can choose the required entities that need to be restored from the backup.

S3-compatible storage is the one and the only single, centralized repository for all backup and recovery data.

Why this policy matters for disaster recovery:

Complete Independence: If your primary cluster goes down completely, the secondary cluster doesn't need to talk to the failed system or rely on its internal database.
Instant Discovery: The secondary cluster can read the metadata straight from S3 to see all available restore points.
Seamless Failover: You can reconstruct your environment on the secondary cluster without any dependency on the primary site.