Downloading the recovery image via datablocks

By downloading and building data blocks of recovery images in computing devices, the problem of outdated storage recovery images is solved, increasing the flexibility and convenience of operating system repairs, and avoiding disk space and restarting of computing devices.

CN112470121BActive Publication Date: 2025-02-25HEWLETT PACKARD DEVELOPMENT COMPANY LP
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN201880096174.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2018-11-05
Publication Date
2025-02-25
Estimated Expiration
2038-11-05

AI Technical Summary

Technical Problem

When the operating system of a computing device is corrupted or corrupted, the stored recovery image may become outdated, causing security issues and user friction while preserving partitions to occupy disk space.

Method used

Through a non-transitory computer-readable storage medium, the instructions cause the processor of the computing device to determine and transmit the block size in response to the block size request received by the recovery agent, download the data block of the recovery image from the server, and in the storage device of the computing device. Storage and building recovery images in the process.

Benefits of technology

This method adds flexibility and convenience to repair the operating system, avoids retaining partitions to occupy disk space, and avoids restarting of the computing device during recovery operations.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN112470121B_ABST
    Figure CN112470121B_ABST
Patent Text Reader

Abstract

An example non-transitory computer-readable storage medium includes instructions that, when executed, cause a processor of a computing device to: determine a block size via firmware instructions of the computing device in response to receiving a block size request from a recovery agent executable at an operating system of the computing device; transmit the block size from the firmware instructions to the recovery agent; sequentially receive data blocks of a recovery image from the recovery agent; store the data blocks in a storage device of the computing device; and construct a recovery image using the data blocks.
Need to check novelty before this filing date? Find Prior Art

Description

Background Art

[0001] The operating system of a computing device can control many aspects of the computing device. When the operating system is damaged or corrupted, the operation of the computing device may be severely limited or the computing device may be rendered inoperable. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Some examples of the present application are described with respect to the following figures:

[0003] Figure 1 A system for transferring a recovery image from a server to a computing device via a data block according to an example is illustrated;

[0004] Figure 2 FIG. 1 illustrates the process of downloading a restore image during a restore image download operation according to an example. Figure 1 The system recovery agent and Figure 1 Message and data exchange between firmware instructions of the system;

[0005] Figure 3 illustrates a method of operation at a computing device for downloading a recovery image via a data block according to an example;

[0006] Figure 4 illustrates a method of operation at a computing device for downloading a recovery image via a data block according to another example;

[0007] Figure 5 illustrates a computing device for downloading a recovery image via a data block according to an example;

[0008] Figure 6 illustrates a computing device for downloading a recovery image via a data block according to another example; and

[0009] Figure 7 A computing device for downloading a recovery image via a data block according to another example is illustrated. DETAILED DESCRIPTION

[0010] When the operating system of a computing device is destroyed or damaged, the operating system can be repaired via a recovery operation. The computing device can store a recovery image in a reserved partition of a storage device of the computing device. The computing device can use the recovery image to replace the destroyed or damaged operating system. However, once the computing device updates the operating system (e.g., by installing a security patch), the stored recovery image may become outdated. This may create security issues and user friction because the operating system will be restored without the latest security patch, and the user may also have to spend a lot of time installing the security patch. In addition, the reserved partition may reduce the disk space available for use by the computing device.

[0011] Examples described herein provide a method for downloading a recovery image via data blocks. For example, a non-transitory computer-readable storage medium may include instructions that, when executed, cause a processor of a computing device to: determine a block size via firmware instructions of the computing device in response to receiving a block size request from a recovery agent executable at an operating system of the computing device; transmit the block size from the firmware instructions to the recovery agent; sequentially receive data blocks of a recovery image from the recovery agent; store the data blocks in a storage device of the computing device; and construct a recovery image using the data blocks.

[0012] In another example, a non-transitory computer-readable storage medium may include instructions that, when executed, cause a processor of a computing device to: request a block size from firmware instructions of the computing device via a recovery agent executable at an operating system of the computing device; in response to receiving the block size, download a first data block of a recovery image from a server via the recovery agent, wherein a size of the first data block corresponds to the block size; receive the first data block from the server; transfer a first data trunk from the recovery agent to the firmware instructions; and in response to receiving an acknowledgement associated with the first data block from the firmware instructions, download a second data block of the recovery image from the server via the recovery agent.

