Repository: openshift/openshift-docs
Pull request #93059: [OSDOCS-12351]: Migrating etcd backup/restore docs to new etcd book
Author: login: lahinson
Labels: name: peer-review-done
description: Signifies that the peer review team has reviewed this PR
name: size/L
description: Denotes a PR that changes 100-499 lines, ignoring generated files.
name: branch/enterprise-4.19
Created: 2025-05-06T16:31:00Z | Merged: 2025-05-13T19:32:28Z

<!--- PR title format: [GH#<gh-issue-id>][BZ#<bz-issue-id>][OCPBUGS#<jira-issue-id>][OSDOCS#<jira-issue-id>]: <short-description-of-the-pr> --->

<!--- If your changes apply to the latest release and/or in-development version of OpenShift, open your PR against the `main` branch.
Do not create or rename a top-level directory (or any subdirectory in a directory that contains a hugebook.flag file) in the repository and topic map without checking with a docs program manager first.
If a book is being created or modified, there are changes on the Customer Portal that must also be made.

* For more details about the information requested in this template, see:
  https://github.com/openshift/openshift-docs/blob/main/contributing_to_docs/create_or_edit_content.adoc#submit-PR --->

Version(s): 4.19
<!--- Specify the version or versions of OpenShift your PR applies to. -->

Issue: https://issues.redhat.com/browse/OSDOCS-12351
<!--- Add a link to the Bugzilla, Jira, or GitHub issue, if applicable. --->

Link to docs preview: https://93059--ocpdocs-pr.netlify.app/openshift-enterprise/latest/etcd/etcd-backup.html
<!--- Add direct link(s) to the exact page(s) with updated content from the preview build. --->

QE review:
- [x] QE has approved this change.
<!--- QE approval is required to merge a PR except for changes that do not impact the meaning of the docs. --->

Note for peer reviewers: This PR migrates the etcd backup and restore content into the new etcd book. The content is largely unchanged.
<!--- Optional: Include additional context or expand the description here.--->

<!--- After you open your PR, ask for review from the OpenShift docs team:
  For community authors: Tag @openshift/team-documentation in a GitHub comment.--->



Diff:
diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
index 5f655f429c89..ee3a0fc824e6 100644
--- a/_topic_maps/_topic_map.yml
+++ b/_topic_maps/_topic_map.yml
@@ -2490,7 +2490,7 @@ Topics:
   File: etcd-practices
 - Name: Performance considerations for etcd
   File: etcd-performance
-- Name: Backing up etcd data
+- Name: Backing up and restoring etcd data
   File: etcd-backup
 - Name: Encrypting etcd data
   File: etcd-encrypt
diff --git a/etcd/etcd-backup.adoc b/etcd/etcd-backup.adoc
index d6e9b2d08472..0d1ef223f457 100644
--- a/etcd/etcd-backup.adoc
+++ b/etcd/etcd-backup.adoc
@@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+toc::[]
+
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member_{context}"]
+== Replacing an unhealthy etcd member
+
+The process to replace a single unhealthy etcd member depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or because the etcd pod is crashlooping.
+
+[NOTE]
+====
+If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to  xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state] instead of this procedure.
+
+If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates] instead of this procedure.
+
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+====
+
+// Identifying an unhealthy etcd member
+include::modules/restore-identify-unhealthy-etcd-member.adoc[leveloffset=+2]
+
+[.role=_additional-resources]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+
+// Determining the state of the unhealthy etcd member
+include::modules/restore-determine-state-etcd-member.adoc[leveloffset=+2]
+
+// Replacing an unhealthy etcd member whose machine is not running or whose node is not ready
+include::modules/restore-replace-stopped-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/control_plane_machine_management/cpmso-troubleshooting.adoc#cpmso-ts-etcd-degraded_cpmso-troubleshooting[Recovering a degraded etcd Operator]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2023/html/assisted_installer_for_openshift_container_platform/expanding-the-cluster#installing-primary-control-plane-node-unhealthy-cluster_expanding-the-cluster[Installing a primary control plane node on an unhealthy cluster]
+
+// Replacing an unhealthy etcd member whose etcd pod is crashlooping
+include::modules/restore-replace-crashlooping-etcd-member.adoc[leveloffset=+3]
+
+// Replacing an unhealthy baremetal stopped etcd member
+include::modules/restore-replace-stopped-baremetal-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-etcd_deleting-machine[Quorum protection with machine lifecycle hooks]
+
+[id="etcd-disaster-recovery_{context}"]
+== Disaster recovery
+
+The disaster recovery documentation provides information for administrators on how to recover from several disaster situations that might occur with their {product-title} cluster. As an administrator, you might need to follow one or more of the following procedures to return your cluster to a working state.
+
+[IMPORTANT]
+====
+Disaster recovery requires you to have at least one healthy control plane host.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-restoring-etcd-quorum-ha_etcd-backup[Restoring etcd quorum for high availability clusters]:: This solution handles situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. This solution does not require an etcd backup.
++
+[NOTE]
+====
+If you have a majority of your control plane nodes still available and have an etcd quorum, xref:../etcd/etcd-backup.adoc#replace-unhealthy-etcd-member_etcd-backup[replace a single unhealthy etcd member].
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]:: This solution handles situations where you want to restore your cluster to a previous state, for example, if an administrator deletes something critical. If you have taken an etcd backup, you can restore your cluster to a previous state.
++
+If applicable, you might also need to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates].
++
+[WARNING]
+====
+Restoring to a previous cluster state is a destructive and destablizing action to take on a running cluster. This procedure should only be used as a last resort.
+
+Before performing a restore, see xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring a cluster state] for more information on the impact to the cluster.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[Recovering from expired control plane certificates]:: This solution handles situations where your control plane certificates have expired. For example, if you shut down your cluster before the first certificate rotation, which occurs 24 hours after installation, your certificates will not be rotated and will expire. You can follow this procedure to recover from expired control plane certificates.
+
+// Testing restore procedures
+include::modules/dr-testing-restore-procedures.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]
+
+// Restoring etcd quorum for high availability clusters
+include::modules/dr-restoring-etcd-quorum-ha.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
+
+* xref:../installing/installing_bare_metal/ipi/ipi-install-expanding-the-cluster.adoc#replacing-a-bare-metal-control-plane-node_ipi-install-expanding[Replacing a bare-metal control plane node]
+
+// Restoring to a previous cluster state
+include::modules/dr-restoring-cluster-state-about.adoc[leveloffset=+2]
+
+// Restoring to a previous cluster state for a single node
+include::modules/dr-restoring-cluster-state-sno.adoc[leveloffset=+3]
+
+// Restoring to a previous cluster state
+include::modules/dr-restoring-cluster-state.adoc[leveloffset=+3]
+
+// Restoring a cluster from etcd backup manually
+include::modules/manually-restoring-cluster-etcd-backup.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
+* xref:../networking/accessing-hosts.adoc#accessing-hosts[Accessing hosts on Amazon Web Services in an installer-provisioned infrastructure cluster]
+* xref:../installing/installing_bare_metal/ipi/ipi-install-expanding-the-cluster.adoc#replacing-a-bare-metal-control-plane-node_ipi-install-expanding[Replacing a bare-metal control plane node]
+
+// Issues and workarounds for restoring a persistent storage state
+include::modules/dr-scenario-cluster-state-issues.adoc[leveloffset=+3]
+
+// Recovering from expired control plane certificates
+include::modules/dr-recover-expired-control-plane-certs.adoc[leveloffset=+2]
\ No newline at end of file
diff --git a/hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc b/hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc
index bcd840aded31..0d1e639fdbd7 100644
--- a/hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc
+++ b/hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="hcp-recovering-etcd-cluster"]
-= Recovering an unhealthy etcd cluster
+= Recovering an unhealthy etcd cluster for {hcp}
 include::_attributes/common-attributes.adoc[]
 :context: hcp-recovering-etcd-cluster
 
diff --git a/modules/backup-etcd.adoc b/modules/backup-etcd.adoc
index 9deecda30203..f31b3d00dc34 100644
--- a/modules/backup-etcd.adoc
+++ b/modules/backup-etcd.adoc
@@ -2,6 +2,7 @@
 //
 // * backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc
 // * post_installation_configuration/cluster-tasks.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="backing-up-etcd-data_{context}"]
diff --git a/modules/creating-recurring-etcd-backups.adoc b/modules/creating-recurring-etcd-backups.adoc
index e66c0f8a7fb0..02dfed17058b 100644
--- a/modules/creating-recurring-etcd-backups.adoc
+++ b/modules/creating-recurring-etcd-backups.adoc
@@ -1,5 +1,10 @@
+//Module included in the following assemblies:
+//
+// * etcd/etcd-backup.adoc
+
+:_mod-docs-content-type: PROCEDURE
 [id="creating-recurring-etcd-backups_{context}"]
-= Creating recurring etcd backups
+= Creating recurring automated etcd backups
 
 Follow these steps to create automated recurring backups of etcd.
 
@@ -190,7 +195,7 @@ $ oc apply -f etcd-backup-pvc.yaml
 
 . Create a custom resource definition (CRD) file named `etcd-recurring-backups.yaml`. The contents of the created CRD define the schedule and retention type of automated backups.
 +
-For the default retention type of `RetentionNumber` with 15 retained backups, use contents such as the following example:
+** For the default retention type of `RetentionNumber` with 15 retained backups, use contents such as the following example:
 +
 [source,yaml]
 ----
