Patent Description:
An operating system of a computing device may control many aspects of computing device. When the operating system is corrupted or damaged, the operations of the computing device may be severely limited or the computing device may be rendered inoperable.

Anonymous: "<NPL>] describes a chunked transfer encoding mechanism used for version <NUM> of the Hypertext Transfer Protocol.

<NPL> [retrieved on <NUM>-<NUM>-<NUM>] describes a transmission control protocol for the Internet protocol suite (IP).

<CIT> describes a mechanism for enhanced data download for power constrained internet of things (IoT) devices.

Some examples of the present application are described with respect to the following figures:.

When an operating system of a computing device is corrupted or damaged, the operating system may be repaired via a recovery operation. The computing device may store a recovery image in a reserved partition of a storage device of the computing device. The computing device may replace the corrupted or damaged operating system using the recovery image. However, the stored recovery image may become outdated once the computing device updates the operating system (e.g., by installing security patches). This may create security issues and user friction, because the operating system will be restored without the latest security patches, and also, the user may have to spend a lot of time installing the security patches. Further, the reserved partition may reduce the disk space available to be used by the computing device.

Examples described herein provide an approach to download a recovery image via data chunks. A non-transitory computer-readable storage medium comprises instructions that when executed cause a processor of a computing device to: in response to receiving a chunk size request from a recovery agent executable at an operating system of the computing device, determine a chunk size via firmware instructions of the computing device; transmit the chunk size from the firmware instructions to the recovery agent; receive data chunks of a recovery image from the recovery agent in sequence; store the data chunks in a storage device of the computing device; and construct the recovery image using the data chunks.

Another non-transitory computer-readable storage medium comprises instructions that when executed cause a processor of a computing device to: request, via a recovery agent executable at an operating system of the computing device, a chunk size from firmware instructions of the computing device; in response to receiving the chunk size, download, via the recovery agent, a first data chunk of the recovery image from a server, wherein a size of the first data chunk corresponds to the chunk size; receive the first data chunk from the server; transmit the first data chunk from the recovery agent to the firmware instructions; and in response to receiving an acknowledgement from the firmware instructions associated with the first data chunk, download, via the recovery agent, a second data chunk of the recovery image from the server.

A computing device comprises a first storage device, firmware instructions 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 are stored in the second storage device. The processor determines, via the firmware instructions, a chunk size of a recovery image. The processor also downloads, via the recovery agent, a first data chunk of the recovery image from a server. A size of the first data chunk corresponds to the chunk size. The processor further, in response to a determination that the first data chunk is valid, downloads, via the recovery agent, a second data chunk of the recovery image from the server. A size of the second data chunk corresponds to the chunk size. The processor further stores, via the firmware instructions, the first data chunk and the second data chunk in the third storage device. The processor further constructs, via the firmware instructions, the recovery image using the first chunk and the second chunk. Examples described herein may increase the flexibility and/or convenience associated with repairing an operating system.

<FIG> illustrates a system <NUM> to transmit a recovery image via data chunks from a server to a computing device, according to an example. System <NUM> may include a computing device <NUM> and a server <NUM>.

Computing device <NUM> may be, for example, a notebook computer, a desktop computer, an all-in-one system, a tablet computing device, a mobile phone, an electronic book reader, or any other electronic device suitable to download a recovery image via data chunks. In some examples, server <NUM> may be similar to computing device <NUM>. in some examples, server <NUM> may be a web-based server, a local area network server, a cloud-based server, or any other electronic device suitable to transmit a recovery image via data chunks.

Computing device <NUM> includes a processor <NUM>, a first storage device <NUM>, a second storage device <NUM>, and a third storage device <NUM>. First storage device <NUM>, second storage device <NUM>, and third storage device <NUM> may each be a distinct device. Computing device <NUM> also includes firmware instructions <NUM><NUM> that are stored in first storage device <NUM>. Computing device <NUM> further includes an operating system (OS) <NUM><NUM> and recovery agent <NUM>. OS <NUM> and recovery agent <NUM> are stored in second storage device <NUM>.