[0013] In another example, a computing device may include a first storage device, a firmware instruction stored in the first storage device, a second storage device, a recovery agent and an operating system (OS), a third storage device, and a processor. The recovery agent and the OS may be stored in the second storage device. The processor may determine the block size of the recovery image via the firmware instruction. The processor may also download the first data block of the recovery image from the server via the recovery agent. The size of the first data block may correspond to the block size. The processor may further download the second data block of the recovery image from the server via the recovery agent in response to the determination that the first data block is valid. The size of the second data block may correspond to the block size. The processor may further store the first data block and the second data block in the third storage device via the firmware instruction. The processor may further use the first block and the second block to build the recovery image via the firmware instruction. The examples described herein may increase the flexibility and / or convenience associated with repairing the operating system.

[0014] Figure 1 A system 100 is illustrated for transferring a recovery image from a server to a computing device via a data block according to an example. The system 100 may include a computing device 102 and a server 104.

[0015] Computing device 102 may be, for example, a notebook computer, a desktop computer, an all-in-one system, a tablet computing device, a mobile phone, an e-book reader, or any other electronic device suitable for downloading a recovery image via a data block. In some examples, server 104 may be similar to computing device 102. In some examples, server 104 may be a web-based server, a local area network server, a cloud-based server, or any other electronic device suitable for transmitting a recovery image via a data block.

[0016] The computing device 102 may include a processor 106, a first storage device 108, a second storage device 110, and a third storage device 112. The first storage device 108, the second storage device 110, and the third storage device 112 may each be a different device. The computing device 102 may also include firmware instructions 114 stored in the first storage device 108. The computing device 102 may further include an operating system (OS) 116 and a recovery agent 118. The OS 116 and the recovery agent 118 may be stored in the second storage device 110.

[0017] As used herein, the first storage device 108, the second storage device 110, and the third storage device 112 may be non-volatile memory. Non-volatile memory may retain stored data even after being power cycled. In some examples, the first storage device 108 may be implemented using an electrically erasable programmable read-only memory (EEPROM) device (e.g., an EEPROM chip). The second storage device 110 may be implemented using a solid-state drive (SSD) or a hard disk drive (HDD). The third storage device 112 may be implemented using an embedded multimedia card (eMMC) device.

[0018] As used herein, firmware instructions 114 may be a series of instructions executable by processor 106. Firmware instructions 114 may be stored in a non-volatile memory, such as first storage device 108. Firmware instructions 114 may be a basic input / output system (BIOS) of computing device 102, which initializes the hardware of computing device 102 and loads OS 116 when computing device 102 is booting. Firmware instructions 114 may be implemented based on the Unified Extensible Firmware Interface (UEFI) specification.

[0019] As used herein, OS 116 may be a series of instructions that may be executed by processor 106. When OS 116 is executing, OS 116 may manage both hardware and software resources of computing device 102. In some examples, OS 116 may be implemented as a 32-bit operating system. In some examples, OS 116 may be implemented as a 64-bit operating system. In some examples, OS 116 may be implemented as a Windows operating system. In some examples, OS 116 may be implemented as a Linux operating system.

[0020] As used herein, the recovery agent 118 may be a series of instructions executable by the processor 106. The recovery agent 118 may be implemented as a background process (eg, a Windows service, a daemon, etc.) executing within the OS 116.

[0021] During operation, the recovery agent 118 may be automatically (i.e., without any user input) executed periodically (e.g., every hour, every day, etc.). During execution, the recovery agent 118 may determine whether a recovery image update condition has been met. In some examples, the recovery agent 118 may communicate with the server 104 to determine the date of the second recovery image 120 stored in the server 104. The recovery agent 118 may compare the date of the second recovery image 120 with the date of the first recovery image 122 stored in the third storage device 112. As used herein, a recovery image (the first recovery image 122 and the second recovery image 120) may be a file containing the content and structure of the OS 116.