@@ -206,7 +211,7 @@ spec:
 ----
 <1> The `CronTab` schedule for recurring backups. Adjust this value for your needs.
 +
-To use retention based on the maximum number of backups, add the following key-value pairs to the `etcd` key:
+** To use retention based on the maximum number of backups, add the following key-value pairs to the `etcd` key:
 +
 [source,yaml]
 ----
@@ -225,7 +230,7 @@ spec:
 A known issue causes the number of retained backups to be one greater than the configured value.
 ====
 +
-For retention based on the file size of backups, use the following:
+** For retention based on the file size of backups, use the following:
 +
 [source,yaml]
 ----
diff --git a/modules/creating-single-etcd-backup.adoc b/modules/creating-single-etcd-backup.adoc
index 9788f6fa4682..b6c08b019324 100644
--- a/modules/creating-single-etcd-backup.adoc
+++ b/modules/creating-single-etcd-backup.adoc
@@ -1,10 +1,11 @@
 // Module included in the following assemblies:
 //
 // * backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="creating-single-etcd-backup_{context}"]
-= Creating a single etcd backup
+= Creating a single automated etcd backup
 
 Follow these steps to create a single etcd backup by creating and applying a custom resource (CR).
 
diff --git a/modules/dr-recover-expired-control-plane-certs.adoc b/modules/dr-recover-expired-control-plane-certs.adoc
index 2b6786c4cd4c..a5ddb30a0c2e 100644
--- a/modules/dr-recover-expired-control-plane-certs.adoc
+++ b/modules/dr-recover-expired-control-plane-certs.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
 // * disaster_recovery/scenario-3-expired-certs.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="dr-scenario-3-recovering-expired-certs_{context}"]
diff --git a/modules/dr-restoring-cluster-state-about.adoc b/modules/dr-restoring-cluster-state-about.adoc
index 0390ba4c3f41..c9e6d9890798 100644
--- a/modules/dr-restoring-cluster-state-about.adoc
+++ b/modules/dr-restoring-cluster-state-about.adoc
@@ -1,10 +1,13 @@
 // Module included in the following assemblies:
 //
 // * disaster_recovery/scenario-2-restoring-cluster-state.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: CONCEPT
 [id="dr-scenario-2-restoring-cluster-state-about_{context}"]
-= About restoring cluster state
+= Restoring to a previous cluster state
+
+To restore the cluster to a previous state, you must have previously backed up the `etcd` data by creating a snapshot. You will use this snapshot to restore the cluster state. For more information, see "Backing up etcd data".
 
 You can use an etcd backup to restore your cluster to a previous state. This can be used to recover from the following situations:
 
@@ -22,4 +25,4 @@ Restoring etcd effectively takes a cluster back in time and all clients will exp
 
 It can cause Operator churn when the content in etcd does not match the actual content on disk, causing Operators for the Kubernetes API server, Kubernetes controller manager, Kubernetes scheduler, and etcd to get stuck when files on disk conflict with content in etcd. This can require manual actions to resolve the issues.
 
-In extreme cases, the cluster can lose track of persistent volumes, delete critical workloads that no longer exist, reimage machines, and rewrite CA bundles with expired certificates.
+In extreme cases, the cluster can lose track of persistent volumes, delete critical workloads that no longer exist, reimage machines, and rewrite CA bundles with expired certificates.
\ No newline at end of file
diff --git a/modules/dr-restoring-cluster-state-sno.adoc b/modules/dr-restoring-cluster-state-sno.adoc
index ad348c9010c1..cc8a8dc27a91 100644
--- a/modules/dr-restoring-cluster-state-sno.adoc
+++ b/modules/dr-restoring-cluster-state-sno.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
 // * disaster_recovery/scenario-2-restoring-cluster-state.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="dr-restoring-cluster-state-sno_{context}"]
diff --git a/modules/dr-restoring-cluster-state.adoc b/modules/dr-restoring-cluster-state.adoc
index 064a99365b08..f3005d1a7026 100644
--- a/modules/dr-restoring-cluster-state.adoc
+++ b/modules/dr-restoring-cluster-state.adoc
@@ -2,6 +2,7 @@
 //
 // * disaster_recovery/scenario-2-restoring-cluster-state.adoc
 // * post_installation_configuration/cluster-tasks.adoc
+// * etcd/etcd-backup.adoc
 
 // Contributors: The documentation for this section changed drastically for 4.18+.
 
@@ -14,7 +15,7 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="dr-scenario-2-restoring-cluster-state_{context}"]
-= Restoring to a previous cluster state
+= Restoring to a previous cluster state for more than one node
 
 You can use a saved etcd backup to restore a previous cluster state or restore a cluster that has lost the majority of control plane hosts.
 
diff --git a/modules/dr-restoring-etcd-quorum-ha.adoc b/modules/dr-restoring-etcd-quorum-ha.adoc
index 81b3942bacae..e91458c08c64 100644
--- a/modules/dr-restoring-etcd-quorum-ha.adoc
+++ b/modules/dr-restoring-etcd-quorum-ha.adoc
@@ -1,12 +1,15 @@
 // Module included in the following assemblies:
 //
 // * disaster_recovery/quorum-restoration.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="dr-restoring-etcd-quorum-ha_{context}"]
 = Restoring etcd quorum for high availability clusters
 
-You can use the `quorum-restore.sh` script to instantly bring back a new single-member etcd cluster based on its local data directory and mark all other members as invalid by retiring the previous cluster identifier. No prior backup is required to restore the control plane from.
+You can use the `quorum-restore.sh` script to restore etcd quorum on clusters that are offline due to quorum loss. When quorum is lost, the {product-title} API becomes read-only. After quorum is restored, the {product-title} API returns to read/write mode.
+
+The `quorum-restore.sh` script instantly brings back a new single-member etcd cluster based on its local data directory and marks all other members as invalid by retiring the previous cluster identifier. No prior backup is required to restore the control plane from.
 
 For high availability (HA) clusters, a three-node HA cluster requires you to shut down etcd on two hosts to avoid a cluster split. On four-node and five-node HA clusters, you must shut down three hosts. Quorum requires a simple majority of nodes. The minimum number of nodes required for quorum on a three-node HA cluster is two. On four-node and five-node HA clusters, the minimum number of nodes required for quorum is three. If you start a new cluster from backup on your recovery host, the other etcd members might still be able to form quorum and continue service.
 
diff --git a/modules/dr-scenario-cluster-state-issues.adoc b/modules/dr-scenario-cluster-state-issues.adoc
index 8d5dba8e2fb6..e250b7f78d7f 100644
--- a/modules/dr-scenario-cluster-state-issues.adoc
+++ b/modules/dr-scenario-cluster-state-issues.adoc
@@ -2,6 +2,7 @@
 //
 // * disaster_recovery/scenario-2-restoring-cluster-state.adoc
 // * post_installation_configuration/cluster-tasks.adoc
+// * etcd/etcd-backup.adoc
 
 [id="dr-scenario-cluster-state-issues_{context}"]
 = Issues and workarounds for restoring a persistent storage state
diff --git a/modules/dr-testing-restore-procedures.adoc b/modules/dr-testing-restore-procedures.adoc
index c93a101acebc..ffa70a286101 100644
--- a/modules/dr-testing-restore-procedures.adoc
+++ b/modules/dr-testing-restore-procedures.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
 // * disaster_recovery/about-disaster-recovery.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="dr-testing-restore-procedures_{context}"]
diff --git a/modules/manually-restoring-cluster-etcd-backup.adoc b/modules/manually-restoring-cluster-etcd-backup.adoc
index 22ae14d135a3..26e217d65f7f 100644
--- a/modules/manually-restoring-cluster-etcd-backup.adoc
+++ b/modules/manually-restoring-cluster-etcd-backup.adoc
@@ -2,6 +2,7 @@
 //
 // * disaster_recovery/scenario-2-manually-restoring-cluster-etcd-backup.adoc
 // * post_installation_configuration/cluster-tasks.adoc
+// * etcd/etcd-backup.adoc
 
 
 :_mod-docs-content-type: PROCEDURE
diff --git a/modules/restore-determine-state-etcd-member.adoc b/modules/restore-determine-state-etcd-member.adoc
index e1a3e01b84b1..0552f2930cfc 100644
--- a/modules/restore-determine-state-etcd-member.adoc
+++ b/modules/restore-determine-state-etcd-member.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
 // * backup_and_restore/replacing-unhealthy-etcd-member.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="restore-determine-state-etcd-member_{context}"]
diff --git a/modules/restore-identify-unhealthy-etcd-member.adoc b/modules/restore-identify-unhealthy-etcd-member.adoc
index 2cf7a828e078..db6feb6c83f0 100644
--- a/modules/restore-identify-unhealthy-etcd-member.adoc
+++ b/modules/restore-identify-unhealthy-etcd-member.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
 // * backup_and_restore/replacing-unhealthy-etcd-member.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="restore-identify-unhealthy-etcd-member_{context}"]
@@ -10,7 +11,8 @@ You can identify if your cluster has an unhealthy etcd member.
 
 .Prerequisites
 
-* Access to the cluster as a user with the `cluster-admin` role.
+* You have access to the cluster as a user with the `cluster-admin` role.
+* You have taken an etcd backup. For more information, see "Backing up etcd data".
 
 .Procedure
 
