Method for mutual backup of single-chip raid solid state disk operating system partition and solid state disk

By dividing a single SSD into explicit and implicit partitions and utilizing firmware-triggered backup mechanisms, the problem of complex and easily crashed single SSD operating system partition backup is solved. This achieves efficient mutual backup of operating system partitions, ensuring that the device can quickly switch to the backup partition in the event of a system crash, thereby improving the reliability and application feasibility of the device.

CN122111756APending Publication Date: 2026-05-29深圳云存科技有限公司
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
深圳云存科技有限公司
Filing Date
2024-11-23
Publication Date
2026-05-29

AI Technical Summary

Technical Problem

In the existing technology, the method of partitioning and backing up the operating system of a single solid-state drive (SSD) is complex and costly, which makes the device prone to failure. In particular, there is a lack of effective operating system backup measures in industrial equipment, and conventional RAID expansion solutions require changes to the device structure.

Method used

A hidden mutual backup solution for operating system partitions is implemented using a single SSD. By dividing the SSD into two partitions of the same capacity before it leaves the factory, the explicit primary partition is used for operating system installation, and the secondary partition is used for hidden backup. The firmware counts the number of power-on cycles to trigger data backup and switching, simplifying the operation process and avoiding changes to the device structure.

Benefits of technology

Without increasing equipment costs or changing the structure, efficient implicit mutual backup of the operating system partitions is achieved, improving the reliability and application feasibility of the equipment, and ensuring that the operating system can quickly switch to the backup partition to continue running when the equipment crashes.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122111756A_ABST
    Figure CN122111756A_ABST
Patent Text Reader

Abstract

This invention provides a method for mutual backup of operating system partitions on a single RAID solid-state drive (SSD) and the SSD itself, relating to the field of storage backup technology. This invention enables SSD manufacturers to implement SSD backup of the operating system disk through specific functions developed in the firmware. Before leaving the factory, the SSD is configured with two partitions of equal size: a visible primary partition for operating system installation and a secondary partition as a hidden operating system backup partition. The user installs the operating system on the primary partition, along with necessary drivers and applications. A command is triggered by continuously powering on and off n times. When the SSD detects that it has been powered on n times consecutively within a predetermined time period, the SSD firmware is triggered to completely back up the visible partition to the hidden secondary partition. When the device enters idle mode, newly added data on the visible system disk partition is automatically backed up to the hidden secondary partition. When the operating system on the primary visible partition is corrupted and cannot function properly, the system is powered on and off m times consecutively. If the SSD detects that it has been powered on and off m times within a specified time period, the SSD's firmware is triggered to switch the device to the operating system on the backup hidden secondary partition. The secondary partition becomes the primary visible operating system partition, and the primary partition becomes the hidden backup secondary partition. After confirming that the new primary visible partition successfully boots the system, the system is powered off. An unbackup operating system operation is then performed, achieving mutual backup of the operating systems.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of solid-state drive operating system partition backup technology, and more specifically, to a RAID solid-state drive that implements operating system partition mutual backup triggering and switching triggering functions on a single solid-state drive. Background Technology

[0002] Most SSDs on the market rely on a single protocol for data read / write operations, such as the common USB / IDE / SATA / NVMe protocols. RAID arrays are typically implemented using two independent SSDs, which is costly and requires additional space in the device architecture. Furthermore, there is still no effective method for cross-partition backup of the operating system on a single RAID SSD, or the process is overly complex and cumbersome. The operating system drive in many devices is prone to data corruption due to accidental operation or virus attacks, and the probability of system drive failure is high, leading to device crashes and catastrophic accidents in production applications. Apart from servers, very few industrial devices can simultaneously support multiple SSD interfaces, and using conventional RAID expansion solutions requires changes to the original structural design, resulting in most industrial equipment lacking operating system backup measures. Summary of the Invention