As used herein, first storage device <NUM>, second storage device <NUM>, and third storage device <NUM><NUM> may be non-volatile memory. Non-volatile memory may retain stored data even after having been power cycled. In some examples, first storage device <NUM> may be implemented using an Electrically Erasable Programmable Read-Only Memory (EEPROM) device (e.g., an EEPROM chip). Second storage device <NUM> may be implemented using a solid-state drive (SSD) or a hard disk drive (HDD). Third storage device <NUM><NUM> may be implemented using an embedded Multi-Media Card (eMMC) device.

As used herein, firmware instructions <NUM> may be a series of instructions that are executable by processor <NUM>. Firmware instructions <NUM> may be stored in non-volatile memory, such as first storage device <NUM>. Firmware instructions <NUM> may be the Basic Input/Output System (BIOS) of computing device <NUM> that initializes hardware of computing device <NUM> and loads OS <NUM> when computing device <NUM> is booting up. Firmware instructions <NUM> may be implemented based on the Unified Extensible Firmware Interface (UEFI) specification.

As used herein, OS <NUM> may a series of instructions that are executable by processor <NUM>. OS <NUM> may manage both hardware and software resources of computing device <NUM> when OS <NUM><NUM> is executing. In some examples, OS <NUM><NUM> may be implemented as a <NUM>-bit operating system. In some examples, OS <NUM><NUM> may be implemented as a <NUM>-bit operating system. In some examples, OS <NUM> may be implemented as a Windows operating system. In some examples, OS <NUM> may be implemented as a Linux operating system.

As used herein, recovery agent <NUM> may be a series of instructions that are executable by processor <NUM>. Recovery agent <NUM> may be implemented as a background process (e.g., a Windows service, a daemon, etc.) that executes within OS <NUM>.

During operation, recovery agent <NUM> may automatically (i.e., without any user input) execute periodically (e.g., every hour, every day, etc.). During execution, recovery agent <NUM> may determine if a recovery image update condition has been satisfied in some examples, recovery agent <NUM> may communicate with server <NUM> to determine a date of a second recovery image <NUM> stored in server <NUM>. Recovery agent <NUM> may compare the date of second recovery image <NUM> to a date of a first recovery image <NUM> stored in third storage device <NUM><NUM>. As used herein, a recovery image (first recovery image <NUM> and second recovery image <NUM>) may be a file containing the contents and structure of OS <NUM>.

Recovery agent <NUM> may determine if the recovery image update condition has been satisfied based on the comparison. If the date of first recovery image <NUM> is older than the data of second recovery image <NUM>, recovery agent <NUM> may determine that the recovery image update condition has been satisfied. Thus, recovery agent <NUM> may determine that second recovery image <NUM> is to be downloaded to replace first recovery image <NUM>. In some examples, instead of a date, other aspects, such as respective version number, age, etc. of recovery images <NUM> and <NUM> may be used to perform the comparison.

In some examples, recovery agent <NUM> may download a recovery image from server <NUM> every time recovery agent <NUM> is executed without performing the comparison. In some example, recovery agent <NUM> may download a recovery image from server <NUM> if recovery agent <NUM> detects that no recovery image is stored in third storage device <NUM>.

In response to a determination to download second recovery image <NUM> from server <NUM>, recovery agent <NUM> receives a chunk size from firmware instructions <NUM> to be used to download second recovery image <NUM>. Recovery agent <NUM> downloads second recovery image <NUM> in data chunks where the size of each data chunk is based on the chunk size. For example, the chunk size may be <NUM> bytes. When the chunk size is determined, recovery agent <NUM> begins to download second recovery image <NUM> by requesting data chunks of second recovery image <NUM> from server <NUM>.

In response to receiving the request, server <NUM> may transmit the data chunks in sequence. For example, server <NUM> may transmit a first data chunk <NUM> to recovery agent <NUM>. In response to receiving first data chunk <NUM>, recovery agent <NUM> transmits first data chunk <NUM> to firmware instructions <NUM>. Firmware instructions <NUM><NUM> validate first data chunk <NUM>. In some examples, firmware instructions <NUM> may validate first data chunk <NUM> using hash values.

