Optimized file storage policies to improve availability of key files

Abstract

An information handling system includes a storage device and a processor. The storage device stores a key file in a partition of the storage device. The processor receives a request for the key file and determines whether the key file is located within the partition of the storage device. In response to the key file not being within the partition of the storage device, the processor retrieves metadata of the key file. The processor determines a physical location of the key file based on the metadata. Based on the physical location, the processor retrieves a segment of the key file from the partition of the storage device. The processor downloads a segment of the key file from a back-end server. The processor recreates the key file based on the segment of the key file retrieved from the partition of the storage device and based on the segment of the key file downloaded from the backend server.

Description

Technical Field

[0001] The present disclosure relates generally to information handling systems, and more particularly to an optimized file storage strategy for improving the availability of key files. Background Art

[0002] As the value and use of information continues to grow, individuals and businesses seek additional ways to process and store information.

[0003] One option is an information handling system. An information handling system typically processes, compiles, stores or transmits information or data for commercial, personal or other purposes. Technology and information handling needs and requirements may vary between different applications. Therefore, information handling systems may also differ in terms of what information is handled, how the information is handled, how much information is processed, stored or transmitted, and how quickly and efficiently the information can be processed, stored or transmitted. The variation of information handling systems allows information handling systems to be general or configured for specific users or specific purposes (such as financial transaction processing, airline booking, enterprise data storage or global communications). In addition, an information handling system may include a variety of hardware and software resources that can be configured to process, store and transmit information, and may include one or more computer systems, graphic interface systems, data storage systems, networking systems and mobile communication systems. Information handling systems may also implement various virtualization architectures. Data and voice communications in information handling systems may be carried out via a network, which may be wired, wireless or a combination thereof. Summary of the invention

[0004] An information handling system includes a storage device that can store a key file in a partition of the storage device. A processor can receive a request for the key file and determine whether the key file is located in a partition of the storage device. In response to the key file not being in a partition of the storage device, the processor can retrieve metadata for the key file. The processor can determine a physical location of the key file based on the metadata. Based on the physical location, the processor can retrieve one or more fragments of the key file from the partition of the storage device. The processor can download one or more fragments of the key file from a backend server. The processor can recreate the key file based on the fragments of the key file retrieved from the partition of the storage device and based on the fragments of the key file downloaded from the backend server. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] It should be understood that for simplicity and clarity of illustration, the elements shown in the figures are not necessarily drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements. Embodiments incorporating the teachings of the present disclosure are shown and described with respect to the drawings herein, in which:

[0006] Figure 1 is a block diagram of a portion of an information handling system according to at least one embodiment of the present disclosure;

[0007] Figure 2 is a flowchart of a method for improving the availability of key files by optimizing file storage strategies according to at least one embodiment of the present disclosure; and

[0008] Figure 3 is a block diagram of a general information handling system according to an embodiment of the present disclosure.

[0009] The use of the same reference numbers in different drawings indicates similar or identical items. DETAILED DESCRIPTION

[0010] The following description in conjunction with the accompanying drawings is provided to help understand the teaching disclosed herein. The description focuses on the specific implementation and implementation of the teaching and is provided to help describe the teaching. This focus should not be interpreted as limiting the scope or applicability of the teaching.

[0011] Figure 1A portion of an information handling system 100 according to at least one embodiment of the present disclosure is shown. For purposes of the present disclosure, an information handling system may include any tool or collection of tools operable to calculate, compute, determine, classify, process, transmit, receive, retrieve, initiate, switch, store, display, transmit, indicate, detect, record, reproduce, process, or utilize any form of information, intelligence, or data for commercial, scientific, control, entertainment, or other purposes. For example, an information handling system may be a personal computer (such as a desktop computer or laptop computer), a tablet computer, a mobile device (such as a personal digital assistant (PDA) or a smart phone), a server (such as a blade server or a rack server), a network storage device, or any other suitable device, and may vary in size, shape, performance, functionality, and price. An information handling system may include random access memory (RAM), one or more processing resources (such as a central processing unit (CPU) or hardware or software control logic), ROM, and / or other types of non-volatile memory. Additional components of an information handling system may include one or more disk drives, one or more network ports for communicating with external devices, and various input and output (I / O) devices (such as a keyboard, mouse, touch screen, and / or video display). The information handling system may also include one or more buses operable to transmit communications between the various hardware components.