diff --git a/modules/restore-replace-crashlooping-etcd-member.adoc b/modules/restore-replace-crashlooping-etcd-member.adoc
index 77fbffb027b7..803b3d308a03 100644
--- a/modules/restore-replace-crashlooping-etcd-member.adoc
+++ b/modules/restore-replace-crashlooping-etcd-member.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
 // * backup_and_restore/replacing-unhealthy-etcd-member.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="restore-replace-crashlooping-etcd-member_{context}"]
diff --git a/modules/restore-replace-stopped-baremetal-etcd-member.adoc b/modules/restore-replace-stopped-baremetal-etcd-member.adoc
index 6322fd66c132..5dbe125d7cc5 100644
--- a/modules/restore-replace-stopped-baremetal-etcd-member.adoc
+++ b/modules/restore-replace-stopped-baremetal-etcd-member.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
 // * /backup_and_restore/control_plane_backup_and_restore/replacing-unhealthy-etcd-member.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="restore-replace-stopped-baremetal-etcd-member_{context}"]
diff --git a/modules/restore-replace-stopped-etcd-member.adoc b/modules/restore-replace-stopped-etcd-member.adoc
index 814bee245974..7f0dd470537c 100644
--- a/modules/restore-replace-stopped-etcd-member.adoc
+++ b/modules/restore-replace-stopped-etcd-member.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
 // * backup_and_restore/control_plane_backup_and_restore/modules/restore-replace-stopped-etcd-member.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="restore-replace-stopped-etcd-member_{context}"]


Reviews:
user: login: ocpdocs-vale-bot
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-07T14:42:59Z
user: login: ocpdocs-vale-bot
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-07T14:43:00Z
user: login: ocpdocs-vale-bot
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-07T14:43:04Z
user: login: ocpdocs-vale-bot
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-08T16:09:38Z
user: login: ocpdocs-vale-bot
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-08T16:09:39Z
user: login: lahinson
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-08T16:11:33Z
user: login: lahinson
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-08T16:11:40Z
user: login: skopacz1
body: Left a few comments, otherwise LGTM!
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-13T16:54:38Z
user: login: lahinson
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-13T17:26:19Z
user: login: lahinson
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-13T17:57:38Z
user: login: lahinson
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-13T18:06:50Z
user: login: lahinson
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-13T18:09:56Z
user: login: lahinson
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-13T18:13:55Z
user: login: lahinson
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-13T18:35:37Z
user: login: lahinson
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-13T18:44:36Z
user: login: lahinson
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-13T18:54:33Z

