Doc-1601: Specify cluster UUID to restore with Whole Cluster Recovery

[Feediver1]

Description

Resolves https://redpandadata.atlassian.net/browse/DOC-1601

IIUC, this feature is for Redpanda Support. I included more detail to help Support when using this config. If not solely for support, I can remove all the explanations and just include a paragraph with a description of the config and what it does, along with a note telling users not to use it without contacting RP Support first.

Review deadline: Dec 19th

Page previews

(https://deploy-preview-1513--redpanda-docs-preview.netlify.app/current/manage/disaster-recovery/whole-cluster-restore/#advanced-restore-data-when-multiple-clusters-share-data)

Checks

• [x ] New feature
• Content gap
• Support Follow-up
• Small fix (typos, links, copyedits, etc)

[netlify]

✅ Deploy Preview for redpanda-docs-preview ready!

Name	Link
🔨 Latest commit	5087b70
🔍 Latest deploy log	https://app.netlify.com/projects/redpanda-docs-preview/deploys/6945acf52f79bc0008793f37
😎 Deploy Preview	https://deploy-preview-1513--redpanda-docs-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

📝 Walkthrough

Walkthrough

This pull request adds comprehensive documentation to the Whole Cluster Restore section, covering behavior when multiple Redpanda clusters share the same object storage bucket. The changes explain the role of cluster UUIDs in manifest selection, provide naming conventions and examples for disambiguating clusters using cloud_storage_cluster_name, document multi-cluster sharing scenarios, and expand troubleshooting guidance with Admin API recovery override via cluster_uuid_override.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

• Documentation-only change affecting a single .adoc file
• No code logic, configuration, or structural changes
• Review should focus on:
  • Accuracy of cluster UUID and manifest selection explanations
  • Correctness of cloud_storage_cluster_name naming rules (character limits and allowed characters)
  • Validity of Admin API examples and recovery override syntax
  • Consistency and clarity of multi-cluster bucket layout examples with actual product behavior

Suggested reviewers

• micheleRP
• asimms41

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main documentation change: adding documentation for specifying cluster UUID in Whole Cluster Recovery.
Linked Issues check	✅ Passed	The PR documentation changes directly address DOC-1601's objective to document the cluster UUID specification feature for Whole Cluster Recovery, including usage scenarios and configuration details.
Out of Scope Changes check	✅ Passed	All changes are documentation-focused and directly related to the objective of documenting cluster UUID specification in Whole Cluster Recovery, with no unrelated modifications.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description check	✅ Passed	The pull request description includes all required sections: JIRA ticket reference, review deadline, page previews, and completed checklist indicating this is a new feature.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[mattschumpert]

@Feediver1

1. Terminology needs adjustment here. The heading is not 'when multiple clusters share data' its' when data from multiple clusters exists in the same bucket/container'
2. Content is quite useful but I think this should be moved to an internal Wiki page (not in public docs), without any objection from @nvartolomei , @andrwng

[nvartolomei]

@mattschumpert i'm fine with public doc unless it is a business/product concern. My argument is that our internal teams consume the same docs. There isn't anything to hide either. We already have this documented in the code.

[mattschumpert]

Up to you. We should be clear in the docs though this only occurs in extreme cases where multiple clusters have accidentally been sharing a bucket due to misconfiguration or a cluster lost quorum etc. I leave it to you / @andrwng to sort this out with @Feediver1

[nvartolomei]

That's beyond what I would have expected for us to have documented but looks great! 🤟

[nvartolomei]

For example, you might wish to mount topics to multiple clusters in the same bucket without having to move data.

you might wish to move topics (unmount on cluster A, mount on cluster B)