[0003] This invention aims to improve the secure and reliable operation of the operating system disk partition in most industrial equipment that only supports a single SSD interface. Without significantly increasing equipment costs or modifying the original equipment structure, it employs a hidden mutual backup scheme for the operating system disk partition using a single SSD. The explicit operating system disk partition is backed up by the SSD firmware to the hidden operating system disk partition. The operation method is simple and easy to use, thereby improving equipment reliability and application feasibility. Because it uses a RAID solid-state drive to achieve mutual backup of the operating system partition on a single disk, it meets the RAID solid-state drive needs of most industrial equipment that only supports single-disk SSDs.

[0004] The specific technical solution for implementing this invention is as follows: Step 1, a method for mutual backup of operating system partitions on a single RAID solid-state drive and a solid-state drive, wherein the mutual backup of the system partitions on the single SSD is performed by opening the SSD with two partitions of the same capacity before it leaves the factory, the explicit primary partition is the operating system installation partition, and the secondary partition is the hidden operating system backup partition, and the explicit capacity of the SSD is half of its actual capacity; refer to step S100.

[0005] Step 2, S110, describes a single RAID solid-state drive operating system partition for mutual backup. The SSD's explicit operating system installation partition can be customized by the user, or the operating system, necessary drivers, and application software can be installed directly on the primary partition.

[0006] Step 3, S110, refers to the operating system, which may be Windows, Linux, Android, iOS, Unix; domestically produced series of commonly used operating systems such as Kylin, Tongxin, Hongmeng, Euler, etc., as well as other operating systems; the installation of necessary drivers or application software on the system disk refers to the underlying hardware driver software and necessary application software for device operation.

[0007] Step 4, S120: The firmware of the single-chip RAID solid-state drive operating system partition mutual backup SSD has an SSD power-on count function, defining a continuous power-on counter. Different command functions are triggered by different counts. The specified time period (20 seconds in this solution) is because the power-on duration can only be calculated after the SSD is powered on. Power-on exceeding the specified duration (20 seconds) is considered normal power-on. Under normal power-on conditions, the firmware will reset the continuous power-on counter to zero. The continuous power-on / off n times refers to powering on and off the SSD n times through the device's power-on / off method. Because the SSD is not an independent device, its power supply is an internal power supply controlled by the device's motherboard. Powering on and off the SSD can only be achieved through the device's power-on / off method.

[0008] Step 5, S120: The SSD detects that it has been powered on n times consecutively within a certain agreed time period (20 seconds). In this scheme, n=5. The number of power-on times that is less than the specified time period (20 seconds) is counted in the consecutive power-on counter. When the SSD is powered on 5 times consecutively, the firmware of the SSD is triggered to completely back up the explicit partition to the implicit secondary partition.

[0009] Step 6: Power on normally. When the triggering requirement of the firmware to fully back up the visible partition to the hidden secondary partition as described in step S130 is met, it means that the firmware's instruction to fully back up the visible system partition to the hidden secondary partition is effective after 5 consecutive power-on operations in step 5. The device will remain in the BIOS interface. The waiting time will vary depending on the backup capacity, but will be at least half an hour. See step S140. If the triggering requirement is not met and other instruction functions are not triggered, the device will directly enter the system interface. See step S131.

[0010] Step 7, S150, refers to the waiting time after which the backup of the explicit primary partition to the implicit secondary partition has been completed. Since this backup process is controlled within the SSD firmware, even if the SSD has completed the backup, it cannot control the device to restart. During and after the backup process, the device remains in the BIOS interface, and the user can only wait blindly until the estimated backup time exceeds the required time before shutting down and restarting.

[0011] Step 8, S160, refers to the SSD firmware sensing that the USB bus / SATA protocol bus / NVME protocol bus has not transmitted data for a long time. The SSD firmware will then perform data backup of the explicit operating system disk partition to the implicit operating system secondary partition disk.

[0012] The system crash issue mentioned in steps 9 and S170 refers to the situation where the operating system files are corrupted due to various reasons during device operation, resulting in the device being unable to operate; a system switch operation needs to be performed to enable the operating system backed up on the secondary disk.