Review comments:
diff_hunk: @@ -1,7 +1,148 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
path: etcd/etcd-backup.adoc
user: login: ocpdocs-vale-bot
body: 🤖 **[error] OpenShiftAsciiDoc.XrefContainsAnchorID**: The xref is missing an anchor ID. 
created_at: 2025-05-07T14:42:59Z
author_association: COLLABORATOR
diff_hunk: @@ -1,7 +1,148 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
+
+This process depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or whether it is unhealthy because the etcd pod is crashlooping.
+
+[NOTE]
+====
+If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to  xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state] instead of this procedure.
+
+If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates] instead of this procedure.
+
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+====
+
+// Identifying an unhealthy etcd member
+include::modules/restore-identify-unhealthy-etcd-member.adoc[leveloffset=+2]
+
+[.role=_additional-resources]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+
+// Determining the state of the unhealthy etcd member
+include::modules/restore-determine-state-etcd-member.adoc[leveloffset=+2]
+
+// Replacing an unhealthy etcd member whose machine is not running or whose node is not ready
+include::modules/restore-replace-stopped-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+//* xref:../machine_management/control_plane_machine_management/cpmso-troubleshooting.adoc#cpmso-ts-etcd-degraded_cpmso-troubleshooting[Recovering a degraded etcd Operator]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2024/html/installing_openshift_container_platform_with_the_assisted_installer/expanding-the-cluster#installing-primary-control-plane-node-unhealthy-cluster_expanding-the-cluster[Installing a primary control plane node on an unhealthy cluster]
+
+// Replacing an unhealthy etcd member whose etcd pod is crashlooping
+include::modules/restore-replace-crashlooping-etcd-member.adoc[leveloffset=+3]
+
+// Replacing an unhealthy baremetal stopped etcd member
+include::modules/restore-replace-stopped-baremetal-etcd-member.adoc[leveloffset=+3]
+
+//[role="_additional-resources"]
+//.Additional resources
+//* xref:../../../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-etcd_deleting-machine[Quorum protection with machine lifecycle hooks]
+
+[id="etcd-disaster-recovery"]
+== Disaster recovery
+
+The disaster recovery documentation provides information for administrators on how to recover from several disaster situations that might occur with their {product-title} cluster. As an administrator, you might need to follow one or more of the following procedures to return your cluster to a working state.
+
+[IMPORTANT]
+====
+Disaster recovery requires you to have at least one healthy control plane host.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-restoring-etcd-quorum-ha_etcd-backup[Restoring etcd quorum for high availability clusters]:: This solution handles situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. This solution does not require an etcd backup.
++
+[NOTE]
+====
+If you have a majority of your control plane nodes still available and have an etcd quorum, xref:../etcd/etcd-backup.adoc#replacing-unhealthy-etcd-member_etcd-backup[replace a single unhealthy etcd member].
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]:: This solution handles situations where you want to restore your cluster to a previous state, for example, if an administrator deletes something critical. If you have taken an etcd backup, you can restore your cluster to a previous state.
++
+If applicable, you might also need to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates].
++
+[WARNING]
+====
+Restoring to a previous cluster state is a destructive and destablizing action to take on a running cluster. This procedure should only be used as a last resort.
+
+Prior to performing a restore, see xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring a cluster state] for more information on the impact to the cluster.
path: etcd/etcd-backup.adoc
user: login: ocpdocs-vale-bot
body: 🤖 **[error] RedHat.TermsErrors**: Use 'before' rather than 'Prior to'. For more information, see [RedHat.TermsErrors](https://redhat-documentation.github.io/vale-at-red-hat/docs/main/reference-guide/termserrors).
created_at: 2025-05-07T14:43:00Z
author_association: COLLABORATOR
diff_hunk: @@ -1,3 +1,7 @@
+//Module included in the following assemblies:
path: modules/creating-recurring-etcd-backups.adoc
user: login: ocpdocs-vale-bot
body: 🤖 **[error] OpenShiftAsciiDoc.ModuleContainsContentType**: Module is missing the '_mod-docs-content-type' variable. 
created_at: 2025-05-07T14:43:04Z
author_association: COLLABORATOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
+
+This process depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or whether it is unhealthy because the etcd pod is crashlooping.
+
+[NOTE]
+====
+If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to  xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state] instead of this procedure.
+
+If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates] instead of this procedure.
+
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+====
+
+// Identifying an unhealthy etcd member
+include::modules/restore-identify-unhealthy-etcd-member.adoc[leveloffset=+2]
+
+[.role=_additional-resources]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+
+// Determining the state of the unhealthy etcd member
+include::modules/restore-determine-state-etcd-member.adoc[leveloffset=+2]
+
+// Replacing an unhealthy etcd member whose machine is not running or whose node is not ready
+include::modules/restore-replace-stopped-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/control_plane_machine_management/cpmso-troubleshooting.adoc#cpmso-ts-etcd-degraded_cpmso-troubleshooting[Recovering a degraded etcd Operator]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2023/html/assisted_installer_for_openshift_container_platform/expanding-the-cluster#installing-primary-control-plane-node-unhealthy-cluster_expanding-the-cluster[Installing a primary control plane node on an unhealthy cluster]
+
+// Replacing an unhealthy etcd member whose etcd pod is crashlooping
+include::modules/restore-replace-crashlooping-etcd-member.adoc[leveloffset=+3]
+
+// Replacing an unhealthy baremetal stopped etcd member
+include::modules/restore-replace-stopped-baremetal-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-etcd_deleting-machine[Quorum protection with machine lifecycle hooks]
+
+[id="etcd-disaster-recovery"]
+== Disaster recovery
+
+The disaster recovery documentation provides information for administrators on how to recover from several disaster situations that might occur with their {product-title} cluster. As an administrator, you might need to follow one or more of the following procedures to return your cluster to a working state.
+
+[IMPORTANT]
+====
+Disaster recovery requires you to have at least one healthy control plane host.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-restoring-etcd-quorum-ha_etcd-backup[Restoring etcd quorum for high availability clusters]:: This solution handles situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. This solution does not require an etcd backup.
++
+[NOTE]
+====
+If you have a majority of your control plane nodes still available and have an etcd quorum, xref:../etcd/etcd-backup.adoc#replace-unhealthy-etcd-member[replace a single unhealthy etcd member].
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]:: This solution handles situations where you want to restore your cluster to a previous state, for example, if an administrator deletes something critical. If you have taken an etcd backup, you can restore your cluster to a previous state.
++
+If applicable, you might also need to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates].
++
+[WARNING]
+====
+Restoring to a previous cluster state is a destructive and destablizing action to take on a running cluster. This procedure should only be used as a last resort.
+
+Before performing a restore, see xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring a cluster state] for more information on the impact to the cluster.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[Recovering from expired control plane certificates]:: This solution handles situations where your control plane certificates have expired. For example, if you shut down your cluster before the first certificate rotation, which occurs 24 hours after installation, your certificates will not be rotated and will expire. You can follow this procedure to recover from expired control plane certificates.
+
+// Testing restore procedures
+include::modules/dr-testing-restore-procedures.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]
+
+// Restoring etcd quorum for high availability clusters
+include::modules/dr-restoring-etcd-quorum-ha.adoc[leveloffset=+2]
+
+[id="_additional-resources"]
+.Additional resources
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
path: etcd/etcd-backup.adoc
user: login: ocpdocs-vale-bot
body: 🤖 **[error] OpenShiftAsciiDoc.XrefContainsAnchorID**: The xref is missing an anchor ID. 
created_at: 2025-05-08T16:09:38Z
author_association: COLLABORATOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
+
+This process depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or whether it is unhealthy because the etcd pod is crashlooping.
+
+[NOTE]
+====
+If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to  xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state] instead of this procedure.
+
+If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates] instead of this procedure.
+
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+====
+
+// Identifying an unhealthy etcd member
+include::modules/restore-identify-unhealthy-etcd-member.adoc[leveloffset=+2]
+
+[.role=_additional-resources]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+
+// Determining the state of the unhealthy etcd member
+include::modules/restore-determine-state-etcd-member.adoc[leveloffset=+2]
+
+// Replacing an unhealthy etcd member whose machine is not running or whose node is not ready
+include::modules/restore-replace-stopped-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/control_plane_machine_management/cpmso-troubleshooting.adoc#cpmso-ts-etcd-degraded_cpmso-troubleshooting[Recovering a degraded etcd Operator]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2023/html/assisted_installer_for_openshift_container_platform/expanding-the-cluster#installing-primary-control-plane-node-unhealthy-cluster_expanding-the-cluster[Installing a primary control plane node on an unhealthy cluster]
+
+// Replacing an unhealthy etcd member whose etcd pod is crashlooping
+include::modules/restore-replace-crashlooping-etcd-member.adoc[leveloffset=+3]
+
+// Replacing an unhealthy baremetal stopped etcd member
+include::modules/restore-replace-stopped-baremetal-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-etcd_deleting-machine[Quorum protection with machine lifecycle hooks]
+
+[id="etcd-disaster-recovery"]
+== Disaster recovery
+
+The disaster recovery documentation provides information for administrators on how to recover from several disaster situations that might occur with their {product-title} cluster. As an administrator, you might need to follow one or more of the following procedures to return your cluster to a working state.
+
+[IMPORTANT]
+====
+Disaster recovery requires you to have at least one healthy control plane host.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-restoring-etcd-quorum-ha_etcd-backup[Restoring etcd quorum for high availability clusters]:: This solution handles situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. This solution does not require an etcd backup.
++
+[NOTE]
+====
+If you have a majority of your control plane nodes still available and have an etcd quorum, xref:../etcd/etcd-backup.adoc#replace-unhealthy-etcd-member[replace a single unhealthy etcd member].
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]:: This solution handles situations where you want to restore your cluster to a previous state, for example, if an administrator deletes something critical. If you have taken an etcd backup, you can restore your cluster to a previous state.
++
+If applicable, you might also need to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates].
++
+[WARNING]
+====
+Restoring to a previous cluster state is a destructive and destablizing action to take on a running cluster. This procedure should only be used as a last resort.
+
+Before performing a restore, see xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring a cluster state] for more information on the impact to the cluster.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[Recovering from expired control plane certificates]:: This solution handles situations where your control plane certificates have expired. For example, if you shut down your cluster before the first certificate rotation, which occurs 24 hours after installation, your certificates will not be rotated and will expire. You can follow this procedure to recover from expired control plane certificates.
+
+// Testing restore procedures
+include::modules/dr-testing-restore-procedures.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]
+
+// Restoring etcd quorum for high availability clusters
+include::modules/dr-restoring-etcd-quorum-ha.adoc[leveloffset=+2]
+
+[id="_additional-resources"]
+.Additional resources
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
+
+* xref:../installing/installing_bare_metal/ipi/ipi-install-expanding-the-cluster.adoc#replacing-a-bare-metal-control-plane-node_ipi-install-expanding[Replacing a bare-metal control plane node]
+
+// Restoring to a previous cluster state
+include::modules/dr-restoring-cluster-state-about.adoc[leveloffset=+2]
+
+// Restoring to a previous cluster state for a single node
+include::modules/dr-restoring-cluster-state-sno.adoc[leveloffset=+3]
+
+// Restoring to a previous cluster state
+include::modules/dr-restoring-cluster-state.adoc[leveloffset=+3]
+
+// Restoring a cluster from etcd backup manually
+include::modules/manually-restoring-cluster-etcd-backup.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
path: etcd/etcd-backup.adoc
user: login: ocpdocs-vale-bot
body: 🤖 **[error] OpenShiftAsciiDoc.XrefContainsAnchorID**: The xref is missing an anchor ID. 
created_at: 2025-05-08T16:09:39Z
author_association: COLLABORATOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
+
+This process depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or whether it is unhealthy because the etcd pod is crashlooping.
+
+[NOTE]
+====
+If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to  xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state] instead of this procedure.
+
+If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates] instead of this procedure.
+
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+====
+
+// Identifying an unhealthy etcd member
+include::modules/restore-identify-unhealthy-etcd-member.adoc[leveloffset=+2]
+
+[.role=_additional-resources]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+
+// Determining the state of the unhealthy etcd member
+include::modules/restore-determine-state-etcd-member.adoc[leveloffset=+2]
+
+// Replacing an unhealthy etcd member whose machine is not running or whose node is not ready
+include::modules/restore-replace-stopped-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/control_plane_machine_management/cpmso-troubleshooting.adoc#cpmso-ts-etcd-degraded_cpmso-troubleshooting[Recovering a degraded etcd Operator]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2023/html/assisted_installer_for_openshift_container_platform/expanding-the-cluster#installing-primary-control-plane-node-unhealthy-cluster_expanding-the-cluster[Installing a primary control plane node on an unhealthy cluster]
+
+// Replacing an unhealthy etcd member whose etcd pod is crashlooping
+include::modules/restore-replace-crashlooping-etcd-member.adoc[leveloffset=+3]
+
+// Replacing an unhealthy baremetal stopped etcd member
+include::modules/restore-replace-stopped-baremetal-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-etcd_deleting-machine[Quorum protection with machine lifecycle hooks]
+
+[id="etcd-disaster-recovery"]
+== Disaster recovery
+
+The disaster recovery documentation provides information for administrators on how to recover from several disaster situations that might occur with their {product-title} cluster. As an administrator, you might need to follow one or more of the following procedures to return your cluster to a working state.
+
+[IMPORTANT]
+====
+Disaster recovery requires you to have at least one healthy control plane host.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-restoring-etcd-quorum-ha_etcd-backup[Restoring etcd quorum for high availability clusters]:: This solution handles situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. This solution does not require an etcd backup.
++
+[NOTE]
+====
+If you have a majority of your control plane nodes still available and have an etcd quorum, xref:../etcd/etcd-backup.adoc#replace-unhealthy-etcd-member[replace a single unhealthy etcd member].
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]:: This solution handles situations where you want to restore your cluster to a previous state, for example, if an administrator deletes something critical. If you have taken an etcd backup, you can restore your cluster to a previous state.
++
+If applicable, you might also need to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates].
++
+[WARNING]
+====
+Restoring to a previous cluster state is a destructive and destablizing action to take on a running cluster. This procedure should only be used as a last resort.
+
+Before performing a restore, see xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring a cluster state] for more information on the impact to the cluster.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[Recovering from expired control plane certificates]:: This solution handles situations where your control plane certificates have expired. For example, if you shut down your cluster before the first certificate rotation, which occurs 24 hours after installation, your certificates will not be rotated and will expire. You can follow this procedure to recover from expired control plane certificates.
+
+// Testing restore procedures
+include::modules/dr-testing-restore-procedures.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]
+
+// Restoring etcd quorum for high availability clusters
+include::modules/dr-restoring-etcd-quorum-ha.adoc[leveloffset=+2]
+
+[id="_additional-resources"]
+.Additional resources
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
path: etcd/etcd-backup.adoc
user: login: lahinson
body: Ignoring this warning because the xref doesn't work when I add an anchor ID.
created_at: 2025-05-08T16:11:33Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
+
+This process depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or whether it is unhealthy because the etcd pod is crashlooping.
+
+[NOTE]
+====
+If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to  xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state] instead of this procedure.
+
+If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates] instead of this procedure.
+
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+====
+
+// Identifying an unhealthy etcd member
+include::modules/restore-identify-unhealthy-etcd-member.adoc[leveloffset=+2]
+
+[.role=_additional-resources]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+
+// Determining the state of the unhealthy etcd member
+include::modules/restore-determine-state-etcd-member.adoc[leveloffset=+2]
+
+// Replacing an unhealthy etcd member whose machine is not running or whose node is not ready
+include::modules/restore-replace-stopped-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/control_plane_machine_management/cpmso-troubleshooting.adoc#cpmso-ts-etcd-degraded_cpmso-troubleshooting[Recovering a degraded etcd Operator]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2023/html/assisted_installer_for_openshift_container_platform/expanding-the-cluster#installing-primary-control-plane-node-unhealthy-cluster_expanding-the-cluster[Installing a primary control plane node on an unhealthy cluster]
+
+// Replacing an unhealthy etcd member whose etcd pod is crashlooping
+include::modules/restore-replace-crashlooping-etcd-member.adoc[leveloffset=+3]
+
+// Replacing an unhealthy baremetal stopped etcd member
+include::modules/restore-replace-stopped-baremetal-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-etcd_deleting-machine[Quorum protection with machine lifecycle hooks]
+
+[id="etcd-disaster-recovery"]
+== Disaster recovery
+
+The disaster recovery documentation provides information for administrators on how to recover from several disaster situations that might occur with their {product-title} cluster. As an administrator, you might need to follow one or more of the following procedures to return your cluster to a working state.
+
+[IMPORTANT]
+====
+Disaster recovery requires you to have at least one healthy control plane host.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-restoring-etcd-quorum-ha_etcd-backup[Restoring etcd quorum for high availability clusters]:: This solution handles situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. This solution does not require an etcd backup.
++
+[NOTE]
+====
+If you have a majority of your control plane nodes still available and have an etcd quorum, xref:../etcd/etcd-backup.adoc#replace-unhealthy-etcd-member[replace a single unhealthy etcd member].
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]:: This solution handles situations where you want to restore your cluster to a previous state, for example, if an administrator deletes something critical. If you have taken an etcd backup, you can restore your cluster to a previous state.
++
+If applicable, you might also need to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates].
++
+[WARNING]
+====
+Restoring to a previous cluster state is a destructive and destablizing action to take on a running cluster. This procedure should only be used as a last resort.
+
+Before performing a restore, see xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring a cluster state] for more information on the impact to the cluster.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[Recovering from expired control plane certificates]:: This solution handles situations where your control plane certificates have expired. For example, if you shut down your cluster before the first certificate rotation, which occurs 24 hours after installation, your certificates will not be rotated and will expire. You can follow this procedure to recover from expired control plane certificates.
+
+// Testing restore procedures
+include::modules/dr-testing-restore-procedures.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]
+
+// Restoring etcd quorum for high availability clusters
+include::modules/dr-restoring-etcd-quorum-ha.adoc[leveloffset=+2]
+
+[id="_additional-resources"]
+.Additional resources
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
+
+* xref:../installing/installing_bare_metal/ipi/ipi-install-expanding-the-cluster.adoc#replacing-a-bare-metal-control-plane-node_ipi-install-expanding[Replacing a bare-metal control plane node]
+
+// Restoring to a previous cluster state
+include::modules/dr-restoring-cluster-state-about.adoc[leveloffset=+2]
+
+// Restoring to a previous cluster state for a single node
+include::modules/dr-restoring-cluster-state-sno.adoc[leveloffset=+3]
+
+// Restoring to a previous cluster state
+include::modules/dr-restoring-cluster-state.adoc[leveloffset=+3]
+
+// Restoring a cluster from etcd backup manually
+include::modules/manually-restoring-cluster-etcd-backup.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
path: etcd/etcd-backup.adoc
user: login: lahinson
body: Ignoring this warning because the xref doesn't work when I add an anchor ID.
created_at: 2025-05-08T16:11:40Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
path: etcd/etcd-backup.adoc
user: login: skopacz1
body: The second sentence seems a little important, would it be worth highlighting in an IMPORTANT admonition? (I see that there are already a lot of admonitions on this page, so I understand if you're hesitant to add more).

This is also unrelated, but I happen to be working on a partner RFE where I am trying to make recommendations more visible by adding them to notes. I am not saying you have to or should do that yourself, but this might be a good opportunity to make the last two sentences of this paragraph more visible because of their importance:

```suggestion
Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. 

[IMPORTANT]
====
Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
====
```

Totally up to you though
created_at: 2025-05-13T15:44:13Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
path: etcd/etcd-backup.adoc
user: login: skopacz1
body: I'm also realizing now that there's no TOC on the right hand side of the page:
```suggestion
toc::[]

As the key-value store for {product-title}, etcd persists the state of all resource objects.
```
created_at: 2025-05-13T16:05:51Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
path: etcd/etcd-backup.adoc
user: login: skopacz1
body: Just checking if it's intentional that these two sections have a level offset of 2. Right now, it appears as these two sections are nested under the procedure for creating automated backups (which seems to be a separate, tech preview feature)
created_at: 2025-05-13T16:12:22Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
path: etcd/etcd-backup.adoc
user: login: skopacz1
body: Per the [docs guidelines](https://github.com/openshift/openshift-docs/blob/main/contributing_to_docs/doc_guidelines.adoc#anchoring-titles-and-section-headings), all headings in modules and all subsection headings in assemblies need a context in their ID:
```suggestion
[id="replace-unhealthy-etcd-member_{context}"]
```
created_at: 2025-05-13T16:13:50Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
path: etcd/etcd-backup.adoc
user: login: skopacz1
body: Somewhere deep in this list on the [ISG](https://www.ibm.com/docs/en/ibm-style?topic=medium-global-audiences#style), it says to avoid self-referential text when possible. I normally don't care about instances like "the following procedures do X" but I guess something about "This document" stuck out to me.

I won't say it's required to rewrite, but could this maybe be rewritten to avoid such language? Or at the very least, maybe it could be more specific by saying "The following sections describe" rather than potentially referring to the entire assembly by accident
created_at: 2025-05-13T16:21:12Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
+
+This process depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or whether it is unhealthy because the etcd pod is crashlooping.
+
+[NOTE]
+====
+If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to  xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state] instead of this procedure.
+
+If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates] instead of this procedure.
+
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+====
+
+// Identifying an unhealthy etcd member
+include::modules/restore-identify-unhealthy-etcd-member.adoc[leveloffset=+2]
+
+[.role=_additional-resources]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+
+// Determining the state of the unhealthy etcd member
+include::modules/restore-determine-state-etcd-member.adoc[leveloffset=+2]
+
+// Replacing an unhealthy etcd member whose machine is not running or whose node is not ready
+include::modules/restore-replace-stopped-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/control_plane_machine_management/cpmso-troubleshooting.adoc#cpmso-ts-etcd-degraded_cpmso-troubleshooting[Recovering a degraded etcd Operator]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2023/html/assisted_installer_for_openshift_container_platform/expanding-the-cluster#installing-primary-control-plane-node-unhealthy-cluster_expanding-the-cluster[Installing a primary control plane node on an unhealthy cluster]
+
+// Replacing an unhealthy etcd member whose etcd pod is crashlooping
+include::modules/restore-replace-crashlooping-etcd-member.adoc[leveloffset=+3]
+
+// Replacing an unhealthy baremetal stopped etcd member
+include::modules/restore-replace-stopped-baremetal-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-etcd_deleting-machine[Quorum protection with machine lifecycle hooks]
+
+[id="etcd-disaster-recovery"]
path: etcd/etcd-backup.adoc
user: login: skopacz1
body: Same comment about IDs requiring contexts:
```suggestion
[id="etcd-disaster-recovery_{context}"]
```
created_at: 2025-05-13T16:26:00Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
+
+This process depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or whether it is unhealthy because the etcd pod is crashlooping.
+
+[NOTE]
+====
+If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to  xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state] instead of this procedure.
+
+If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates] instead of this procedure.
+
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+====
+
+// Identifying an unhealthy etcd member
+include::modules/restore-identify-unhealthy-etcd-member.adoc[leveloffset=+2]
+
+[.role=_additional-resources]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+
+// Determining the state of the unhealthy etcd member
+include::modules/restore-determine-state-etcd-member.adoc[leveloffset=+2]
+
+// Replacing an unhealthy etcd member whose machine is not running or whose node is not ready
+include::modules/restore-replace-stopped-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/control_plane_machine_management/cpmso-troubleshooting.adoc#cpmso-ts-etcd-degraded_cpmso-troubleshooting[Recovering a degraded etcd Operator]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2023/html/assisted_installer_for_openshift_container_platform/expanding-the-cluster#installing-primary-control-plane-node-unhealthy-cluster_expanding-the-cluster[Installing a primary control plane node on an unhealthy cluster]
+
+// Replacing an unhealthy etcd member whose etcd pod is crashlooping
+include::modules/restore-replace-crashlooping-etcd-member.adoc[leveloffset=+3]
+
+// Replacing an unhealthy baremetal stopped etcd member
+include::modules/restore-replace-stopped-baremetal-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-etcd_deleting-machine[Quorum protection with machine lifecycle hooks]
+
+[id="etcd-disaster-recovery"]
+== Disaster recovery
+
+The disaster recovery documentation provides information for administrators on how to recover from several disaster situations that might occur with their {product-title} cluster. As an administrator, you might need to follow one or more of the following procedures to return your cluster to a working state.
+
+[IMPORTANT]
+====
+Disaster recovery requires you to have at least one healthy control plane host.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-restoring-etcd-quorum-ha_etcd-backup[Restoring etcd quorum for high availability clusters]:: This solution handles situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. This solution does not require an etcd backup.
++
+[NOTE]
+====
+If you have a majority of your control plane nodes still available and have an etcd quorum, xref:../etcd/etcd-backup.adoc#replace-unhealthy-etcd-member[replace a single unhealthy etcd member].
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]:: This solution handles situations where you want to restore your cluster to a previous state, for example, if an administrator deletes something critical. If you have taken an etcd backup, you can restore your cluster to a previous state.
++
+If applicable, you might also need to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates].
++
+[WARNING]
+====
+Restoring to a previous cluster state is a destructive and destablizing action to take on a running cluster. This procedure should only be used as a last resort.
+
+Before performing a restore, see xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring a cluster state] for more information on the impact to the cluster.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[Recovering from expired control plane certificates]:: This solution handles situations where your control plane certificates have expired. For example, if you shut down your cluster before the first certificate rotation, which occurs 24 hours after installation, your certificates will not be rotated and will expire. You can follow this procedure to recover from expired control plane certificates.
+
+// Testing restore procedures
+include::modules/dr-testing-restore-procedures.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]
+
+// Restoring etcd quorum for high availability clusters
+include::modules/dr-restoring-etcd-quorum-ha.adoc[leveloffset=+2]
+
+[id="_additional-resources"]
path: etcd/etcd-backup.adoc
user: login: skopacz1
body: This should be a role instead:
```suggestion
[role="_additional-resources"]
```
created_at: 2025-05-13T16:37:12Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
+
+This process depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or whether it is unhealthy because the etcd pod is crashlooping.
+
+[NOTE]
+====
+If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to  xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state] instead of this procedure.
+
+If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates] instead of this procedure.
+
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+====
+
+// Identifying an unhealthy etcd member
+include::modules/restore-identify-unhealthy-etcd-member.adoc[leveloffset=+2]
+
+[.role=_additional-resources]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+
+// Determining the state of the unhealthy etcd member
+include::modules/restore-determine-state-etcd-member.adoc[leveloffset=+2]
+
+// Replacing an unhealthy etcd member whose machine is not running or whose node is not ready
+include::modules/restore-replace-stopped-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/control_plane_machine_management/cpmso-troubleshooting.adoc#cpmso-ts-etcd-degraded_cpmso-troubleshooting[Recovering a degraded etcd Operator]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2023/html/assisted_installer_for_openshift_container_platform/expanding-the-cluster#installing-primary-control-plane-node-unhealthy-cluster_expanding-the-cluster[Installing a primary control plane node on an unhealthy cluster]
+
+// Replacing an unhealthy etcd member whose etcd pod is crashlooping
+include::modules/restore-replace-crashlooping-etcd-member.adoc[leveloffset=+3]
+
+// Replacing an unhealthy baremetal stopped etcd member
+include::modules/restore-replace-stopped-baremetal-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-etcd_deleting-machine[Quorum protection with machine lifecycle hooks]
+
+[id="etcd-disaster-recovery"]
+== Disaster recovery
+
+The disaster recovery documentation provides information for administrators on how to recover from several disaster situations that might occur with their {product-title} cluster. As an administrator, you might need to follow one or more of the following procedures to return your cluster to a working state.
+
+[IMPORTANT]
+====
+Disaster recovery requires you to have at least one healthy control plane host.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-restoring-etcd-quorum-ha_etcd-backup[Restoring etcd quorum for high availability clusters]:: This solution handles situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. This solution does not require an etcd backup.
++
+[NOTE]
+====
+If you have a majority of your control plane nodes still available and have an etcd quorum, xref:../etcd/etcd-backup.adoc#replace-unhealthy-etcd-member[replace a single unhealthy etcd member].
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]:: This solution handles situations where you want to restore your cluster to a previous state, for example, if an administrator deletes something critical. If you have taken an etcd backup, you can restore your cluster to a previous state.
++
+If applicable, you might also need to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates].
++
+[WARNING]
+====
+Restoring to a previous cluster state is a destructive and destablizing action to take on a running cluster. This procedure should only be used as a last resort.
+
+Before performing a restore, see xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring a cluster state] for more information on the impact to the cluster.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[Recovering from expired control plane certificates]:: This solution handles situations where your control plane certificates have expired. For example, if you shut down your cluster before the first certificate rotation, which occurs 24 hours after installation, your certificates will not be rotated and will expire. You can follow this procedure to recover from expired control plane certificates.
+
+// Testing restore procedures
+include::modules/dr-testing-restore-procedures.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]
+
+// Restoring etcd quorum for high availability clusters
+include::modules/dr-restoring-etcd-quorum-ha.adoc[leveloffset=+2]
+
+[id="_additional-resources"]
+.Additional resources
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
path: etcd/etcd-backup.adoc
user: login: skopacz1
body: This doesn't work when adding `#installing-bare-metal`? That's weird if so, oh well.
created_at: 2025-05-13T16:38:50Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
+
+This process depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or whether it is unhealthy because the etcd pod is crashlooping.
+
+[NOTE]
+====
+If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to  xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state] instead of this procedure.
+
+If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates] instead of this procedure.
+
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+====
+
+// Identifying an unhealthy etcd member
+include::modules/restore-identify-unhealthy-etcd-member.adoc[leveloffset=+2]
+
+[.role=_additional-resources]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+
+// Determining the state of the unhealthy etcd member
+include::modules/restore-determine-state-etcd-member.adoc[leveloffset=+2]
+
+// Replacing an unhealthy etcd member whose machine is not running or whose node is not ready
+include::modules/restore-replace-stopped-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/control_plane_machine_management/cpmso-troubleshooting.adoc#cpmso-ts-etcd-degraded_cpmso-troubleshooting[Recovering a degraded etcd Operator]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2023/html/assisted_installer_for_openshift_container_platform/expanding-the-cluster#installing-primary-control-plane-node-unhealthy-cluster_expanding-the-cluster[Installing a primary control plane node on an unhealthy cluster]
+
+// Replacing an unhealthy etcd member whose etcd pod is crashlooping
+include::modules/restore-replace-crashlooping-etcd-member.adoc[leveloffset=+3]
+
+// Replacing an unhealthy baremetal stopped etcd member
+include::modules/restore-replace-stopped-baremetal-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-etcd_deleting-machine[Quorum protection with machine lifecycle hooks]
+
+[id="etcd-disaster-recovery"]
+== Disaster recovery
+
+The disaster recovery documentation provides information for administrators on how to recover from several disaster situations that might occur with their {product-title} cluster. As an administrator, you might need to follow one or more of the following procedures to return your cluster to a working state.
+
+[IMPORTANT]
+====
+Disaster recovery requires you to have at least one healthy control plane host.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-restoring-etcd-quorum-ha_etcd-backup[Restoring etcd quorum for high availability clusters]:: This solution handles situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. This solution does not require an etcd backup.
++
+[NOTE]
+====
+If you have a majority of your control plane nodes still available and have an etcd quorum, xref:../etcd/etcd-backup.adoc#replace-unhealthy-etcd-member[replace a single unhealthy etcd member].
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]:: This solution handles situations where you want to restore your cluster to a previous state, for example, if an administrator deletes something critical. If you have taken an etcd backup, you can restore your cluster to a previous state.
++
+If applicable, you might also need to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates].
++
+[WARNING]
+====
+Restoring to a previous cluster state is a destructive and destablizing action to take on a running cluster. This procedure should only be used as a last resort.
+
+Before performing a restore, see xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring a cluster state] for more information on the impact to the cluster.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[Recovering from expired control plane certificates]:: This solution handles situations where your control plane certificates have expired. For example, if you shut down your cluster before the first certificate rotation, which occurs 24 hours after installation, your certificates will not be rotated and will expire. You can follow this procedure to recover from expired control plane certificates.
+
+// Testing restore procedures
+include::modules/dr-testing-restore-procedures.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]
+
+// Restoring etcd quorum for high availability clusters
+include::modules/dr-restoring-etcd-quorum-ha.adoc[leveloffset=+2]
+
+[id="_additional-resources"]
+.Additional resources
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
+
+* xref:../installing/installing_bare_metal/ipi/ipi-install-expanding-the-cluster.adoc#replacing-a-bare-metal-control-plane-node_ipi-install-expanding[Replacing a bare-metal control plane node]
+
+// Restoring to a previous cluster state
path: etcd/etcd-backup.adoc
user: login: skopacz1
body: This section title has both:

1. The same wording as the title of the actual procedure module below
2. A gerund phrase, which per the [mod docs guidelines](https://redhat-documentation.github.io/modular-docs/#con-creating-procedure-modules_writing-mod-docs:~:text=Procedure%20title-,The%20title,-of%20a%20procedure) is typically reserved for the titles of procedures


Can one of these two section titles be slightly reworded so that at least they're not exactly identical? Ideally this section could be changed to something without a gerund phrase since this is the about section, but any differentiation would be an improvement IMO
created_at: 2025-05-13T16:43:30Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
+
+This process depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or whether it is unhealthy because the etcd pod is crashlooping.
+
+[NOTE]
+====
+If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to  xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state] instead of this procedure.
+
+If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates] instead of this procedure.
+
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+====
+
+// Identifying an unhealthy etcd member
+include::modules/restore-identify-unhealthy-etcd-member.adoc[leveloffset=+2]
+
+[.role=_additional-resources]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+
+// Determining the state of the unhealthy etcd member
+include::modules/restore-determine-state-etcd-member.adoc[leveloffset=+2]
+
+// Replacing an unhealthy etcd member whose machine is not running or whose node is not ready
+include::modules/restore-replace-stopped-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/control_plane_machine_management/cpmso-troubleshooting.adoc#cpmso-ts-etcd-degraded_cpmso-troubleshooting[Recovering a degraded etcd Operator]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2023/html/assisted_installer_for_openshift_container_platform/expanding-the-cluster#installing-primary-control-plane-node-unhealthy-cluster_expanding-the-cluster[Installing a primary control plane node on an unhealthy cluster]
+
+// Replacing an unhealthy etcd member whose etcd pod is crashlooping
+include::modules/restore-replace-crashlooping-etcd-member.adoc[leveloffset=+3]
+
+// Replacing an unhealthy baremetal stopped etcd member
+include::modules/restore-replace-stopped-baremetal-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-etcd_deleting-machine[Quorum protection with machine lifecycle hooks]
+
+[id="etcd-disaster-recovery"]
+== Disaster recovery
+
+The disaster recovery documentation provides information for administrators on how to recover from several disaster situations that might occur with their {product-title} cluster. As an administrator, you might need to follow one or more of the following procedures to return your cluster to a working state.
+
+[IMPORTANT]
+====
+Disaster recovery requires you to have at least one healthy control plane host.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-restoring-etcd-quorum-ha_etcd-backup[Restoring etcd quorum for high availability clusters]:: This solution handles situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. This solution does not require an etcd backup.
++
+[NOTE]
+====
+If you have a majority of your control plane nodes still available and have an etcd quorum, xref:../etcd/etcd-backup.adoc#replace-unhealthy-etcd-member[replace a single unhealthy etcd member].
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]:: This solution handles situations where you want to restore your cluster to a previous state, for example, if an administrator deletes something critical. If you have taken an etcd backup, you can restore your cluster to a previous state.
++
+If applicable, you might also need to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates].
++
+[WARNING]
+====
+Restoring to a previous cluster state is a destructive and destablizing action to take on a running cluster. This procedure should only be used as a last resort.
+
+Before performing a restore, see xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring a cluster state] for more information on the impact to the cluster.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[Recovering from expired control plane certificates]:: This solution handles situations where your control plane certificates have expired. For example, if you shut down your cluster before the first certificate rotation, which occurs 24 hours after installation, your certificates will not be rotated and will expire. You can follow this procedure to recover from expired control plane certificates.
+
+// Testing restore procedures
+include::modules/dr-testing-restore-procedures.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]
+
+// Restoring etcd quorum for high availability clusters
+include::modules/dr-restoring-etcd-quorum-ha.adoc[leveloffset=+2]
+
+[id="_additional-resources"]
+.Additional resources
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
+
+* xref:../installing/installing_bare_metal/ipi/ipi-install-expanding-the-cluster.adoc#replacing-a-bare-metal-control-plane-node_ipi-install-expanding[Replacing a bare-metal control plane node]
+
+// Restoring to a previous cluster state
+include::modules/dr-restoring-cluster-state-about.adoc[leveloffset=+2]
+
+// Restoring to a previous cluster state for a single node
+include::modules/dr-restoring-cluster-state-sno.adoc[leveloffset=+3]
+
+// Restoring to a previous cluster state
+include::modules/dr-restoring-cluster-state.adoc[leveloffset=+3]
+
+// Restoring a cluster from etcd backup manually
+include::modules/manually-restoring-cluster-etcd-backup.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
+* xref:../networking/accessing-hosts.adoc#accessing-hosts[Accessing hosts on Amazon Web Services in an installer-provisioned infrastructure cluster]
path: etcd/etcd-backup.adoc
user: login: skopacz1
body: Very slight nit, but the anchor ID here seems to link to the top of the assembly rather than the section mentioned in the link text. Not a big deal since that section is right below, but just thought I'd point that out
created_at: 2025-05-13T16:49:36Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,10 +1,13 @@
 // Module included in the following assemblies:
 //
 // * disaster_recovery/scenario-2-restoring-cluster-state.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: CONCEPT
 [id="dr-scenario-2-restoring-cluster-state-about_{context}"]