[0012] Information handling system 100 includes non-volatile random access memory (NVRAM) 102, processor 104, and storage device 106. Processor 104 may execute one or more sets of code, including, but not limited to, recovery code 110. Processor 104 may communicate with NVRAM storage device 102 and storage device 106 to recover key file 120, as will be described herein. Information handling system 100 may include any suitable number of additional components or information handling systems without departing from the scope of the present disclosure.

[0013] In an example, key files may be very important for system boot operations, system recovery operations, and hardware driver recovery operations. These key files may be installed during factory installation operations. In some examples, these key files may be deleted by individuals associated with the information handling system during actions including, but not limited to, formatting and partition re-layout. Individuals may not know which features are affected by deleting these key files. When individuals want to use related features, these features may not be available because the key files are lost. The information handling system 100 can be improved by the processor 104 storing metadata of the key file 120 in the NVRAM 102. When the metadata of the large key file is stored in the NVRAM 102, the information handling system 100 can be further improved. The information handling system 100 can also be improved by the processor 104 using persistent metadata to improve the availability of the key file 120 via the remaining raw data 142 in the storage device 106.

[0014] During operation of the information handling system 100, the processor 104 may save metadata 130 associated with one or more key files 120 in the NVRAM storage device 102. In an example, the processor 104 may store the metadata 130 in the NVRAM storage device 102 during an initial boot of the information handling system 100, during a manufacturing process of the information handling system, etc. As used herein, a key file refers to a recovery image file of the information handling system 100.

[0015] In an example, the processor 104 may perform one or more suitable operations to store the metadata 130 in the NVRAM storage device 102. For example, the processor 104 may receive an entry in a master file table (MFT) 140, and the entry number may be identified by a value such as $MFT. Based on the entry number, a file record having information associated with the key file 120 may be retrieved from the MFT 140. The processor 104 may use the information to determine a file size and a virtual cluster number (VCN) of the key file 120. In an example, the VCN may identify a file status location of the key file 120 within the storage device 106. The processor 104 may map the VCN to a logical cluster number (LCN) of the key file 120 and obtain raw data 142 of the key file from the storage device 106.

[0016] In an example, the processor 104 may calculate a checksum of the raw data 142 of the key file 120. In some examples, the processor 104 may store metadata 130 of the key file 120 in the NVRAM 102. In an example, the metadata 130 may include, but is not limited to, a file name, an LCN of a starting location, an ending location, and a checksum of the key file 120. In some examples, the NVRAM storage 102 may be a reserved memory space within the BIOS of the information handling system 100, and the processor 104 may access the NVRAM space via an NVRAM input / output (I / O) interface.

[0017] In some examples, an individual associated with the information handling system 100 may cause the processor 104 to perform a quick format, partition re-layout, etc. of the storage device 106. During the quick format, partition re-layout, etc., the processor 104 may clean up the original MFT 140, and the metadata 130 of the key file 120 may be erased or lost. In this case, the file original data 142 may remain in the cluster of the storage device 106. In some examples, most of the original data 142 of the key file 120 may be overwritten, but some of the original data of the small key file and the portion of the large key file may be recovered. For example, when the recovery tool 110 needs to use the key files to restore the information handling system 100 after the key files are cleaned, the processor 104 may use the metadata to restore the key files, as described in more detail below.