[0022] The recovery agent 118 may determine whether the recovery image update condition has been met based on the comparison. If the date of the first recovery image 122 is older than the data of the second recovery image 120, the recovery agent 118 may determine that the recovery image update condition has been met. Therefore, the recovery agent 118 may determine to download the second recovery image 120 to replace the first recovery image 122. In some examples, instead of a date, other aspects (such as the corresponding version numbers, age, etc. of the recovery images 120 and 122) may be used to perform the comparison.

[0023] In some examples, recovery agent 118 may download a recovery image from server 104 without performing a comparison each time recovery agent 118 is executed. In some examples, recovery agent 118 may download a recovery image from server 104 if recovery agent 118 detects that a recovery image is not stored in third storage device 112.

[0024] In response to a determination that the second recovery image 120 is to be downloaded from the server 104, the recovery agent 118 may receive from the firmware instructions 114 a block size to be used to download the second recovery image 120. The recovery agent 118 may download the second recovery image 120 in data blocks, where the size of each data block is based on the block size. For example, the block size may be 1024 bytes. When the block size is determined, the recovery agent 118 may begin downloading the second recovery image 120 by requesting the data blocks of the second recovery image 120 from the server 104.

[0025] In response to receiving the request, server 104 may transmit the data blocks in sequence. For example, server 104 may transmit first data block 124 to recovery agent 118. In response to receiving first data block 124, recovery agent 118 may transmit first data block 124 to firmware instructions 114. Firmware instructions 114 may verify first data block 124. In some examples, firmware instructions 114 may verify first data block 124 using a hash value.

[0026] In response to the determination that the first data block 124 is valid, the firmware instructions 114 may confirm to the recovery agent 118 that the firmware instructions 114 have accepted the first data block 124. In addition, the firmware instructions 114 may store the first data block 124 in the third storage device 112. In some examples, the third storage device 112 may be accessible only by the firmware instructions 114. The OS 116 may not be able to access the third storage device 112. Therefore, if the OS 116 is included, it is unlikely that the data stored in the third storage device 112 (e.g., the first data block 124) is included. In response to receiving the confirmation associated with the first data block 124 from the firmware instructions 114, the recovery agent 118 may begin downloading the second data block 126 of the second recovery image 120 from the server 104. In response to the determination that the first data block 124 is invalid, the firmware instructions 114 may reject the first data block 124. When the firmware instructions 114 reject the first data block 124, the recovery agent 118 may download the first data block 124 again.

[0027] During a recovery operation for repairing or replacing OS 116, firmware instructions 114 may delete first recovery image 122 and build second recovery image 120 in third storage device 112 using all data blocks of second recovery image 120 (e.g., first data block 124 and second data block 126). When building second recovery image 120, firmware instructions 114 may discard all data blocks of second recovery image 120. In some examples, before firmware instructions 114 are to build second recovery image 120, firmware instructions 114 may verify all data blocks again. When all data blocks are verified, firmware instructions 114 may build second recovery image 120 and use second recovery image 120 to repair and / or replace OS 116.

[0028] By downloading the second recovery image 120 in data blocks and storing the data blocks directly in the third storage device 112, a reserved partition for recovery image storage in the second storage device 110 may be avoided. Therefore, more storage space in the second storage device 110 may be available for use by the user of the computing device 102. In addition, a reboot of the computing device 102 may be avoided during a recovery operation because the second recovery image 120 is not copied from the second storage device 110 to the third storage device 112.

[0029] Figure 2 FIG. 1 illustrates the process of downloading a restore image during a restore image download operation according to an example. Figure 1 Messages and data exchanged between the recovery agent 118 of the computing device 102 and the firmware instructions 114 of the computing device 102.

[0030] In response to the recovery agent 118 determining that a recovery image (such as the second recovery image 120) is to be downloaded from the server 104, the recovery agent 118 may transmit a block size request 202 to the firmware instructions 114. In response to receiving the block size request 202, the firmware instructions 114 may determine a block size 204. In some examples, the block size 204 may be fixed and stored in the computing device 102 (e.g., in the first storage device 108). The firmware instructions 114 may retrieve the block size 204 and transmit the block size 204 to the recovery agent 118.

[0031] In some examples, the firmware instructions 114 may dynamically determine the block size 204 based on the block size request 202. That is, the firmware instructions 114 may determine a different block size for each block size request. In some examples, the block size request 202 may include the size of the second recovery image 120, the quality of the network connection at the computing device 102, the utilization percentage of the processor 106, or a combination thereof. It should be understood that the block size request 202 may include any other information indicative of the workload on the computing device 102.