-= About restoring cluster state
+= Restoring to a previous cluster state
path: modules/dr-restoring-cluster-state-about.adoc
user: login: skopacz1
body: Somewhat mentioned this earlier for another section, but just an FYI that using a gerund phrase in the title of this concept module might make it seem like this section will have a procedure, at least by the logic of our mod docs guidelines
created_at: 2025-05-13T16:53:08Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
path: etcd/etcd-backup.adoc
user: login: lahinson
body: Good catch!
created_at: 2025-05-13T17:26:19Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
path: etcd/etcd-backup.adoc
user: login: lahinson
body: You make a valid point. I'm hesitant to add another admonition, though, because as you mentioned, this is already admonition-heavy content. Sometimes with the etcd content, I feel like I should just add a big banner to the top of the page stating, "Everything on this page is important" :) I think I will leave it as-is for now.
created_at: 2025-05-13T17:57:38Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
path: etcd/etcd-backup.adoc
user: login: lahinson
body: Good question. Yes, those are meant to be nested under the automated backup feature. I might tweak the titles of the two nested modules to make that clear.
created_at: 2025-05-13T18:06:49Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
path: etcd/etcd-backup.adoc
user: login: lahinson
body: Good catch
created_at: 2025-05-13T18:09:55Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
path: etcd/etcd-backup.adoc
user: login: lahinson
body: Good point. I revised the wording to avoid the self-referential text.
created_at: 2025-05-13T18:13:55Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
+
+This process depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or whether it is unhealthy because the etcd pod is crashlooping.
+
+[NOTE]
+====
+If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to  xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state] instead of this procedure.
+
+If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates] instead of this procedure.
+
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+====
+
+// Identifying an unhealthy etcd member
+include::modules/restore-identify-unhealthy-etcd-member.adoc[leveloffset=+2]
+
+[.role=_additional-resources]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+
+// Determining the state of the unhealthy etcd member
+include::modules/restore-determine-state-etcd-member.adoc[leveloffset=+2]
+
+// Replacing an unhealthy etcd member whose machine is not running or whose node is not ready
+include::modules/restore-replace-stopped-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/control_plane_machine_management/cpmso-troubleshooting.adoc#cpmso-ts-etcd-degraded_cpmso-troubleshooting[Recovering a degraded etcd Operator]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2023/html/assisted_installer_for_openshift_container_platform/expanding-the-cluster#installing-primary-control-plane-node-unhealthy-cluster_expanding-the-cluster[Installing a primary control plane node on an unhealthy cluster]
+
+// Replacing an unhealthy etcd member whose etcd pod is crashlooping
+include::modules/restore-replace-crashlooping-etcd-member.adoc[leveloffset=+3]
+
+// Replacing an unhealthy baremetal stopped etcd member
+include::modules/restore-replace-stopped-baremetal-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-etcd_deleting-machine[Quorum protection with machine lifecycle hooks]
+
+[id="etcd-disaster-recovery"]
+== Disaster recovery
+
+The disaster recovery documentation provides information for administrators on how to recover from several disaster situations that might occur with their {product-title} cluster. As an administrator, you might need to follow one or more of the following procedures to return your cluster to a working state.
+
+[IMPORTANT]
+====
+Disaster recovery requires you to have at least one healthy control plane host.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-restoring-etcd-quorum-ha_etcd-backup[Restoring etcd quorum for high availability clusters]:: This solution handles situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. This solution does not require an etcd backup.
++
+[NOTE]
+====
+If you have a majority of your control plane nodes still available and have an etcd quorum, xref:../etcd/etcd-backup.adoc#replace-unhealthy-etcd-member[replace a single unhealthy etcd member].
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]:: This solution handles situations where you want to restore your cluster to a previous state, for example, if an administrator deletes something critical. If you have taken an etcd backup, you can restore your cluster to a previous state.
++
+If applicable, you might also need to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates].
++
+[WARNING]
+====
+Restoring to a previous cluster state is a destructive and destablizing action to take on a running cluster. This procedure should only be used as a last resort.
+
+Before performing a restore, see xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring a cluster state] for more information on the impact to the cluster.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[Recovering from expired control plane certificates]:: This solution handles situations where your control plane certificates have expired. For example, if you shut down your cluster before the first certificate rotation, which occurs 24 hours after installation, your certificates will not be rotated and will expire. You can follow this procedure to recover from expired control plane certificates.
+
+// Testing restore procedures
+include::modules/dr-testing-restore-procedures.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]
+
+// Restoring etcd quorum for high availability clusters
+include::modules/dr-restoring-etcd-quorum-ha.adoc[leveloffset=+2]
+
+[id="_additional-resources"]
+.Additional resources
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
+
+* xref:../installing/installing_bare_metal/ipi/ipi-install-expanding-the-cluster.adoc#replacing-a-bare-metal-control-plane-node_ipi-install-expanding[Replacing a bare-metal control plane node]
+
+// Restoring to a previous cluster state
path: etcd/etcd-backup.adoc
user: login: lahinson
body: Another good point. I changed the second title to "Restoring to a previous cluster state for more than one node".
created_at: 2025-05-13T18:35:37Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,7 +1,149 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="etcd-backup"]
 include::_attributes/common-attributes.adoc[]