[0018] In an example, the key file 120 may be an operating system (OS) recovery image file. In this example, the processor 104 may utilize the recovery tool 110 to access the OS recovery image file to enable an individual of the information handling system 100 to recover the system. In some examples, the key file 120, such as the OS recovery image file, may be stored locally in the storage device 106, in the back-end server 150, or in both the storage device and the back-end server. The amount of recovery time may differ based on the size of the key file 120 and whether the key file is retrieved from the storage device 106 or the back-end server 150. For example, if a recovery image, such as the key file 120, is available in the storage device 106, the amount of time used to recover is reduced by the amount of download time to retrieve the key file from the back-end server 150. This recovery time difference may be a significant improvement for the information handling system 100.

[0019] In some examples, the processor 104 may determine the size of the key file 120. Based on the size of the key file 120, the processor 104 may split the key file into multiple segments to increase the probability that the original data 142 of the key file 120 can be recovered when the MFT 140 is erased. In an example, as the size of the key file 120 increases, the processor 104 may increase the number of segments into which the key file is split. For example, if the key file 120 is approximately 8 GB, the processor 104 may split the key file into approximately 100 segments and store the segments as the original data 142 in the storage device 106. If the key file 120 is approximately 4 GB, the processor 104 may split the key file into approximately 50 segments and store the segments as the original data 142 in the storage device 106. In an example, if the storage device 106 is erased during a quick format, partition re-layout, etc., the larger the number of segments, the higher the probability that the original data 142 can be recovered.

[0020] In some examples, the NVRAM storage device 102 may store only a small amount of data, so that a small amount of metadata 130 may be stored in the NVRAM storage device. This small amount of metadata 130 may be used to obtain the original data 142 of the key file 120 from the storage device 106. In an example, the metadata 130 may also be divided into multiple segments and these separate segments may be stored in the NVRAM storage device 102.

[0021] During system recovery, the processor 104 may execute the recovery tool 110 and attempt to utilize the key file 120, such as an OS recovery image, to perform system recovery. Before the processor 104 utilizes the original data 142 of the key file 120, such as an OS recovery image, the processor may determine whether all fragments of the original data are located within the storage device 106. For example, the processor 104 may retrieve the metadata 130 of the key file 120 from the NVRAM storage device 102 and utilize the metadata to determine the entries in the MFT 140 of the key file. The processor 104 may then utilize the information in the MFT 140 to determine the file size and VCN of the key file 120. Based on the VCN, the processor 104 may determine the LCN of the key file 120 and retrieve any original data 142 of the key file that still remains in the storage device 106.

[0022] In an example, the processor 104 may determine which segments, if any, of the raw data 142 of the key file 120 are lost or damaged. Based on the determined lost or damaged segments of the raw data 142, the processor 104 may download these segments of the raw data from the backend server 150. The processor 104 may combine the downloaded segments with the segments of the raw data 142 retained in the storage device 106 to recreate the entire key file 120. In an example, the processor 104 only needs to download a subset of the segments of the raw data 142, such as the lost or damaged segments, which may significantly reduce the download time compared to downloading the entire large key file 120 from the backend server 150. In this example, system recovery of the information handling system 100 may be improved based on the metadata 130 in the NVRAM storage device 102 and the multiple raw data segments 142 in the storage device 106 of the key file 120.

[0023] In a specific example, the key file 120 may be a wireless fidelity (WIFI) driver for a universal serial bus (USB) key for the information handling system 100. In some examples, a recovery USB key may be created based on a service tag for a particular platform of the information handling system 100. However, the recovery USB key may not be used for every platform of the information handling system because the WIFI driver key file 120 may be different for different information handling system platforms.

