diff --git a/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md b/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md
index c4d2ae77476..2c049e8dfe4 100644
--- a/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md
+++ b/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md
@@ -79,23 +79,38 @@ If you are using [local snapshots](./back-up-rancher-launched-kubernetes-cluster
     1. In the **Clusters** page, go to the cluster where you want to remove nodes.
     1. In the **Machines** tab, click **⋮ > Delete** on each node you want to delete. Initially, you will see the nodes hang in a `deleting` state, but once all etcd nodes are deleting, they will be removed together. This is due to the fact that Rancher sees all etcd nodes deleting and proceeds to "short circuit" the etcd safe-removal logic.
 
-1. After all etcd nodes are removed, add a new etcd node that you are planning to restore from.
+1. After all etcd nodes are removed, add a new etcd node that you are planning to restore from. The new node must be assigned the role of `all` (etcd, controlplane, and worker).
 
-    - For custom clusters, go to the **Registration** tab then copy and run the registration command on your node. If the node has previously been used in a cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md#cleaning-up-nodes) first.
+    - If the node has previously been used in a cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md#cleaning-up-nodes) first.
+    - For custom clusters, go to the **Registration** tab and check the box for `etcd, controlplane, and worker`. Then copy and run the registration command on your node.
     - For node driver clusters, a new node is provisioned automatically.
 
     At this point, Rancher will indicate that restoration from etcd snapshot is required.
 
 1. Restore from an etcd snapshot.
 
+    :::note
+    As the etcd node is a clean node, the path (`/var/lib/rancher/<k3s/rke2>/server/db/snapshots/`) may need to be manually created.
+    :::
+
     - For S3 snapshots, restore using the UI.
       1. Click the **Snapshots** tab to view the list of saved snapshots.
       1. Go to the snapshot you want to restore and click **⋮ > Restore**.
       1. Select a **Restore Type**.
       1. Click **Restore**.
     - For local snapshots, restore using the UI is **not** available.
-      1. In the upper right corner, click **⋮ > Edit YAML**.
-      1. Define `spec.cluster.rkeConfig.etcdSnapshotRestore.name` as the filename of the snapshot on disk in `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/`.
+      1. In the upper right corner, click **⋮ > Edit YAML** to configure the setting `spec.cluster.rkeConfig.etcdSnapshotRestore.name` as the filename of the snapshot on disk in `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/`.
+      1. Example YAML that can be added under your `rkeConfig` configuration:
+
+      ```yaml
+        ...
+        rkeConfig:
+            etcdSnapshotRestore:
+                name: <string> #Refers to the filename of the associated etcdsnapshot object.
+                generation: <int> #Changing the generation initiates a snapshot restore.
+                restoreRKEConfig: <string> #Set to either none (or empty string), all, or kubernetesVersion.
+        ...
+      ```
 
 1. After restoration is successful, you can scale your etcd nodes back up to the desired redundancy.