In response to a determination that first data chunk <NUM> is valid, firmware instructions <NUM> may acknowledge to recovery agent <NUM> that firmware instructions <NUM> has accepted first data chunk <NUM>. Also, firmware instructions <NUM><NUM> stores first data chunk <NUM> in third storage device <NUM>. In some examples, third storage device <NUM> may only be accessible by firmware instructions <NUM>. OS <NUM> may not be able to access third storage device <NUM>. Thus, data stored in third storage device <NUM> (e.g., first data chunk <NUM>) may be less likely to be comprised if OS <NUM> is comprised. In response to receiving an acknowledgement associated with first data chunk <NUM> from firmware instructions <NUM>, recovery agent <NUM> begins to download a second data chunk <NUM> of second recovery image <NUM> from server <NUM>. In response to a determination that first data chunk <NUM> is invalid, firmware instructions <NUM> may reject first data chunk <NUM>. Recovery agent <NUM> may download first data chunk <NUM> again when firmware instructions <NUM> reject first data chunk <NUM>.

During a recovery operation to repair or replace OS <NUM>, firmware instructions <NUM> may delete first recovery image <NUM> and construct second recovery image <NUM> in third storage device <NUM> using all the data chunks of second recovery image <NUM> (e.g., first data chunk <NUM> and second data chunk <NUM>). When second recovery image <NUM> is constructed, firmware instructions <NUM> may discard all the data chunks of second recovery image <NUM>. In some examples, before firmware instructions <NUM> are to construct second recovery image <NUM>, firmware instructions <NUM> may validate all the data chunks again. When all the data chunks are validated, firmware instructions <NUM> may construct second recovery image <NUM> and use second recovery image <NUM> to repair and/or replace OS <NUM>.

By downloading second recovery image <NUM> in data chunks and storing the data chunks in third storage device <NUM> directly, a reserved partition in second storage device <NUM> for recovery image storage may be avoided. Thus, more storage space in second storage device <NUM> may be available for use by a user of computing device <NUM>. Further, a reboot of computing device <NUM> may be avoided during the recovery operation as second recovery image <NUM> is not copied from second storage device <NUM> to third storage device <NUM>.

<FIG> illustrates message and data exchanges between recovery agent <NUM> of computing device <NUM> of <FIG> and firmware instructions <NUM> of computing device <NUM> during a recovery image download operation, according to an example.

In response to a determination that recovery agent <NUM> is to download a recovery image, such as second recovery image <NUM>, from server <NUM>, recovery agent <NUM> transmits a chunk size request <NUM> to firmware instructions <NUM>. In response to receiving chunk size request <NUM>, firmware instructions <NUM> determines a chunk size <NUM>. In some examples, chunk size <NUM> may be fixed and stored in computing device <NUM> (e.g., in first storage device <NUM>). Firmware instructions <NUM> may retrieve chunk size <NUM> and transmit chunk size <NUM> to recovery agent <NUM>.

Firmware instructions <NUM> determines chunk size <NUM> dynamically based on chunk size request <NUM>. That is, firmware instructions <NUM> may determine a distinct chunk size for each chunk size request. Chunk size request <NUM> includes a size of second recovery image <NUM>, a quality of a network connection at computing device <NUM>, a utilization percentage of processor <NUM>, or a combination thereof. It should be understood that chunk size request <NUM> may include any other information that is indicative of a workload on computing device <NUM>.

Using the information in chunk size request <NUM>, firmware instructions <NUM> may calculate chunk size <NUM> such that downloading the data chunks may have minimal impact to the performance of computing device <NUM>. For example, instead of setting chunk size <NUM> to a larger unit (e.g., in megabytes) for a shorter download process, firmware instructions <NUM> may set chunk size <NUM> to a smaller unit (e.g., in bytes) when computing device <NUM> is under a heavy workload and/or the network connection has low bandwidth. When computing device <NUM> has a light workload and/or the network connection has high bandwidth, firmware instructions <NUM> may set chunk size <NUM> to a larger unit.

When chunk size <NUM> is determined, firmware instructions <NUM> transmits chunk size <NUM> to recovery agent <NUM>. Recovery agent <NUM> begins to download second recovery image <NUM> in data chunks from server <NUM>. Each data chunk has a size that corresponds to chunk size <NUM>. Recovery agent <NUM> transmits first data chunk <NUM> to firmware instructions <NUM> when recovery agent <NUM> receives first data chunk <NUM> from server <NUM>.