[0024] In an example, if the raw data 142 of the WIFI driver key file 120 is not stored in the storage device 106, cloud-based features such as cloud reset, self-update, etc. may not be utilized in the information handling system 100. In this example, a specific WIFI driver key file 120 associated with the platform of the information handling system 100 may be stored in the storage device 106 during the factory installation process. When the information handling system 100 boots into WinRE, the USB key may utilize the WIFI driver key file 120. During WinRE operation, if the raw data 142 of the WIFI driver key file 120 is located in the storage device 106, the WIFI key file may be used directly. If all of the raw data 142 of the WIFI driver key file 120 is not located in the storage device 106, the processor 104 may retrieve the metadata 130 of the WIFI driver key file from the NVRAM storage device 102. Based on the retrieved metadata 130, the processor 140 may determine the segments of the raw data 142 located in the storage device 106 and download the missing segments from the backend server 150. In response to retrieving the missing fragments from the backend server 150 , the processor 104 may create the entire WIFI driver key file 120 so that the USB key may properly execute the cloud-based features of WinRE.

[0025] In another example, the BIOS key file 120 may be utilized by the BIOS UEFI of the information handling system 100 to perform BIOS recovery. In this case, multiple segments of the raw data 142 of the BIOS key file 120 may be stored in the storage device 106, and the corresponding metadata 130 of the BIOS key file may be stored in the NVRAM storage device 106. The BIOS UEFI may utilize the metadata 130, the raw data 142, and substantially similar operations described above to restore the BIOS key file 120 before performing BIOS recovery.

[0026] Figure 2 is a flow chart of a method 200 for improving the availability of key files by optimizing file storage strategies according to at least one embodiment of the present disclosure, the method starting at block 202. In one example, the method 200 may include, but is not limited to, Figure 1 It should be readily understood that not every method step set forth in the flowchart is always necessary, but rather that certain steps of the method may be combined, performed simultaneously, performed in a different order, or may be omitted without departing from the scope of the present disclosure.

[0027] At box 204, a key file request is received. In an example, the key file request may be received in response to any suitable event in the information handling system. The event may include, but is not limited to, an OS system recovery, a BIOS recovery, and a WinRE operation. At box 206, a determination is made as to whether the key file exists in a partition of the storage device. If the key file exists, the key file is used for recovery at box 208, and the process ends at box 210. If the key file does not exist, the key file metadata is retrieved from the NVRAM of the information handling system at box 212.

[0028] At block 214, the physical location of the key file is retrieved from the metadata. In an example, the metadata can be used to determine an entry in the MFT of the key file. The information in the MFT can then be used to determine the file size and VCN of the key file. Based on the VCN, the processor can determine the LCN or physical location of the key file in the storage device of the information handling system.

[0029] Based on the physical location, the key file raw data is retrieved from the storage device at box 216. In an example, any raw data of the key file lost from the storage device can be downloaded from the back-end server, and a complete key file can be created based on the raw data in the storage device and the raw data downloaded from the back-end server. At box 218, the checksum is retrieved from the metadata. In an example, the checksum of the key file can be part of the metadata. At box 220, it is determined whether the checksum has been verified. If the checksum is verified, the key file is used for recovery at box 208, and the process ends at box 210. If the checksum is not verified, it is determined at box 222 that the key file cannot be used, and the process ends at box 210.

[0030] Figure 3 A generalized embodiment of an information handling system 300 according to an embodiment of the present disclosure is shown. For the purposes of the present disclosure, an information handling system may include any tool or tool set operable to calculate, classify, process, transmit, receive, retrieve, generate, switch, store, display, indicate, detect, record, reproduce, handle or utilize any form of information, intelligence or data for commercial, scientific, control, entertainment or other purposes. For example, the information handling system 300 may be a personal computer, a laptop computer, a smart phone, a tablet device or other consumer electronic device, a network server, a network storage device, a switch, a router or another network communication device, or any other suitable device, and may vary in size, shape, performance, functionality and price. In addition, the information handling system 300 may include processing resources for executing machine executable code, such as a central processing unit (CPU), a programmable logic array (PLA), an embedded device such as a system on a chip (SoC), or other control logic hardware. The information handling system 300 may also include one or more computer-readable media for storing machine executable code such as software or data. Additional components of information handling system 300 may include one or more storage devices that can store machine-executable code, one or more communication ports for communicating with external devices, and various input and output (I / O) devices such as a keyboard, a mouse, and a video display. Information handling system 300 may also include one or more buses operable to transfer information between the various hardware components.