[0032] Using the information in the block size request 202, the firmware instructions 114 may calculate the block size 204 so that downloading the data block may have minimal impact on the performance of the computing device 102. For example, instead of setting the block size 204 to a larger unit (e.g., in megabytes) for a shorter download process, when the computing device 102 is under a heavy workload and / or the network connection has a low bandwidth, the firmware instructions 114 may set the block size 204 to a smaller unit (e.g., in bytes). When the computing device 102 has a light workload and / or the network connection has a high bandwidth, the firmware instructions 114 may set the block size 204 to a larger unit.

[0033] When the block size 204 is determined, the firmware instructions 114 may transmit the block size 204 to the recovery agent 118. The recovery agent 118 may begin downloading the second recovery image 120 in data blocks from the server 104. Each data block may have a size corresponding to the block size 204. When the recovery agent 118 receives the first data block 124 from the server 104, the recovery agent 118 may transmit the first data block 124 to the firmware instructions 114.

[0034] When the firmware instructions 114 successfully verify the first data block 124, the firmware instructions 114 may transmit a confirmation 206 associated with the first data block 124 to the recovery agent 118. The firmware instructions 114 may store the first data block 124 in the third storage device 112, such as Figure 1 The confirmation 206 may indicate to the recovery agent 118 that the firmware instructions 114 have accepted the first data block 124. In response to receiving the confirmation 206, the recovery agent 118 may download the next data block (e.g., the second data block 126) from the server 104 and then transmit the second data block 126 to the firmware instructions 114. The firmware instructions 114 may process the second data block 126 in the same manner as the first data block 124.

[0035] When the firmware instructions 114 cannot successfully verify the first data block 124, the firmware instructions 114 may transmit an error message 208 associated with the first data block 124 to the recovery agent 118. The error message 208 may indicate that the firmware instructions 114 have rejected the first data block 124. In response to receiving the error message 208, the recovery agent 118 may download the first data block 124 again from the server 104 to repeat the process.

[0036] When the firmware instructions 114 have received and accepted all data blocks of the second recovery image 120, the firmware instructions 114 can transmit a termination message 210 to the recovery agent 118 to indicate that the download of the second recovery image 120 has been completed. In response to receiving the termination message 210, the recovery agent 118 can terminate the download process with the server 104.

[0037] Figure 3 A method 300 of operations at a computing device for downloading a recovery image via a data block according to an example is illustrated. The method 300 may be performed by Figure 1-2 The recovery agent 118 is used to implement it.

[0038] At 302, the recovery agent 118 may determine whether a recovery image update condition has been met. For example, the recovery agent 118 may compare the first recovery image 122 to the second recovery image 120. If the first recovery image 122 is older than the second recovery image 120, the recovery agent 118 may determine that the recovery image update condition has been met. At 304, in response to a determination that the recovery image update condition has been met, the recovery agent 118 may request a block size 204 from the firmware instructions 114. For example, the recovery agent 118 may transmit a block size request 202 to the firmware instructions 114 to request the block size 204.

[0039] At 306, the recovery agent 118 may download the data block from the server 104 based on the block size 204. For example, the recovery agent 118 may download the first data block 124 of the second recovery image 120 from the server 104. At 308, the recovery agent 118 may transmit the first data block 124 to the firmware instructions 114. At 310, the recovery agent 118 may determine whether the first data block 124 has been accepted by the firmware instructions 114. For example, when the first data block 124 has been accepted, the recovery agent 118 may receive an acknowledgement 206 from the firmware instructions 114. When the first data block has been rejected, the recovery agent 118 may receive an error message 208 from the firmware instructions 114.

[0040] When the first data block 124 has been rejected, the recovery agent 118 may download the first data block 124 again from the server 104. When the first data block 124 has been accepted, at 312, the recovery agent 118 may determine whether a termination message 210 has been received. When the termination message 210 has been received, the recovery agent 118 may terminate the download process of the second recovery image 120. When the recovery agent 118 has not received the termination message 210, at 314, the recovery agent 118 may download the next data block (e.g., the second data block 126) of the second recovery image 120 from the server 104.