When firmware instructions <NUM> successfully validate first data chunk <NUM>, firmware instructions <NUM> transmits an acknowledgement <NUM> associated with first data chunk <NUM> to recovery agent <NUM>. Firmware instructions <NUM> store first data chunk <NUM> in third storage device <NUM>, as described in <FIG>. Acknowledgement <NUM> may indicate to recovery agent <NUM> that firmware instructions <NUM> have accepted first data chunk <NUM>. In response to receiving acknowledgement <NUM>, recovery agent <NUM> downloads the next data chunk (e.g., second data chunk <NUM>) from server <NUM>, then transmit second data chunk <NUM> to firmware instructions <NUM>. Firmware instructions <NUM> may process second data chunk <NUM> in the same manner as first data chunk <NUM>.

When firmware instructions <NUM> are not able to successfully validate first data chunk <NUM>, firmware instructions <NUM> may transmit an error message <NUM> associated with first data chunk <NUM> to recovery agent <NUM>. Error message <NUM> may indicate that firmware instructions <NUM> have rejected first data chunk <NUM>. In response to receiving error message <NUM>, recovery agent <NUM> may download first data chunk <NUM> again from server <NUM> to repeat the process.

When firmware instructions <NUM> have received and accepted all the data chunks of second recovery image <NUM>, firmware instructions <NUM> may transmit a termination message <NUM> to recovery agent <NUM> to indicate that the download of second recovery image <NUM> has finished. In response to receiving termination message <NUM>, recovery agent <NUM> may terminate the download process with server <NUM>.

<FIG> illustrates a method <NUM> of operation at a computing device to download a recovery image via data chunks, according to an example. Method <NUM> may be implemented by recovery agent <NUM> of <FIG>.

At <NUM>, recovery agent <NUM> may determine if a recovery image update condition has been satisfied. For example, recovery agent <NUM> may compare first recovery image <NUM> to second recovery image <NUM>. if first recovery image <NUM> is older than second recovery image <NUM>, then recovery agent <NUM> may determine that the recovery image update condition has been satisfied. At <NUM>, in response to a determination that the recovery image update condition has been satisfied, recovery agent <NUM> may request chunk size <NUM> from firmware instructions <NUM>. Recovery agent <NUM> transmits chunk size request <NUM> to firmware instructions <NUM> to request chunk size <NUM>.

At <NUM>, recovery agent <NUM> downloads a data chunk from server <NUM> based on chunk size <NUM>. Recovery agent <NUM> downloads first data chunk <NUM> of second recovery image <NUM> from server <NUM>. At <NUM>, recovery agent <NUM> transmits first data chunk <NUM> to firmware instructions <NUM>. At <NUM>, recovery agent <NUM> may determine if first data chunk <NUM> has been accepted by firmware instructions <NUM>. Recovery agent <NUM> receives acknowledgement <NUM> from firmware instructions <NUM> when first data chunk <NUM> has been accepted. Recovery agent <NUM> may receive error message <NUM> from firmware instructions <NUM> when first data chunk has been rejected.

When first data chunk <NUM> has been rejected, recovery agent <NUM> may download first data chunk <NUM> from server <NUM> again. When first data chunk <NUM> has been accepted, recovery agent <NUM> may determine if termination message <NUM> has been received, at <NUM>. Recovery agent <NUM> may terminate the download process of second recovery image <NUM> when termination message <NUM> has been received. When recovery agent <NUM> has not received termination message <NUM>, recovery agent <NUM> may download the next data chunk (e.g., second data chunk <NUM>) of second recovery image <NUM> from server <NUM>, at <NUM>.

<FIG> illustrates a method <NUM> of operation at a computing device to download a recovery image via data chunks, according to another example. Method <NUM> may be implemented by firmware instructions <NUM> of <FIG>.

At <NUM>, firmware instructions <NUM> receive chunk size request <NUM> from recovery agent <NUM>. At <NUM>, firmware instructions <NUM> determine chunk size <NUM> based on chunk size request <NUM>. In some examples, chunk size <NUM> may be fixed and may be stored in third storage device <NUM>. Thus, firmware instructions <NUM> may retrieve the fixed chunk size <NUM> in response to receiving chunk size request <NUM>. Chunk size <NUM> is computed based on information in chunk size request <NUM>. Chunk size request <NUM> includes information that is indicative of workload of computing device <NUM>, firmware instructions <NUM> computing chunk size <NUM> based on the workload.

