HyperBDR · DianZheng321 · Jul 2, 2026
diff --git a/src/userguide/technical-practices/general-failback-drill.md b/src/userguide/technical-practices/general-failback-drill.md
@@ -1,202 +1,28 @@
 # General Failback Drill
 
-## The loopback platform supports ISO boot 
+The general failback drill is designed for scenarios where the failback target platform lacks standard automated failback capabilities. By copying disk data from the failback transition host and performing driver repair using the HyperDoor boot image, you can create an independent drill host for startup and service verification without impacting ongoing failback data synchronization or business continuity.
 
-### Supports cloning hosts
+## Applicable Scenarios
 
-- On the disaster recovery platform, after waiting for the failback data synchronization to complete, log in to the target platform for failback\.
+- The failback target platform does not support platform-level automatic failback, or has not yet been adapted for the target cloud or virtualization platform.
+- Before the formal failback, you need to verify whether the operating system can boot normally, disks are recognized, and the network and services are available after failback.
+- The target platform supports capabilities such as VM cloning, disk snapshots, volume replication, or disk attachment, allowing an independent drill environment to be created from the failback transition host's data.
+- There are differences in virtualization drivers, disk controllers, or boot modes between the source and failback target, requiring driver repair via the Livecd-HyperDoor image.
+- You need to avoid directly operating the failback transition host that is synchronizing data or running formal failback tasks, minimizing the drill's impact on the formal failback process.
 
-- Find the "rollback transition host" that receives data, and use the platform's host cloning capability to clone a new host\. 
+## Core Principles
 