[0041] Figure 4A method 400 of operations at a computing device for downloading a recovery image via a data block according to another example is illustrated. The method 400 may be performed by Figure 1-2 The firmware instruction 114 is implemented.

[0042] At 402, the firmware instructions 114 may receive a block size request 202 from the recovery agent 118. At 404, the firmware instructions 114 may determine a block size 204 based on the block size request 202. In some examples, the block size 204 may be fixed and may be stored in the third storage device 112. Thus, the firmware instructions 114 may retrieve the fixed block size 204 in response to receiving the block size request 202. In some examples, the block size 204 may be calculated based on information in the block size request 202. The block size request 202 may include information indicating a workload of the computing device 102, and the firmware instructions 114 may calculate the block size 204 based on the workload.

[0043] At 406, the firmware instructions 114 may transmit the block size 204 to the recovery agent 118. At 408, the firmware instructions 114 may receive a data block, such as the first data block 124, from the recovery agent 118. At 410, the firmware instructions 114 may verify the first data block 124 to determine whether to accept the first data block 124. When the first data block 124 is successfully verified, the firmware instructions 114 may accept the first data block 124. For example, when a hash value of the first data block 124 matches an expected hash value, the firmware instructions 114 may successfully verify the first data block 124. When the hash value does not match the expected hash value, the first data block 124 may have failed verification.

[0044] At 412, when the firmware instructions 114 reject the first data block 124, the firmware instructions 114 may transmit the error message 208 to the recovery agent 118 to indicate that the first data block 124 has been rejected. At 414, when the firmware instructions 114 accept the first data block 124, the firmware instructions 114 may store the first data block 124 in the third storage device 112. At 416, the firmware instructions 114 may transmit the confirmation 206 to the recovery agent 118 to indicate that the first data block 124 has been accepted.

[0045] At 418, the firmware instructions 114 may determine whether more data blocks will come from the recovery agent 118. For example, the recovery agent 118 may obtain the size of the second recovery image 120 from the server 104. The recovery agent 118 may include the size of the second recovery image 120 in the block size request 202. The firmware instructions 114 may calculate the number of data blocks based on the size of the second recovery image 120. The firmware instructions 114 may count the number of received data blocks to determine whether more data blocks will come from the recovery agent 118. When more data blocks are expected, the firmware instructions 114 may wait for the next data block from the recovery agent 118.

[0046] At 420, when the firmware instructions 114 determine that the last data block has been accepted, the firmware instructions 114 can transmit a termination message 210 to the recovery agent 118 to indicate that all data blocks of the second recovery image 120 have been received and accepted. Therefore, the recovery agent 118 can terminate the download process of the second recovery image 120.

[0047] Figure 5 FIG. 5 illustrates a computing device 500 for downloading a recovery image via a data block according to an example. The computing device 500 may implement Figure 1 The computing device 500 may include a processor 502 and a computer-readable storage medium 504.

[0048] Processor 502 may be a central processing unit (CPU), a semiconductor-based microprocessor, and / or other hardware device suitable for retrieving and executing instructions stored in computer-readable storage medium 504. Processor 502 may fetch, decode, and execute instructions 506, 508, 510, 512, and 514 to download a recovery image from a server, such as server 104. As an alternative to or in addition to retrieving and executing instructions, processor 502 may include at least one electronic circuit including electronic components for performing the functions of instructions 506, 508, 510, 512, 514, or a combination thereof.

[0049] Computer readable storage medium 504 may be any electronic, magnetic, optical or other physical storage device containing or storing executable instructions. Thus, computer readable storage medium 504 may be, for example, a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), a storage device, an optical disk, etc. In some examples, storage medium 504 may be a non-transitory storage medium, where the term "non-transitory" does not include transient propagating signals. Computer readable storage medium 504 may be encoded with a series of processor executable instructions 506, 508, 510, 512, and 514.

[0050] Block size determination instructions 506 may determine block size 204. For example, referring to Figure 2 , the firmware instructions 114 may determine the block size 204. The block size transmission instructions 508 may transmit the block size from the firmware instructions 114 to the recovery agent 118. For example, referring to Figure 2 , firmware instructions 114 may transmit block size 204 to recovery agent 118. Data block receiving instructions 510 may receive a data block from recovery agent 118. For example, referring to Figure 2 , the firmware instructions 114 may receive the first data block 124 from the recovery agent 118 .