At <NUM>, firmware instructions <NUM> transmit chunk size <NUM> to recovery agent <NUM>. At <NUM>, firmware instructions <NUM> receive a data chunk, such as first data chunk <NUM>, from recovery agent <NUM>. At <NUM>, firmware instructions <NUM> validate first data chunk <NUM> to determine if first data chunk <NUM> is to be accepted. Firmware instructions <NUM> may accept first data chunk <NUM> when first data chunk <NUM> is successfully validated. For example, firmware instructions <NUM> may successfully validate first data chunk <NUM> when a hash value of first data chunk <NUM> matches an expected hash value. First data chunk <NUM> may fail the validation when the hash value does not match the expected hash value.

At <NUM>, when firmware instructions <NUM> reject first data chunk <NUM>, firmware instructions <NUM> may transmit error message <NUM> to recovery agent <NUM> to indicate that first data chunk <NUM> has been rejected. At <NUM>, when firmware instructions <NUM> accept first data chunk <NUM>, firmware instructions <NUM> store first data chunk <NUM> in third storage device <NUM>. At <NUM>, firmware instructions <NUM> transmit acknowledgement <NUM> to recovery agent <NUM> to indicate that first data chunk <NUM> has been accepted.

At <NUM>, firmware instructions <NUM> may determine if more data chunks are to come from recovery agent <NUM>. For example, recovery agent <NUM> may get the size of second recovery image <NUM> from server <NUM>. Recovery agent <NUM> may include the size of second recovery image <NUM> in chunk size request <NUM>. Firmware instructions <NUM> may compute the number of data chunks based on the size of second recovery image <NUM>. Firmware instructions <NUM> may count the number of accepted data chunks to determine if more data chunks are to come from recovery agent <NUM>. When more data chunks are expected, firmware instructions <NUM> may wait for the next data chunk from recovery agent <NUM>.

At <NUM>, when firmware instructions <NUM> determines that the last data chunk has been accepted, firmware instructions <NUM> may transmit termination message <NUM> to recovery agent <NUM> to indicate all data chunks of second recovery image <NUM> have been received and accepted. Thus, recovery agent <NUM> may terminate the download process of second recovery image <NUM>.

<FIG> illustrates a computing device <NUM> to download a recovery image via data chunks, according to an example. Computing device <NUM> may implement computing device <NUM> of <FIG>. Computing device <NUM> may include a processor <NUM> and a computer-readable storage medium <NUM>.

Processor <NUM> may be a central processing unit (CPU), a semiconductor-based microprocessor, and/or other hardware devices suitable for retrieval and execution of instructions stored in computer-readable storage medium <NUM>. Processor <NUM> may fetch, decode, and execute instructions <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> to download a recovery image from a server, such as server <NUM>. As an alternative or in addition to retrieving and executing instructions, processor <NUM> may include at least one electronic circuit that includes electronic components for performing the functionality of instructions <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or a combination thereof.

Computer-readable storage medium <NUM> may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, computer-readable storage medium <NUM> may be, for example, Random Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, etc. In some examples, storage medium <NUM> may be a non-transitory storage medium, where the term "non-transitory" does not encompass transitory propagating signals. Computer-readable storage medium <NUM> may be encoded with a series of processor executable instructions <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>.

Chunk size determination instructions <NUM> determine chunk size <NUM>. Referring to <FIG>, firmware instructions <NUM> determine chunk size <NUM>. Chunk size transmitting instructions <NUM> transmit the chunk size from firmware instructions <NUM> to recovery agent <NUM>. Referring to <FIG>, firmware instructions <NUM> transmit chunk size <NUM> to recovery agent <NUM>. Data chunk receiving instructions <NUM> receive data chunks from recovery agent <NUM>. Referring to <FIG>, firmware instructions <NUM> receive first data chunk <NUM> from recovery agent <NUM>.

Data chunk storing instructions <NUM> store received data chunks in a storage device. Referring to <FIG>, firmware instructions <NUM> store first data chunk <NUM> in third storage device <NUM>. Recovery image constructing instructions <NUM> construct a recovery image using data chunks. Referring to <FIG>, firmware instructions <NUM> construct second recovery image <NUM> in third storage device <NUM> using all the data chunks of second recovery image <NUM> (e.g., first data chunk <NUM> and second data chunk <NUM>).