-= Backing up etcd
+= Backing up and restoring etcd data
 :context: etcd-backup
 
-// This assembly will contain modules to provide information about backing up and restoring etcd.
\ No newline at end of file
+As the key-value store for {product-title}, etcd persists the state of all resource objects.
+
+Back up the etcd data for your cluster regularly and store it in a secure location, ideally outside the {product-title} environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.
+
+Be sure to take an etcd backup before you update your cluster. Taking a backup before you update is important because when you restore your cluster, you must use an etcd backup that was taken from the same z-stream release. For example, an {product-title} 4.17.5 cluster must use an etcd backup that was taken from 4.17.5.
+
+[IMPORTANT]
+====
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
+====
+
+After you have an etcd backup, you can xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state].
+
+// Backing up etcd data
+include::modules/backup-etcd.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.adoc[Recovering an unhealthy etcd cluster for {hcp}]
+
+// Creating automated etcd backups
+include::modules/etcd-creating-automated-backups.adoc[leveloffset=+1]
+
+// Creating a single etcd backup
+include::modules/creating-single-etcd-backup.adoc[leveloffset=+2]
+
+// Creating recurring etcd backups
+include::modules/creating-recurring-etcd-backups.adoc[leveloffset=+2]
+
+[id="replace-unhealthy-etcd-member"]
+== Replacing an unhealthy etcd member
+
+This document describes the process to replace a single unhealthy etcd member.
+
+This process depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or whether it is unhealthy because the etcd pod is crashlooping.
+
+[NOTE]
+====
+If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to  xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[restore to a previous cluster state] instead of this procedure.
+
+If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates] instead of this procedure.
+
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+====
+
+// Identifying an unhealthy etcd member
+include::modules/restore-identify-unhealthy-etcd-member.adoc[leveloffset=+2]
+
+[.role=_additional-resources]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+
+// Determining the state of the unhealthy etcd member
+include::modules/restore-determine-state-etcd-member.adoc[leveloffset=+2]
+
+// Replacing an unhealthy etcd member whose machine is not running or whose node is not ready
+include::modules/restore-replace-stopped-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/control_plane_machine_management/cpmso-troubleshooting.adoc#cpmso-ts-etcd-degraded_cpmso-troubleshooting[Recovering a degraded etcd Operator]
+* link:https://docs.redhat.com/en/documentation/assisted_installer_for_openshift_container_platform/2023/html/assisted_installer_for_openshift_container_platform/expanding-the-cluster#installing-primary-control-plane-node-unhealthy-cluster_expanding-the-cluster[Installing a primary control plane node on an unhealthy cluster]
+
+// Replacing an unhealthy etcd member whose etcd pod is crashlooping
+include::modules/restore-replace-crashlooping-etcd-member.adoc[leveloffset=+3]
+
+// Replacing an unhealthy baremetal stopped etcd member
+include::modules/restore-replace-stopped-baremetal-etcd-member.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../machine_management/deleting-machine.adoc#machine-lifecycle-hook-deletion-etcd_deleting-machine[Quorum protection with machine lifecycle hooks]
+
+[id="etcd-disaster-recovery"]
+== Disaster recovery
+
+The disaster recovery documentation provides information for administrators on how to recover from several disaster situations that might occur with their {product-title} cluster. As an administrator, you might need to follow one or more of the following procedures to return your cluster to a working state.
+
+[IMPORTANT]
+====
+Disaster recovery requires you to have at least one healthy control plane host.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-restoring-etcd-quorum-ha_etcd-backup[Restoring etcd quorum for high availability clusters]:: This solution handles situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. This solution does not require an etcd backup.
++
+[NOTE]
+====
+If you have a majority of your control plane nodes still available and have an etcd quorum, xref:../etcd/etcd-backup.adoc#replace-unhealthy-etcd-member[replace a single unhealthy etcd member].
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]:: This solution handles situations where you want to restore your cluster to a previous state, for example, if an administrator deletes something critical. If you have taken an etcd backup, you can restore your cluster to a previous state.
++
+If applicable, you might also need to xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[recover from expired control plane certificates].
++
+[WARNING]
+====
+Restoring to a previous cluster state is a destructive and destablizing action to take on a running cluster. This procedure should only be used as a last resort.
+
+Before performing a restore, see xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring a cluster state] for more information on the impact to the cluster.
+====
+
+xref:../etcd/etcd-backup.adoc#dr-scenario-3-recovering-expired-certs_etcd-backup[Recovering from expired control plane certificates]:: This solution handles situations where your control plane certificates have expired. For example, if you shut down your cluster before the first certificate rotation, which occurs 24 hours after installation, your certificates will not be rotated and will expire. You can follow this procedure to recover from expired control plane certificates.
+
+// Testing restore procedures
+include::modules/dr-testing-restore-procedures.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#dr-scenario-2-restoring-cluster-state-about_etcd-backup[Restoring to a previous cluster state]
+
+// Restoring etcd quorum for high availability clusters
+include::modules/dr-restoring-etcd-quorum-ha.adoc[leveloffset=+2]
+
+[id="_additional-resources"]
+.Additional resources
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
+
+* xref:../installing/installing_bare_metal/ipi/ipi-install-expanding-the-cluster.adoc#replacing-a-bare-metal-control-plane-node_ipi-install-expanding[Replacing a bare-metal control plane node]
+
+// Restoring to a previous cluster state
+include::modules/dr-restoring-cluster-state-about.adoc[leveloffset=+2]
+
+// Restoring to a previous cluster state for a single node
+include::modules/dr-restoring-cluster-state-sno.adoc[leveloffset=+3]
+
+// Restoring to a previous cluster state
+include::modules/dr-restoring-cluster-state.adoc[leveloffset=+3]
+
+// Restoring a cluster from etcd backup manually
+include::modules/manually-restoring-cluster-etcd-backup.adoc[leveloffset=+3]
+
+[role="_additional-resources"]
+.Additional resources
+* xref:../etcd/etcd-backup.adoc#backing-up-etcd-data_etcd-backup[Backing up etcd data]
+* xref:../installing/installing_bare_metal/upi/installing-bare-metal.adoc[Installing a user-provisioned cluster on bare metal]
+* xref:../networking/accessing-hosts.adoc#accessing-hosts[Accessing hosts on Amazon Web Services in an installer-provisioned infrastructure cluster]
path: etcd/etcd-backup.adoc
user: login: lahinson
body: Noted. I'll look into it.
created_at: 2025-05-13T18:44:35Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,10 +1,13 @@
 // Module included in the following assemblies:
 //
 // * disaster_recovery/scenario-2-restoring-cluster-state.adoc