-- Use the Livecd\-HyperDoor\.iso mirroring image to boot up this cloned host using the platform's Livecd\. 
-
-- Log in to this cloned host, execute the minitgt\-fix command, and perform driver repair\. 
-
-- Wait for the driver repair to complete, shut down the host, remove the optical drive, and then boot from the hard disk\.
-
-- Configure the IP Address for this test host\. 
-
-- Just adjust the business configuration and perform verification\.
-
-
-
-### Cloning hosts is not supported
-
-- On the disaster recovery platform, after waiting for the failback data synchronization to complete, log in to the target platform for failback\.
-
-- Locate the "rollback transition host" that receives data, and make a copy of all disks corresponding to this host for backup 
-
-- Use the copied system disk, leverage the volume boot capability, start up a host, and mount the remaining data disks to this host
-
-- Use the Livecd\-HyperDoor\.iso mirroring image to boot up this cloned host using the platform's Livecd\. 
-
-- Log in to this cloned host, execute the minitgt\-fix command, and perform driver repair\. 
-
-- Wait for the driver repair to complete, shut down the host, remove the optical drive, and then boot from the hard disk\.
-
-- Configure the IP Address for this test host\. 
-
-- Just adjust the business configuration and perform verification\.
-
-
-
-## The backcut platform does not support ISO boot 
-
-- On the disaster recovery platform, after waiting for the failback data synchronization to complete, log in to the target platform for failback\.
-
-- Locate the "rollback transition host" that receives data, and make a copy of all disks corresponding to this host for backup 
-
-- Use the Livecd\-HyperDoor\.iso or Livecd\-HyperDoor\.qcow2 mirroring to create a brand new transitional host, and the system disk of this host must be equal in size to or larger than that of the host to be reverted 
-
-- Then mount all the system disks and data disks that were previously copied out for backup onto this new transitional host\. 
-
-- Use the dd command to copy the newly mounted system disk in its entirety to the system disk of the transition host itself\. After the copy is completed, unmount the mounted system disk\. 
-
-- In this transition host, use lsblk to check the system disk of this host \(assuming it is vda\), and execute the minitgt\-fix /dev/vda command to perform driver repair\. 
-
-- Wait for the driver repair to complete, then restart the transition host\. 
-
-- After the host has finished starting up, configure the IP Address for this host\. 
-
-- Just adjust the business configuration and perform verification\.
-
-
-
----
-
-## Organize and optimize
-
-Based on the above document, I think it can be used as a multi\-step guiding process to allow users to perform operations:
-
-#### Step 1: Upload mirroring 
-
-```Plain Text
-The disaster recovery drill requires a boot image. Upload the image to the target platform first.
-
-> Platforms that support ISO boot, such as VMware
-
-Recommended for VMware vSphere environments. It provides complete virtual machine image support.
-Download link: https://192.168.8.22:30080/softwares/hyperdoor/Livecd-HyperDoor.iso
-
-> Cloud platforms that support QCOW2, such as OpenStack
-
-Recommended for mainstream cloud platforms. It provides strong compatibility with cloud environments.
-Download link: https://192.168.8.22:30080/softwares/hyperdoor/Livecd-HyperDoor.qcow2
-
-> Upload the image to the target platform
-
-Upload the downloaded image to your target cloud platform or VMware environment. The upload process may vary by platform. Refer to the documentation of your platform for details.
-
-Upload notes:
-- For cloud platforms: upload the QCOW2 image through the console.
-- For VMware: upload the ISO image through vCenter.
-- Make sure the image is uploaded to the correct region or data center.
-- After the upload is complete, verify the image integrity.
-
-```
-
-#### Step 2: Copy Disk 
-
-First, this page should prompt the following content:
-
-```Plain Text
-Do not copy disks while data synchronization is in progress. This may cause data inconsistency. Before copying disks, confirm that:
-1. Data synchronization has completed.
-2. The protection policy for the host can be disabled.
-After both items are confirmed, copy the disks.
-```
-
-Then it is to guide users to copy the disk, mainly including:
-
-```Plain Text
-> Platforms that support host cloning, such as VMware
-
-Find the transition host that receives the synchronized data. Use the platform's host cloning feature to create a new host for the drill.
-
-> Platforms that support snapshots, such as OpenStack
-
-Find the transition host that receives the synchronized data. Use host snapshots or volume snapshots to create snapshots for all disks of the transition host.
-Then create volumes from the snapshots for later use.
-
-> Platforms that do not support the quick disk copy methods above, such as physical servers
-
-Create the same number of disks with the same sizes as the disks on the transition host, and attach them to the transition host.
-Log in to the transition host through SSH. Use the dd command to copy each disk to the newly attached drill disk.
-After the copy is complete, detach the disks for later use.
-
-```
-
-#### Step 3: Boot the host
-
-```Plain Text
-> Platforms that support host cloning and ISO boot, such as VMware
-
-Attach the ISO image uploaded in Step 1 to the host cloned in Step 2.
-Start the host and make sure it boots successfully from the ISO.
-For easier management, configure the IP address through DHCP or manually.
-
-> Cloud platforms that support QCOW2 images, such as OpenStack
-
-Use the QCOW2 image uploaded in Step 1 to create a new drill host on the platform. The system disk must be the same size as or larger than the system disk of the transition host.
-Attach the disks prepared in Step 2 to the new drill host, using the same disk order as the transition host that receives synchronized data.
-Start the host and make sure it boots successfully.
-For easier management, configure the IP address through DHCP or manually.
-
-```
-
-#### Step 4: Driver Repair
-
-```Plain Text
-Log in to the drill host started in Step 3 through the console or SSH.
-Run minitgt-fix to repair the drivers.
-If you need to convert UEFI to BIOS, refer to the document: xxx.
-If you need WinPE repair, refer to the document: xxx.
-
-```
-
-#### Step 5: Verify the host
-
-```Plain Text
-> Drill hosts cloned and started through ISO boot, such as VMware
-
-Unmount the ISO image from the CD/DVD drive.
-Run reboot to restart the system.
-Verify the system after startup.
-
-> Drill hosts created from a QCOW2 image, such as OpenStack
-
-Use dd to overwrite the system disk created from the QCOW2 image with the repaired system disk.
-Run reboot to restart the system.
-Verify the system after startup.
-
-```
-
-## Final Solution
-
-Use only one page to guide users to download the mirroring, and then direct them to the document platform for processing\.
-
-```Plain Text
-The disaster recovery drill requires a boot image. Upload the image to the target platform first.
-
-> Platforms that support ISO boot, such as VMware
-
-Recommended for VMware vSphere environments. It provides complete virtual machine image support.
-Download link: https://192.168.8.22:30080/softwares/hyperdoor/Livecd-HyperDoor.iso
-
-> Cloud platforms that support QCOW2, such as OpenStack and Alibaba Cloud
-
-Recommended for mainstream cloud platforms. It provides strong compatibility with cloud environments.
-Download link: https://192.168.8.22:30080/softwares/hyperdoor/Livecd-HyperDoor.qcow2
-
-> Upload the image to the target platform
-
-Upload the downloaded image to your target cloud platform or VMware environment. The upload process may vary by platform. Refer to the documentation of your platform for details.
-
-
-```
+- The drill must be based on a disk copy of the failback transition host. Do not directly modify the failback transition host that is synchronizing data.
+- Before copying the disk, confirm that failback data synchronization is complete and that the host is allowed to be shut down or enter drill mode.
+- The number of disks on the drill host must match the failback host. Disk capacity can be larger than the original, but not smaller.
+- The boot mode of the source and drill target must match. For example, if the source uses BIOS boot, the target must also use BIOS; if the source uses UEFI, the target must also use UEFI.
+- After driver repair is complete, remove the Livecd-HyperDoor boot image and boot the host from the repaired system disk.
+- It is recommended to use independent IP addresses, network policies, and service configurations for the drill environment to avoid conflicts with the production environment.
 
 ## Reference Guide
 