[0013] Step 10 and step S180 refer to the continuous power-on and power-off times m times. In this scheme, m=2 times, which means the power-off and power-on of the SSD is counted in the same way as described in step 4. When the SSD detects that the SSD has been powered on twice in a time period of no more than 20 seconds, the SSD firmware switches the system disk command and resets the continuous power-on counter to zero.

[0014] Step 11, S190, regarding whether the system's normal startup and operation meet the power-off count requirements for the disk switching command operation, refers to whether the disk switching command operation in step 10 was successful. If unsuccessful, the operating system still cannot run normally. Refer to step S191 and return to S180 to perform the power-off and power-on operation twice as required. If the disk switching command operation is successful, the operating system will start and run normally, entering the operating system interface or application software interface. The original hidden partition backup disk (secondary disk) will be converted into a visible partition disk, and the damaged original visible partition disk (primary disk) will be converted into a hidden partition disk; the primary and secondary disk identities will be switched; refer to step S200.

[0015] Step 12, S200, refers to performing the unbackup of the operating system, which means backing up the explicit partition system disk that has been transformed to the implicitly damaged secondary disk, thus achieving mutual backup of the operating systems; it is necessary to return to repeat steps S120-S150.

[0016] To summarize the above steps, according to the requirements of steps 5-7, the data of the explicit system partition of the firmware is completely backed up to the implicit secondary partition, referring to steps S120-S150; according to the requirements of steps 10-11, the disk switching command is implemented, referring to steps S180-S200; according to the requirements of step 12, the operating system disk is mutually backed up; and so on, repeating steps S120-S200 to ensure that the device has a backed-up operating system disk at all times. Detailed Implementation

[0017] The present invention will now be described in detail with reference to the accompanying drawings. The specific operation methods in the method embodiments can also be applied to the device embodiments or system embodiments.

[0018] Step 1: Method for mutual backup of operating system partitions on a single RAID solid-state drive and the solid-state drive itself. The mutual backup of system partitions on the single SSD means that the SSD is opened at the factory with two partitions of the same size. The visible primary partition is the operating system installation partition, and the secondary partition is the hidden operating system backup partition. The visible capacity of the SSD is half of its actual capacity; refer to step S100.

[0019] Step 2, S110, refers to the Windows operating system; the installation of necessary drivers or application software on the system disk refers to the underlying hardware driver software and necessary application software for device operation.

[0020] Step 3, S120: The firmware of the single-chip RAID solid-state drive operating system partition mutual backup SSD has an SSD power-on count function, defining a continuous power-on counter. Different command functions are triggered by different counts. Within a certain agreed time period (20 seconds in this example), power-on exceeding the agreed time (20 seconds) is considered normal power-on. Under normal power-on conditions, the firmware will reset the continuous power-on counter to zero. The continuous power-on / off n times refers to powering on and off the SSD n times through the device's power-on / off method. Because the SSD is not an independent device, its power supply is an internal power supply controlled by the device's motherboard, and powering on and off the SSD can only be achieved through the device's power-on / off method.

[0021] Step 4, S120: The SSD detects that it has been powered on n times in no more than 20 seconds. In this example, n=5. The number of power-on times that are less than the specified duration of 20 seconds is counted in the continuous power-on counter. If there are 5 consecutive power-on times, the firmware of the SSD will trigger the instruction to completely back up the explicit partition to the implicit secondary partition.

[0022] Step 5: Power on normally. When the triggering requirement of the firmware to fully back up the visible partition to the hidden secondary partition as described in step S130 is met, it means that the firmware's instruction to fully back up the visible system partition to the hidden secondary partition is effective after 5 consecutive power-on operations in step 4. The device will remain in the BIOS interface. The waiting time is 50 minutes depending on the backup capacity. See step S140. If the triggering requirement is not met and other instruction functions are not triggered, the device will directly enter the system interface. See step S131.

[0023] Step 6, S150, refers to the 50-minute wait required for the explicit primary partition to be backed up to the implicit secondary partition. Since this backup process is controlled within the SSD firmware, even if the SSD has completed the data backup, it cannot control the device to restart. During and after the backup process, the device remains in the BIOS interface, and the user can only wait blindly until the estimated time exceeds the backup requirement before shutting down and restarting.

