Cloudera Docs

Key Data Recovery Scenarios

The framework covers two primary data recovery models depending on the scope of the disaster.

  • Secondary Cluster Restore: Used when an entire production (primary) cluster is destroyed, lost, or unreachable. Data is restored from external storage (S3) into a separate, dedicated Disaster Recovery (DR) secondary cluster.
  • Same-Cluster Restore: Used for localized failures or data corruption (for example, accidental deletions) where the cluster remains healthy, but the system needs to revert to a previous healthy state.

Prerequisite Configuration

  • Both the primary and secondary clusters must be connected to the exact same external S3 storage bucket destination.
  • The secondary (DR) cluster operates in a clean state until a restore procedure is initiated.

Secondary Cluster Restore

In the event of an impending data loss situation in your primary cluster, you can restore the backed up data from the Primary cluster to a secondary cluster. This is referred to as Disaster Recovery.

Before you start this process, you must be aware about the existing functionality and take action accordingly:

  • As part of its creation and backing up the data to the external storage S3, the existing Primary cluster environment points to its own unique Cloudera Manager and Base versions.
  • As part of the restore operations, you must repoint or update the Primary cluster based Cloudera Manager and Base cluster details with the Secondary cluster based Cloudera Manager and Base details to establish connectivity. The S3 bucket name must be the same on both the Primary and Secondary clusters.
  1. Backup generation: The primary cluster continuously or periodically pushes control plane state, data, and service configurations to the designated external S3 bucket.
  2. Backup discovery: The secondary cluster detects available backup snapshots from the shared S3 bucket in real time.
  3. Trigger restoration: In a likely event of a primary cluster outage, initiate the Restore procedure directly from the secondary cluster.
  4. Cloudera Control Plane Rewiring (Re-pointing):
    • During the restore configuration step, select the secondary cluster's environment settings.
    • This updates all references to point to the secondary Cloudera Manager (CM2) instead of the original primary Cloudera Manager (CM1).
  5. Cluster Environment Wipe: The secondary cluster automatically clears its existing base environment to prepare for state replacement.
  6. State and Data Injection: The Cloudera Control Plane state, data services, and rewired configuration pointers are pulled from S3 and applied to the secondary cluster, making it the new active primary.

Same-Cluster Restore

This is also referred to as In-Place restore.
  1. Trigger Local Restore: Navigate to the Backup and Restore page on the active primary cluster.
  2. Select Snapshot: Choose the target historical backup snapshot stored in S3.
  3. Execute In-Place Restore: Initiate Start Restore operation.