+If your failback target platform belongs to one of the following types, refer to the corresponding guide to complete the general failback drill. Different platforms may differ in image upload, disk copy, host creation, disk attachment, and boot mode configuration. Please follow the platform-specific guide.
+
 | Cloud Provider                           | Configuration Guide |
 | ------------------------------- | ---- |
 | VMware                            | [View guide](./vmware-failback-drill-reference-guide.md)     |

diff --git a/src/userguide/technical-practices/openstack-failback-drill-reference-guide.md b/src/userguide/technical-practices/openstack-failback-drill-reference-guide.md
@@ -74,10 +74,6 @@ Enter Project, Volumes, Volumes, find the volume created by the snapshot, and mo
 
 Log in to the HyperUbuntuDrill host that has just completed booting via the Console or SSH, and execute minitgt\-fix to complete driver repair; 
 
-If UEFI to BIOS conversion is required, please refer to the document: xxx\. 
-
-If WinPE repair is needed, please refer to the document: xxx\. 
-
 ![Image](./images/openstack-failback-drill-reference-guide-13.png)
 
 ![Image](./images/openstack-failback-drill-reference-guide-14.png)

diff --git a/src/userguide/technical-practices/vmware-failback-drill-reference-guide.md b/src/userguide/technical-practices/vmware-failback-drill-reference-guide.md
@@ -30,6 +30,8 @@ At this time, Livecd\-HyperDoor\.iso has been successfully uploaded to the Cloud
 
 Find the transition host that has completed synchronization, and use the host cloning capability of the platform to clone a new host for standby\.
 
+> After the cloning process is complete, please verify that the boot mode of the target host is consistent with that of the source host. Under normal circumstances, the cloned host should use the same boot mode as the source host.
+
 Find HyperUbuntu, click ACTIONS, move to Clone, and click Clone to Virtual Machine\.\.\.
 
 ![Image](./images/vmware-failback-drill-reference-guide-5.png)
@@ -65,10 +67,6 @@ setting-ip 192.168.8.35 255.255.240.0 192.168.0.1 114.114.114.114
 
 Log in to the HyperUbuntuDrill host that has just completed booting via the Console or SSH, and execute minitgt\-fix to complete driver repair; 
 
-If UEFI to BIOS conversion is required, please refer to the document: xxx\. 
-
-If WinPE repair is required, please refer to the document: xxx\.
-
 ![Image](./images/vmware-failback-drill-reference-guide-9.png)
 
 ![Image](./images/vmware-failback-drill-reference-guide-10.png)