[0024] Step 7, S160, refers to the SSD firmware sensing that the SATA protocol bus has not transmitted data for a long time. The SSD firmware will then perform data backup of the explicit operating system disk partition to the implicit operating system secondary partition disk.

[0025] Step 8 and step S170 describe a system crash issue, which means that the operating system files are corrupted due to various reasons during device operation, causing the device to malfunction; a system switch operation needs to be performed to enable the operating system backed up on the secondary disk.

[0026] Step 9 and step S180 refer to the continuous power-on and power-off times m times. In this example, m=2. This means that the power is turned off and on twice to the SSD in the same way as described in step 3. When the SSD detects that the SSD has been powered on twice in a time period of no more than 20 seconds, the SSD firmware switches the system disk command and resets the continuous power-on counter to zero.

[0027] Step 10, S190, regarding whether the system's normal startup and operation meet the power-off count requirements for the disk switching command operation, refers to whether the system disk switching command operation in Step 9 is successful. If it is unsuccessful and does not meet other command function operations, the operating system still cannot run normally. Refer to step S191 and return to S180 to perform the power-off and power-on operation twice as required. If the system disk switching command operation is successful, the operating system will start and run normally, entering the operating system interface or application software interface. The original hidden partition backup disk (secondary disk) will be converted into a visible partition disk, and the damaged original visible partition disk (primary disk) will be converted into a hidden partition disk; the primary and secondary disk identities will be switched; refer to step S200.

[0028] Step 11, S200, involves performing an unbackup of the operating system, which means backing up the exposed system disk (which has had its identity changed) to a hidden, damaged secondary disk, thus achieving mutual backup of the operating systems. This requires returning to repeat steps S120-S150.

[0029] To summarize the above steps, according to the requirements of steps 4-6, the data of the explicit system partition of the firmware is completely backed up to the implicit secondary partition, referring to steps S120-S150; according to the requirements of steps 9-10, the disk switching command is implemented, referring to steps S180-S200; according to the requirements of step 11, the operating system disk is mutually backed up; and so on, repeating steps S120-S200 to ensure that the device has a backed-up operating system disk at all times. Attached Figure Description Figure 1 Brief process of single-chip RAID solid-state drive operating system mutual backup disk; Figure 2 Detailed process for creating a backup disk between a single RAID solid-state drive and an operating system.

Claims

1. Claim 1: A method for mutual backup of operating system partitions on a single RAID solid-state drive and a solid-state drive, wherein the mutual backup of the system partitions on the single SSD is performed by opening the SSD with two partitions of the same capacity before it leaves the factory, wherein the explicit primary partition is the operating system installation partition, and the secondary partition is the hidden operating system backup partition, and the explicit capacity of the SSD is half of its actual capacity, see step S100.

2. Claim 2: The explicit operating system installation partition of the single-chip RAID solid-state drive operating system partition mutual backup SSD can be customized and repartitioned by the user, or the operating system, as well as the necessary drivers and application software for device operation, can be directly installed on the main partition, see step S110.

3. Claim 3: The operating system may be Windows, Linux, Android, iOS, Unix; domestically produced series of commonly used operating systems such as Kylin, Tongxin, Hongmeng, Euler operating systems, etc., and other operating systems; see step S110.

4. Claim 4: The installation of necessary drivers or application software on the system disk refers to the underlying hardware driver software and necessary application software during device operation, see step S110.

5. Claim 5: The single-chip RAID solid-state drive operating system partition mutual backup SSD has a firmware with SSD power-on count statistics function, which defines a counter for continuous power-on, and triggers different command functions based on different counts; see step S120.

6. Claim 6: The specified time period is because the SSD can only calculate the power-on duration after power-on. Power-on exceeding the specified duration (t seconds) is considered normal power-on. Under normal power-on conditions, the firmware will reset the continuous power-on counter to zero. Power-on less than the specified duration (t seconds) is considered a special power-on operation that needs to be counted, and the continuous power-on counter is counted. When the next normal power-on exceeds the power supply duration t seconds, an instruction is executed and the continuous power-on counter is reset to zero. See step S120.

