# Whole Cluster Restore for Disaster Recovery > For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [streaming-full.txt](https://docs.redpanda.com/streaming-full.txt) --- title: Whole Cluster Restore for Disaster Recovery latest-operator-version: v26.1.4 # EOL = End-of-Life (support lifecycle status) page-is-nearing-eol: "false" page-is-past-eol: "true" page-eol-date: July 31, 2025 latest-console-tag: v3.7.3 latest-connect-version: 4.93.0 docname: whole-cluster-restore page-component-name: streaming page-version: "24.2" page-component-version: "24.2" page-component-title: Streaming page-relative-src-path: whole-cluster-restore.adoc page-edit-url: https://github.com/redpanda-data/docs/edit/v/24.2/modules/manage/pages/whole-cluster-restore.adoc description: Restore a failed cluster, including its metadata. page-git-created-date: "2023-12-22" page-git-modified-date: "2024-02-26" support-status: past end-of-life --- With [Tiered Storage](https://docs.redpanda.com/streaming/24.2/manage/tiered-storage/) enabled, you can use whole cluster restore to restore data from a failed cluster (source cluster), including its metadata, onto a new cluster (target cluster). This is a simpler and cheaper alternative to active-active replication, for example with [MirrorMaker 2](https://docs.redpanda.com/streaming/24.2/upgrade/migrate/data-migration/). Use this recovery method to restore your application to the latest functional state as quickly as possible. > 📝 **NOTE** > > You cannot use whole cluster restore if the target cluster is in [recovery mode](https://docs.redpanda.com/streaming/24.2/manage/recovery-mode/). > ⚠️ **CAUTION** > > Whole cluster restore is not a fully-functional disaster recovery solution. It does not provide snapshot-style consistency. Some partitions in some topics will be more up-to-date than others. Committed transactions are not guaranteed to be atomic. > > If you need to restore only a subset of topic data, consider using [topic recovery](https://docs.redpanda.com/streaming/24.2/manage/topic-recovery/) instead of a whole cluster restore. The following metadata is included in a whole cluster restore: - Topic definitions. If you have enabled Tiered Storage only for specific topics, topics without Tiered Storage enabled will be restored empty. - Users and access control lists (ACLs). - [Schemas](https://docs.redpanda.com/streaming/24.2/manage/schema-reg/schema-reg-overview/). To ensure that your schemas are also archived and restored, you must also enable Tiered Storage for the `_schemas` topic. - The [consumer offsets topic](https://docs.redpanda.com/streaming/24.2/develop/consume-data/consumer-offsets/). Some restored committed consumer offsets may be truncated to a lower value than in the original cluster, to keep offsets at or below the highest restored offset in the partition. - Transaction metadata, up to the highest committed transaction. In-flight transactions are treated as aborted and will not be included in the restore. - [Cluster configurations](https://docs.redpanda.com/streaming/24.2/reference/properties/cluster-properties/), including your Redpanda license key, with the exception of the following properties: - `cloud_storage_cache_size` - `cluster_id` - `cloud_storage_access_key` - `cloud_storage_secret_key` - `cloud_storage_region` - `cloud_storage_bucket` - `cloud_storage_api_endpoint` - `cloud_storage_credentials_source` - `cloud_storage_trust_file` - `cloud_storage_backend` - `cloud_storage_credentials_host` - `cloud_storage_azure_storage_account` - `cloud_storage_azure_container` - `cloud_storage_azure_shared_key` - `cloud_storage_azure_adls_endpoint` - `cloud_storage_azure_adls_port` ## [](#manage-source-metadata-uploads)Manage source metadata uploads By default, Redpanda uploads cluster metadata to object storage periodically. You can manage metadata uploads for your source cluster, or disable them entirely, with the following cluster configuration properties: - [`enable_cluster_metadata_upload_loop`](https://docs.redpanda.com/streaming/24.2/reference/properties/cluster-properties/#enable_cluster_metadata_upload_loop): Enable metadata uploads. This property is enabled by default and is required for whole cluster restore. - [`cloud_storage_cluster_metadata_upload_interval_ms`](https://docs.redpanda.com/streaming/24.2/reference/properties/object-storage-properties/#cloud_storage_cluster_metadata_upload_interval_ms): Set the time interval to wait between metadata uploads. - [`controller_snapshot_max_age_sec`](https://docs.redpanda.com/streaming/24.2/reference/properties/cluster-properties/#controller_snapshot_max_age_sec): Maximum amount of time that can pass before Redpanda attempts to take a controller snapshot after a new controller command appears. This property affects how current the uploaded metadata can be. > 📝 **NOTE** > > You can monitor the [redpanda\_cluster\_latest\_cluster\_metadata\_manifest\_age](https://docs.redpanda.com/streaming/24.2/reference/public-metrics-reference/#redpanda_cluster_latest_cluster_metadata_manifest_age) metric to track the age of the most recent metadata upload. ## [](#restore-data-from-a-source-cluster)Restore data from a source cluster To restore data from a source cluster: 1. [Start a target cluster](#start-a-target-cluster) (new cluster). 2. [Restore data from a failed source cluster to the new cluster](#restore-to-target-cluster). ### [](#prerequisites)Prerequisites You must have the following: - [Tiered Storage](https://docs.redpanda.com/streaming/24.2/manage/tiered-storage/) enabled on the source cluster. - Physical or virtual machines on which to deploy the target cluster. ### [](#limitations)Limitations - Whole cluster restore supports only one source cluster. It is not possible to consolidate multiple clusters onto the target cluster. - If a duplicate cluster configuration is found in the target cluster, it will be overwritten by the restore. - The target cluster should not contain user-managed or application-managed topic data, schemas, users, ACLs, or ongoing transactions. ### [](#start-a-target-cluster)Start a target cluster Follow the steps to [deploy a new cluster](https://docs.redpanda.com/streaming/24.2/deploy/deployment-option/self-hosted/manual/). > 📝 **NOTE** > > Make sure to configure the target cluster with the same Tiered Storage settings as the source cluster. ### [](#restore-to-target-cluster)Restore to target cluster You can restore data from a source cluster to a target cluster using the [`rpk cluster storage restore`](https://docs.redpanda.com/streaming/24.2/reference/rpk/rpk-cluster/rpk-cluster-storage-restore/) command. 1. Restore data from the source cluster: ```bash rpk cluster storage restore start -w ``` The wait flag (`-w`) tells the command to poll the status of the restore process and then exit when completed. 2. Check if a rolling restart is required: ```bash rpk cluster config status ``` Example output when a restart is required: ```bash NODE CONFIG-VERSION NEEDS-RESTART INVALID UNKNOWN 1 4 true [] [] ``` 3. If a restart is required, perform a [rolling restart](https://docs.redpanda.com/streaming/24.2/manage/cluster-maintenance/rolling-restart/). When the cluster restore is successfully completed successfully, you can redirect your application workload to the new cluster. Make sure to update your application code to use the new addresses of your brokers.