[0031] Information handling system 300 may include devices or modules that embody one or more of the following devices or modules, and operate to perform one or more of the following methods. Information handling system 300 includes processors 302 and 304, input / output (I / O) interface 310, memory 320 and 325, graphics interface 330, basic input and output system / universal extensible firmware interface (BIOS / UEFI) module 340, disk controller 350, hard disk drive (HDD) 354, optical disk drive (ODD) 356, disk emulator 360 connected to external solid state drive (SSD) 362, I / O bridge 370, one or more extended resources 374, trusted platform module (TPM) 376, network interface 380, management device 390, and power supply 395. Processors 302 and 304, I / O interface 310, memory 320, graphics interface 330, BIOS / UEFI module 340, disk controller 350, HDD 354, ODD 356, disk emulator 360, SSD 362, I / O bridge 370, extension resource 374, TPM 376, and network interface 380 operate together to provide a host environment for information handling system 300, which operates to provide the data processing functionality of the information handling system. The host environment operates to execute machine executable code, including platform BIOS / UEFI code, device firmware, operating system code, application programs, programs, etc., to perform data processing tasks associated with information handling system 300.

[0032] In a host environment, processor 302 is connected to I / O interface 310 via processor interface 306, and processor 304 is connected to I / O interface via processor interface 308. Memory 320 is connected to processor 302 via memory interface 322. Memory 325 is connected to processor 304 via memory interface 327. Graphics interface 330 is connected to I / O interface 310 via graphics interface 332 and provides video display output 336 to video display 334. In a particular embodiment, information handling system 300 includes separate memories dedicated to each of processors 302 and 304 via separate memory interfaces. Examples of memories 320 and 330 include random access memory (RAM), such as static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NV-RAM), etc., read-only memory (ROM), another type of memory, or a combination thereof.

[0033] The BIOS / UEFI module 340, the disk controller 350, and the I / O bridge 370 are connected to the I / O interface 310 via an I / O channel 312. Examples of the I / O channel 312 include a peripheral component interconnect (PCI) interface, a PCI-Extension (PCI-X) interface, a high-speed PCI-Express (PCIe) interface, another industry standard or proprietary communication interface, or a combination thereof. The I / O interface 310 may also include one or more other I / O interfaces, including an Industry Standard Architecture (ISA) interface, a Small Computer Serial Interface (SCSI) interface, an Inter-Integrated Circuit (IIC) interface, and a SCSI interface. 2 C) interface, system packet interface (SPI), universal serial bus (USB), another interface, or a combination thereof. BIOS / UEFI module 340 includes BIOS / UEFI code that is operable to detect resources within information handling system 300, provide drivers for resources, initialize resources, and access resources. BIOS / UEFI module 340 includes code that is operable to detect resources within information handling system 300, provide drivers for resources, initialize resources, and access resources.

[0034] The disk controller 350 includes a disk interface 352 that connects the disk controller to the HDD 354, the ODD 356, and the disk emulator 360. Examples of the disk interface 352 include an integrated drive electronics (IDE) interface, an advanced technology attachment (ATA) such as a parallel ATA (PATA) interface or a serial ATA (SATA) interface, a SCSI interface, a USB interface, a proprietary interface, or a combination thereof. The disk emulator 360 allows the SSD 364 to be connected to the information handling system 300 via the external interface 362. Examples of the external interface 362 include a USB interface, an IEEE 3394 (Firewire) interface, a proprietary interface, or a combination thereof. Alternatively, the solid state drive 364 can be disposed within the information handling system 300.