7. Claim 7: The continuous power-on and power-off n times refers to powering off and on the SSD n times by powering on and off the device. Since the SSD is not an independent device, its power supply is an internal power supply controlled by the device's motherboard. Powering off and on the SSD can only be achieved by powering off and on the device. See step S120.

8. Claim 8: The SSD detects that the SSD has been powered on continuously n times within a certain agreed time period (t seconds), and the number of power-on times less than the specified duration (t seconds) is counted into the continuous power-on counter. When the SSD is powered on continuously n times, the firmware of the SSD is triggered to completely back up the explicit partition to the implicit secondary partition; see step S130.

9. Claim 9: When the device powers on normally, and the triggering operation in step S130 meets the requirement of the number of power-off operations set for the firmware to completely back up the explicit partition to the implicit secondary partition, the number of consecutive power-on operations n in claim 8 is defined as the firmware's instruction to completely back up the data of the explicit system partition to the implicit secondary partition. The device remains in the BIOS interface, and the waiting time varies depending on the backup capacity, but is at least half an hour; see step S140. If the triggering number requirement is not met and other instruction functions are not triggered, the device directly enters the system interface; see step S131.

10. Claim 10: The waiting time refers to the time required for the explicit primary partition to be backed up to the implicit secondary partition. Since this backup process is controlled within the SSD firmware, even if the SSD has completed the data backup, the SSD cannot control the device to restart. During and after the backup process, the device remains in the BIOS interface, and the user can only wait blindly until the estimated time exceeds the backup requirement before shutting down and restarting. See step S150.

11. Claim 11: When the device enters an idle state in step S160, it means that when the SSD firmware senses that the USB bus / SATA protocol bus / NVME protocol bus, etc., has not transmitted data for a long time, the SSD firmware will perform the addition and backup of the explicit operating system disk partition data to the implicit operating system secondary partition disk.

12. Claim 12: The occurrence of the operating system crash problem in the device refers to the situation where the operating system files are damaged due to various reasons during the operation of the device, resulting in the device being unable to operate; a system switching operation needs to be performed to enable the operating system backed up on the secondary disk; see step S170.

13. Claim 13: The continuous power-on and power-off times m times (note that m ≠ n) refers to the number of times the SSD is powered off and powered on in the same manner as described in claim 6. When the SSD detects that the SSD has been powered on continuously for no more than m times within a certain agreed time period, the SSD firmware switches the system disk command and resets the continuous power-on counter to zero, see step S180.

14. Claim 14: Whether the normal startup and operation of the system meets the power-off count requirement of the disk switching command operation refers to checking whether the system disk switching command operation in claim 13 is successful. If the system disk switching command is unsuccessful and its count does not meet the requirements of other function commands, the operating system still cannot operate normally. See S191, and return to S180 to perform the power-off and power-on operation m times as required. If the system disk switching command operation is successful, the system starts up and runs normally, enters the operating system interface or application software interface, the backup disk (secondary disk) of the original hidden partition is converted into a visible partition disk, and the damaged original visible partition disk (primary disk) is converted into a hidden partition disk; the primary and secondary disk identities are switched; see steps S190 and S200.

15. Claim 15: The operation of performing the reverse backup of the operating system in S200 refers to the reverse backup of the explicit partition system disk that has been transformed to the implicitly damaged secondary disk, thereby realizing mutual backup of the operating systems; it is necessary to return to repeat the operation of steps S120-S150.

16. Claim 16: Implement the complete backup of data from the explicit system partition to the implicit secondary partition according to claims 7-10, referring to steps S120-S150; implement the disk switching command according to claims 12-13, referring to steps S180-S200; According to claim 15, mutual backup of the operating system disk is achieved; steps S120-S200 are executed repeatedly to ensure that the device has a backup operating system disk from beginning to end.