+// * etcd/etcd-backup.adoc
 
 :_mod-docs-content-type: CONCEPT
 [id="dr-scenario-2-restoring-cluster-state-about_{context}"]
-= About restoring cluster state
+= Restoring to a previous cluster state
path: modules/dr-restoring-cluster-state-about.adoc
user: login: lahinson
body: Leaving as-is for the purposes of this PR to migrate the content, but I'll take a note to address in a future PR.
created_at: 2025-05-13T18:54:33Z
author_association: CONTRIBUTOR

PR comments:
user: login: ocpdocs-previewbot
created_at: 2025-05-06T16:52:48Z
body: 🤖 Tue May 13 19:12:36 - Prow CI generated the docs preview:

https://93059--ocpdocs-pr.netlify.app/openshift-enterprise/latest/backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.html
https://93059--ocpdocs-pr.netlify.app/openshift-enterprise/latest/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/about-disaster-recovery.html
https://93059--ocpdocs-pr.netlify.app/openshift-enterprise/latest/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/quorum-restoration.html
https://93059--ocpdocs-pr.netlify.app/openshift-enterprise/latest/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.html
https://93059--ocpdocs-pr.netlify.app/openshift-enterprise/latest/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-3-expired-certs.html
https://93059--ocpdocs-pr.netlify.app/openshift-enterprise/latest/backup_and_restore/control_plane_backup_and_restore/replacing-unhealthy-etcd-member.html
https://93059--ocpdocs-pr.netlify.app/openshift-enterprise/latest/edge_computing/day_2_core_cnf_clusters/updating/telco-update-before-the-update.html
https://93059--ocpdocs-pr.netlify.app/openshift-enterprise/latest/etcd/etcd-backup.html
https://93059--ocpdocs-pr.netlify.app/openshift-enterprise/latest/hosted_control_planes/hcp_high_availability/hcp-recovering-etcd-cluster.html
https://93059--ocpdocs-pr.netlify.app/openshift-enterprise/latest/post_installation_configuration/cluster-tasks.html
author_association: NONE
user: login: lahinson
created_at: 2025-05-06T20:32:43Z
body: /retest
author_association: CONTRIBUTOR
user: login: lahinson
created_at: 2025-05-07T13:03:58Z
body: /retest
author_association: CONTRIBUTOR
user: login: geliu2016
created_at: 2025-05-09T05:08:06Z
body: /lgtm
author_association: NONE
user: login: openshift-ci[bot]
created_at: 2025-05-13T18:01:00Z
body: New changes are detected. LGTM label has been removed.
author_association: NONE
user: login: openshift-ci[bot]
created_at: 2025-05-13T19:14:21Z
body: @lahinson: all tests **passed!**


[Full PR test history](https://prow.ci.openshift.org/pr-history?org=openshift&repo=openshift-docs&pr=93059). [Your PR dashboard](https://prow.ci.openshift.org/pr?query=is:pr+state:open+author:lahinson).

<details>

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository. I understand the commands that are listed [here](https://go.k8s.io/bot-commands).
</details>
<!-- test report -->
author_association: NONE
user: login: lahinson
created_at: 2025-05-13T19:32:42Z
body: /cherrypick enterprise-4.19
author_association: CONTRIBUTOR
user: login: openshift-cherrypick-robot
created_at: 2025-05-13T19:33:31Z
body: @lahinson: new pull request created: #93326

<details>

In response to [this](https://github.com/openshift/openshift-docs/pull/93059#issuecomment-2877716777):

>/cherrypick enterprise-4.19


Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
</details>
author_association: NONE