[0051] The data block storage instruction 512 may store the received data block in a storage device. Figure 1 , the firmware instructions 114 may store the first data block 124 in the third storage device 112. The recovery image construction instructions 514 may use the data blocks to construct a recovery image. Figure 1 , the firmware instructions 114 may construct the second recovery image 120 in the third storage device 112 using all data blocks of the second recovery image 120 (eg, the first data block 124 and the second data block 126 ).

[0052] Figure 6 A computing device 500 is illustrated for downloading a recovery image via a data block according to another example. In addition to being encoded with instructions 506, 508, 510, 512, and 514, computer readable storage medium 504 may be encoded with instructions 602, 604, 606, 608, and 610.

[0053] The data block verification instructions 602 may verify each received data block, such as the first data block 124 and the second data block 126. For example, referring to Figure 1 , firmware instructions 114 may verify first data block 124. Confirmation transmission instructions 604 may transmit a confirmation to recovery agent 118. For example, referring to Figure 2 When the firmware instructions 114 successfully verify the first data block 124 , the firmware instructions 114 may transmit an acknowledgement 206 to the recovery agent 118 .

[0054] Error message transmission instructions 606 may transmit an error message to recovery agent 118. For example, referring to Figure 2 When the firmware instructions 114 cannot successfully verify the first data block 124 , the firmware instructions 114 may transmit an error message 208 to the recovery agent 118 .

[0055] Termination message transmission instructions 608 may transmit termination message 210 to recovery agent 118. For example, referring to Figure 2When the firmware instructions 114 have received and accepted all the data blocks of the second recovery image 120, the firmware instructions 114 may transmit a termination message 210 to the recovery agent 118 to indicate that the download of the second recovery image 120 has been completed. After the second recovery image 120 is built in the third storage device 112, the data block discarding instructions 610 may discard all the data blocks stored in the third storage device 112. For example, referring to Figure 1 When the second recovery image 120 is constructed, the firmware instructions 114 may discard all data blocks of the second recovery image 120 .

[0056] Figure 7 A computing device 700 is illustrated for downloading a recovery image via a data block according to another example. The computing device 700 may implement Figure 1 The computing device 102 of FIG. 700 may include a processor 502 and a computer-readable storage medium 702. The computer-readable storage medium 702 may be similar to the computer-readable storage medium 504.

[0057] The computer readable storage medium 702 may be encoded with instructions 704, 706, and 708. In some examples, the computer readable storage medium 702 may also be encoded with instructions 710. The block size request instructions 704 may transmit the block size request 202 to the firmware instructions 114. For example, referring to Figure 2 , the recovery agent 118 may transmit the block size request 202 to the firmware instructions 114. The data block download instructions 706 may download the data block from the server 104. For example, referring to Figure 2 , recovery agent 118 may download data blocks 124 and 126 from server 104 .

[0058] The data block transfer instructions 708 may transfer the data block to the firmware instructions 114. For example, referring to Figure 1 , the recovery agent 118 may transfer the data blocks 124 and 126 to the firmware instructions 114. The data block download termination instruction 710 may terminate the download process of the recovery image (such as the second recovery image 120). Figure 2 In response to receiving the termination message 210 , the recovery agent 118 may terminate the download process with the server 104 .

[0059] The use of "comprises," "including," or "having" are synonymous and variations thereof herein are meant to be inclusive or open-ended and do not exclude additional, unrecited elements or method steps.

Claims

1. A non-transitory computer-readable storage medium comprising instructions that, when executed, cause a processor of a computing device to: The block size is dynamically determined via firmware instructions in a first storage device of the computing device in response to receiving a block size request from a recovery agent executable at an operating system in a second storage device of the computing device, wherein The processor determines the block size based on a percentage of utilization of the processor, a quality of the network connection, a size of the recovery image, or a combination thereof; transferring the block size from the firmware instructions in the first storage device to the recovery agent in the second storage device; receiving data blocks of the recovery image from the recovery agent in the second storage device in sequence and verifying the data blocks; storing the data block in the first or second storage device or in an additional storage device of the computing device; as well as Use the data blocks to build a recovery image.