<FIG> illustrates computing device <NUM> to download a recovery image via data chunks, according to another example. In addition to encoded with instructions <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, computer-readable storage medium <NUM> may also be encoded with instructions <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>.

Data chunk validation instructions <NUM> validate each received data chunk, such as first data chunk <NUM> and second data chunk <NUM>. Referring to <FIG>, firmware instructions <NUM> validate first data chunk <NUM>. Acknowledgement transmitting instructions <NUM> transmit an acknowledgement to recovery agent <NUM>. For example, referring to <FIG>, when firmware instructions <NUM> successfully validate first data chunk <NUM>, firmware instructions <NUM> may transmit acknowledgement <NUM> to recovery agent <NUM>.

Error message transmitting instructions <NUM> may transmit an error message to recovery agent <NUM>. For example, referring to <FIG>, when firmware instructions <NUM> are not able to successfully validate first data chunk <NUM>, firmware instructions <NUM> may transmit an error message <NUM> to recovery agent <NUM>.

Termination message transmitting instructions <NUM> may transmit termination message <NUM> to recovery agent <NUM>. For example, referring to <FIG>, when firmware instructions <NUM> have received and accepted all the data chunks of second recovery image <NUM>, firmware instructions <NUM> may transmit termination message <NUM> to recovery agent <NUM> to indicate that the download of second recovery image <NUM> has finished. Data chunk discarding instructions <NUM> may discard all the data chunks stored in third storage device <NUM> after second recovery image <NUM> is constructed in third storage device <NUM>. For example, referring to <FIG>, when second recovery image <NUM> is constructed, firmware instructions <NUM> may discard all the data chunks of second recovery image <NUM>.

<FIG> illustrates a computing device <NUM> to download a recovery image via data chunks, according to another example. Computing device <NUM> may implement computing device <NUM> of <FIG>. Computing device <NUM> may include processor <NUM> and a computer-readable storage medium <NUM>. Computer-readable storage medium <NUM> may be similar to computer-readable storage medium <NUM>.

Computer-readable storage medium <NUM> may be encoded with instructions <NUM>, <NUM>, and <NUM>. In some examples, computer-readable storage medium <NUM> may also be encoded with instructions <NUM>. Chunk size request instructions <NUM> transmit chunk size request <NUM> to firmware instructions <NUM>. Referring to <FIG>, recovery agent <NUM> may transmit chunk size request <NUM> to firmware instructions <NUM>. Data chunk downloading instructions <NUM> download data chunks from server <NUM>. Referring to <FIG>, recovery agent <NUM> downloads data chunks <NUM> and <NUM> from server <NUM>.

Data chunk transmitting instructions <NUM> transmit data chunks to firmware instructions <NUM>. Referring to <FIG>, recovery agent <NUM> transmits data chunks <NUM> and <NUM> to firmware instructions <NUM>. Data chunk download termination instructions <NUM> may terminate a download process of a recovery image, such as second recovery image <NUM>. For example, referring to <FIG>, in response to receiving termination message <NUM>, recovery agent <NUM> may terminate the download process with server <NUM>.

Claim 1:
A non-transitory computer-readable storage medium (<NUM>, <NUM>) comprising instructions that when executed cause a processor (<NUM>, <NUM>) of a computing device (<NUM>, <NUM>) to:
in response to receiving a chunk size request from a recovery agent (<NUM>) executable at an operating system (<NUM>) in a second storage device (<NUM>) of the computing device (<NUM>, <NUM>), dynamically determine a chunk size via firmware instructions (<NUM>) in a first storage device (<NUM>) of the computing device (<NUM>, <NUM>);
transmit the chunk size from the firmware instructions (<NUM>) in the first storage device (<NUM>) to the recovery agent (<NUM>) in the second storage device (<NUM>);
receive data chunks (<NUM>, <NUM>) of a recovery image from the recovery agent (<NUM>) in the second storage device (<NUM>) in sequence and validate the data chunks (<NUM>);
store the data chunks (<NUM>, <NUM>) in a third storage device (<NUM>) of the computing device (<NUM>, <NUM>); and
construct the recovery image using the data chunks (<NUM>, <NUM>) ;
wherein the chunk size is determined based on a utilization percentage of the processor (<NUM>, <NUM>), a quality of a network connection, a size of the recovery image, or a combination thereof.