[0035] I / O bridge 370 includes a peripheral interface 372 that connects the I / O bridge to an extended resource 374, a TPM 376, and a network interface 380. Peripheral interface 372 may be an interface of the same type as I / O channel 312, or may be an interface of a different type. Thus, when peripheral interface 372 and I / O channel 312 are of the same type, I / O bridge 370 extends the capabilities of the I / O channel, and when they are of different types, the I / O bridge converts information from a format suitable for the I / O channel to a format suitable for peripheral bridge 372. Extended resource 374 may include a data storage system, an additional graphics interface, a network interface card (NIC), a sound / video processing card, another extended resource, or a combination thereof. Extended resource 374 may be located on a main circuit board, on a separate circuit board or expansion card disposed within information handling system 300, on a device external to the information handling system, or a combination thereof.

[0036] The network interface 380 represents a NIC that is disposed within the information handling system 300, located on the main circuit board of the information handling system, integrated into another component such as the I / O interface 310, located in another suitable location, or a combination thereof. The network interface device 380 includes network channels 382 and 384 that provide interfaces to devices outside the information handling system 300. In a specific embodiment, the network channels 382 and 384 are of different types from the peripheral channels 372, and the network interface 380 converts information from a format suitable for the peripheral channels to a format suitable for the external device. Examples of network channels 382 and 384 include InfiniBand channels, fiber channel channels, Gigabit Ethernet channels, proprietary channel architectures, or a combination thereof. Network channels 382 and 384 can be connected to external network resources (not shown). Network resources can include another information handling system, a data storage system, another network, a grid management system, another suitable resource, or a combination thereof.

[0037] Management device 390 represents one or more processing devices that operate together to provide a management environment for information handling system 300, such as a dedicated baseboard management controller (BMC) system-on-chip (SoC) device, one or more associated memory devices, one or more network interface devices, complex programmable logic devices (CPLD), etc. Specifically, management device 390 is connected to various components of the host environment via various internal communication interfaces (such as low pin count (LPC) interface, inter-integrated circuit (I2C) interface, PCIe interface, etc.) to provide an out-of-band (OOB) mechanism to retrieve information related to the operation of the host environment, provide BIOS / UEFI or system firmware updates, and manage non-processing components of information handling system 300, such as system cooling fans and power supplies. Management device 390 may include a network connection to an external management system, and the management device may communicate with the management system to report status information of information handling system 300, receive BIOS / UEFI or system firmware updates, or perform other tasks for managing and controlling the operation of information handling system 300.

[0038] The management device 390 may operate off a separate power plane from the components of the host environment, such that the management device receives power to manage the information handling system 300 when the information handling system is otherwise shut down. Examples of the management device 390 include commercially available BMC products or other devices that operate in accordance with the Intelligent Platform Management Initiative (IPMI) specification, the Web Services Management (WSMan) interface, the Redfish application programming interface (API), another Distributed Management Task Force (DMTF), or other management standards, and may include an integrated Dell Remote Access Controller (iDRAC), an embedded controller (EC), etc. The management device 390 may also include associated memory devices, logic devices, security devices, etc., as needed or desired.

[0039] Although only a few exemplary embodiments are described in detail herein, those skilled in the art will readily appreciate that many modifications may be made to the exemplary embodiments without materially departing from the novel teachings and advantages of the embodiments of the present disclosure. Therefore, all such modifications are intended to be included within the scope of the embodiments of the present disclosure as defined by the appended claims. In the claims, means-plus-function clauses are intended to cover structures described herein as performing the recited function, and not only structural equivalents, but also equivalent structures.

Claims

1. An information processing system, comprising: a storage device configured to store the key file in a partition of the storage device; as well as A processor, the processor communicating with the storage device, the processor: receiving a request for the key file; determining whether the key file is located in the partition of the storage device; In response to the key file not being in the partition of the storage device, the processor: Retrieving metadata of the key file; determining a physical location of the key file based on the metadata; retrieving one or more segments of the key file from the partition of the storage device based on the physical location; Downloading one or more fragments of the key file from a backend server; as well as The key file is recreated based on the fragment of the key file retrieved from the partition of the storage device and based on the fragment of the key file downloaded from the backend server.