2. The non-transitory computer-readable storage medium of claim 1 , wherein the instructions, when executed, further cause the processor to: In response to receiving the first data block from the recovery agent, verifying the first data block; Responsive to a determination that the first data block is valid, transmitting an acknowledgement to a recovery agent; and In response to a determination that the first data block is invalid, an error message is transmitted to the recovery agent.

3. The non-transitory computer-readable storage medium of claim 1 , wherein the instructions, when executed, further cause the processor to: Responsive to a determination that all data blocks of the recovery image have been stored in the storage device, a termination message is transmitted to the recovery agent.

4. The non-transitory computer-readable storage medium of claim 1 , wherein the instructions, when executed, further cause a processor to: During a restore operation, verifying data blocks; and Responsive to a determination that all of the data blocks are valid, a recovery image is constructed using the data blocks.

5. The non-transitory computer-readable storage medium of claim 4, wherein the instructions, when executed, further cause the processor to: After building the recovery image, discarding all data blocks; and Store the recovery image on a storage device.

6. The non-transitory computer-readable storage medium of claim 1 , wherein the instructions, when executed, further cause a processor to: The block size is determined via firmware instructions based on the quality of the network connection.

7. The non-transitory computer-readable storage medium of claim 1 , wherein the instructions, when executed, further cause a processor to: The block size is determined via firmware instructions based on the utilization percentage of the processor.

8. A non-transitory computer-readable storage medium comprising instructions that, when executed, cause a processor of a computing device to: The dynamically determined block size is requested from firmware instructions in a first storage device of the computing device via a recovery agent executable at an operating system of the computing device, wherein The block size is determined based on a percentage of processor utilization, a quality of a network connection, a size of a recovery image, or a combination thereof; in response to receiving the block size, downloading a first data block of the recovery image from the server via the recovery agent, wherein a size of the first data block corresponds to the block size; receiving a first data block from a server; firmware instructions for transferring a first body of data from a recovery agent in a second storage device to a first storage device; as well as In response to receiving an acknowledgement associated with the first data block from the firmware instructions, a second data block of the recovery image is downloaded from the server via the recovery agent.

9. The non-transitory computer-readable storage medium of claim 8, wherein the instructions, when executed, further cause the processor to: In response to receiving an error message associated with the first data block, the first data block is downloaded again from the server.

10. The non-transitory computer-readable storage medium of claim 8, wherein the instructions, when executed, further cause the processor to: In response to receiving a termination message from the firmware instruction, downloading of data blocks of the recovery image from the server is terminated.

11. The non-transitory computer-readable storage medium of claim 8, wherein the instructions, when executed, further cause the processor to: comparing a first recovery image in a storage device of the computing device with a second recovery image in a server; and Responsive to a determination that the first recovery image is older than the second recovery image, a block size is requested from the firmware instructions.

12. A computing device comprising: a first storage device; firmware instructions stored in a first storage device; a second storage device; a recovery agent and an operating system (OS), wherein the recovery agent and the OS are stored in a second storage device; a third storage device; and Processor for: dynamically determining a block size of the recovery image via firmware instructions, wherein the processor is configured to determine the block size based on a percentage of utilization of the processor, a quality of a network connection, a size of the recovery image, or a combination thereof; downloading a first data block of the recovery image from the server via the recovery agent, wherein a size of the first data block corresponds to a block size; responsive to a determination that the first data block is valid, downloading a second data block of the recovery image from the server via the recovery agent, wherein a size of the second data block corresponds to the block size; storing the first data block and the second data block in a third storage device via the firmware instructions; and Via firmware instructions, a recovery image is constructed using the first block of data and the second block of data.

13. The computing device of claim 12, wherein: The first storage device, the second storage device, and the third storage device are non-volatile memories.

14. The computing device of claim 12, wherein: The processor is configured to store the recovery image in a third storage device.

Citation Information

Patent Citations

  • Efficient application-aware disaster recovery

    US20130061089A1

  • Enhanced Data Download Mechanism for Power Constrained Internet of Things Devices

    US20180124544A1