2. The information handling system of claim 1, wherein the processor further: Determining whether a checksum of the key file is verified; In response to the checksum of the key file being verified, performing system recovery using the key file; and In response to the checksum of the key file not being verified, it is determined that the key file cannot be used to perform the system recovery.

3. The information handling system of claim 1 , wherein to determine the physical location of the key file, the processor further: Based on the metadata, determining an entry in a master file table associated with the key file; and Based on the entry in the master file, a virtual cluster number of a key file and a logical cluster number of the key file are determined.

4. The information handling system of claim 1 , wherein before receiving the request for the key file, the processor further: Splitting the key file into a plurality of segments; and The segments are stored in the partitions of the storage device.

5. The information handling system of claim 1, wherein the request for the key file is associated with a system recovery of the information handling system.

6. The information handling system of claim 1, wherein it is determined that the key file is not located within the partition of the storage device based on one or more fragments of the key file not being located within the partition of the storage device.

7. The information handling system of claim 1, wherein the metadata is stored in non-volatile random access memory.

8. The information handling system of claim 1, wherein in response to the key file being located in the partition of the storage device, the processor further: utilizes the key file to perform system recovery of the information handling system.

9. A method comprising: Receiving, by a processor, a request for a key file; Determining whether the key file is located in a partition of a storage device; as well as In response to the key file not being within the partition of the storage device: Retrieving metadata of the key file; determining a physical location of the key file based on the metadata; retrieving one or more segments of the key file from the partition of the storage device based on the physical location; Downloading one or more fragments of the key file from a backend server; as well as The key file is recreated based on the fragment of the key file retrieved from the partition of the storage device and based on the fragment of the key file downloaded from the backend server.

10. The method according to claim 9, wherein the method further comprises: If the checksum of the key file is verified, performing system recovery using the key file; as well as If the checksum is not verified, it is determined that the key file cannot be used to perform the system recovery.

11. The method of claim 9, wherein to determine the physical location of the key file, the method further comprises: Based on the metadata, determining an entry in a master file table associated with the key file; as well as Based on the entry in the master file, a virtual cluster number of a key file and a logical cluster number of the key file are determined.

12. The method of claim 9, wherein before receiving the request for the key file, the method further comprises: Splitting the key file into a plurality of segments; as well as The segments are stored in the partitions of the storage device.

13. The method of claim 9, wherein the request for the key file is associated with a system recovery of an information handling system.

14. The method of claim 9, wherein determining that the key file is not located within the partition of the storage device is based on one or more fragments of the key file not being located within the partition of the storage device.

15. The method of claim 9, wherein the metadata is stored in non-volatile random access memory.

16. The method of claim 9, wherein in response to the key file being located within the partition of the storage device, utilizing the key file to perform a system recovery of an information handling system.

17. A method comprising: Split the key file into multiple fragments; storing the plurality of segments in partitions of a storage device; Receiving, by a processor of an information handling system, a request for the key file; If the key file is not located in the partition of the storage device, then: Retrieving metadata of the key file; determining a physical location of the key file based on the metadata; retrieving one or more segments of the key file from the partition of the storage device based on the physical location; Downloading one or more fragments of the key file from a backend server; recreating the key file based on the fragment of the key file retrieved from the partition of the storage device and based on the fragment of the key file downloaded from the backend server; If the checksum of the key file is verified, the key file is used to perform system recovery, otherwise it is determined that the key file cannot be used to perform system recovery.

18. The method of claim 17, wherein determining that the key file is not located within the partition of the storage device is based on one or more fragments of the key file not being located within the partition of the storage device.

19. The method of claim 17, wherein the request for the key file is associated with a system recovery of the information handling system.

20. The method of claim 17, wherein in response to the key file being located within the partition of the storage device, utilizing the key file to perform a system recovery of the information handling system.

Images