Method, apparatus and computer program product for recovering objects in storage system

Abstract

The embodiment of the invention relates to a method, equipment and a computer program product for recovering an object in a storage system. A method for recovering an object in a storage system according to an embodiment of the present disclosure includes parsing object metadata associated with an object from a log of the storage system, and storing the parsed object metadata in a storage space. The method also includes receiving a request to restore the object, and in response to receiving the request, retrieving the parsed object metadata from the storage space. The method further includes reconstructing a link to a block corresponding to the object based on the retrieved object metadata. In this manner, it is possible to improve space utilization without affecting space recovery during recovery for the object. In addition, the time spent in the recovery process is shortened, and the recovery success rate of the object is improved.

Description

Technical Field

[0001] Embodiments of the present disclosure relate generally to the field of storage, and more particularly to methods, apparatus, and computer program products for restoring objects in a storage system. Background Art

[0002] Object storage is an architecture and technology for storing data. Different from traditional block storage and file storage, object storage uses objects as the basic storage unit. Each object has a unique identifier (for example, a globally unique URL) and contains the data itself and the metadata associated with it.

[0003] Object storage has been widely used in data-intensive scenarios such as cloud storage, big data analysis, backup and archiving. Object storage can store and manage massive amounts of unstructured data such as images, audio, video, text, etc. in an efficient, reliable and scalable manner. Summary of the invention

[0004] An embodiment of the present disclosure provides a solution for restoring an object in a storage system.

[0005] In a first aspect of the present disclosure, a method for recovering an object in a storage system is provided, the method comprising: parsing object metadata associated with the object from a log of the storage system; storing the parsed object metadata in a storage space; receiving a request for recovering the object; retrieving the parsed object metadata from the storage space in response to receiving the request; and rebuilding a link to a block corresponding to the object based on the retrieved object metadata.

[0006] In another aspect of the present disclosure, a device for recovering an object in a storage system is provided, the device comprising a processor, and a memory coupled to the processor and having instructions stored thereon, which, when executed by the processor, cause the device to perform the following actions: parsing object metadata associated with the object from a log of the storage system; storing the parsed object metadata in a storage space; receiving a request for recovering the object; retrieving the parsed object metadata from the storage space in response to receiving the request; and rebuilding a link to a block corresponding to the object based on the retrieved object metadata.

[0007] In another aspect of the present disclosure, a computer program product is provided, which is tangibly stored on a non-transitory computer-readable storage medium and includes computer-executable instructions, which, when executed, cause a computer to perform a method or process according to an embodiment of the present disclosure.

[0008] Please note that the invention summary is provided to introduce a series of concepts in a simplified form, which will be further described in the detailed description below. The invention summary is not intended to identify key features or essential features of the present disclosure, nor is it intended to limit the scope of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The above and other purposes, features and advantages of the present disclosure will become more clearly understood by describing the embodiments of the present disclosure in more detail in conjunction with the accompanying drawings, in which:

[0010] Figure 1 A schematic diagram illustrating an example object storage system in which methods and / or processes according to embodiments of the present disclosure may be implemented;

[0011] Figure 2 A flowchart of a method for restoring an object in a storage system according to an embodiment of the present disclosure is illustrated;

[0012] Figure 3 is a timing diagram illustrating a time range for object recovery according to an embodiment of the present disclosure;

[0013] Figure 4 is a schematic diagram illustrating metadata overhead according to an embodiment of the present disclosure;

[0014] Figure 5 is a diagram illustrating a parsing process for metadata update according to an embodiment of the present disclosure;

[0015] Figure 6 is a diagram illustrating a distributed arrangement of logs according to an embodiment of the present disclosure;

[0016] Figure 7 is a diagram illustrating a recovery process for an object according to an embodiment of the present disclosure;

[0017] Figure 8 is a timing diagram illustrating the reconstruction of a link to a tile according to an embodiment of the present disclosure; and

[0018] Fig. 9 Schematic block diagram of an example device that may be used to implement embodiments according to the present disclosure.

[0019] Throughout the drawings, same or similar reference numbers generally refer to same or similar elements. Specific embodiments

[0020] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments set forth herein. On the contrary, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0021] In the description of the embodiments of the present disclosure, the term "including" and its variations should be understood as open inclusion, that is, "including but not limited to". The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc. may refer to different or the same objects, unless explicitly indicated to be different.

[0022] Compared with traditional storage, object storage can better meet the storage and management needs of large-scale, distributed and unstructured data, and has the advantages of elastic expansion, simplified management, high availability, high performance and low cost. However, the use of object storage also brings some problems. For example, some current object storage systems do not have a recycle bin design, so deletion operations cannot be undone. Below, we will further introduce these problems in the form of examples.

[0023] In some examples, space reclamation needs to be completely suspended for weeks or months during traditional object recovery. The reason behind this is that during space reclamation, the original data of the chunk will be permanently deleted. In the case where the original data of the chunk is deleted, the objects on the chunk will be unrecoverable. For users with high capacity utilization, since space reclamation is disabled for a long time, it will lead to disadvantages such as wasted storage space and increased storage costs.

[0024] In other examples, the traditional recovery process relies on historical log parsing and is based on a list provided by the user. When this list is updated, there is no logic to continue or resume log parsing. As a result, when such a list is updated, the recovery work needs to start from scratch, which means that the log parsing results cannot be reused. In addition, the more time the recovery process takes, the less chance there is to save the data, because the blocks will be recycled in the background.

[0025] In summary, traditional object storage systems do not have a recycle bin design, and when an object is deleted, the system marks the object as deleted and compresses the previous updates. Historical object update entries can be found in the log. Before recycling the block, the object can be restored at the metadata level and the historical object updates can be appended (ie, overwritten), but this is very time-consuming.

[0026] In order to solve at least some of the above and other potential problems, an embodiment of the present disclosure proposes a solution for recovering objects in a storage system. The solution includes parsing object metadata associated with the object from a log of the storage system, and storing the parsed object metadata in a storage space. The solution also includes receiving a request for recovering the object, and retrieving the parsed object metadata from the storage space in response to receiving the request. The solution also includes rebuilding a link to a block corresponding to the object based on the retrieved object metadata. In this way, space recovery can be unaffected during the recovery of the object, thereby improving space utilization. In addition, the time spent in the recovery process is reduced, and the success rate of object recovery is improved.

[0027] Reference below Figures 1 to 9 It should be understood that these exemplary embodiments are provided only to enable those skilled in the art to better understand and implement the embodiments of the present disclosure, and are not intended to limit the scope of the present disclosure in any way.

[0028] Figure 1 A schematic diagram of an exemplary object storage system 100 in which the methods and / or processes according to embodiments of the present disclosure may be implemented is shown. Unless otherwise specified, the abbreviation "storage system" or "system" hereinafter refers to the object storage system. Figure 1 The storage architecture of the object storage system 100 and the data storage mechanism therein are further described in detail.

[0029] The object storage system 100 according to an embodiment of the present disclosure can be configured to abstract data into objects for storage, management, etc. The object storage system 100 uses a specific method for disk capacity management, which is almost independent of the file system, and all disk space is divided into a set of larger blocks of fixed size, called blocks. All user data is stored in blocks. A block may contain data segments of several objects. From a low-level perspective, an object is usually represented as a set of data segments stored in different blocks.

[0030] like Figure 1 As shown in FIG. 1 , an object 110 abstracted from user data corresponds to data segments (shown in shaded portions) respectively stored in blocks 121, 122, and 123, wherein these blocks 121, 122, and 123 correspond to underlying physical storage devices 131, 132, and 133. The underlying physical storage devices 131, 132, and 133 (e.g., HDDs or SSDs) may be deployed locally or in a distributed manner in the cloud.

[0031] For ease of illustration and explanation, Figure 1Although described with one object (ie, object 110 ), the object storage system 100 can of course also perform operations (such as storage and management) on a greater number of objects. Figure 1 It is exemplarily shown that the data segments corresponding to object 110 are stored in three blocks (i.e., blocks 121, 122, and 123), but this is not restrictive, and the data segments corresponding to object 110 can be stored in a greater or lesser number of blocks, and the arrangement of these data segments in each block (e.g., their size, position, etc.) can be specifically set depending on various factors (e.g., capacity). Figure 1 The correspondence between the object and the block and between the block and the underlying physical storage device (shown by arrows) is also exemplary, and other different correspondences may exist between them. In addition, the types of the underlying physical storage devices may be the same or different, and the embodiments of the present disclosure do not limit this.

[0032] In addition, the metadata of the objects of the object storage system 100 indicates a 1:1 mapping between the objects and the blocks. The object storage system 100 also uses index compression to compress object updates into indexes. As a result, when an object is deleted after index compression, the previous updates will be stripped away, only limited information will be retained, and the object-block mapping details will be lost. By way of example and not limitation, the metadata information of the objects of the object storage system 100 can be stored in an internal storage space, such as an object target table (OB DT), which is part of the object table key.

[0033] The object storage system 100 can be log-based and append-only, i.e., it cannot be directly modified or deleted. All user operations are first written to the log (also called log record) in an append-only manner, and these logs are written to the disk in the form of three mirror blocks. These log blocks can be used to retrieve object updates.

[0034] Combined with the above Figure 1 A schematic diagram of an example environment 100 is depicted in which methods and / or processes according to embodiments of the present disclosure may be implemented. Figure 2 A flowchart of a method 200 for restoring an object in a storage system 100 according to an embodiment of the present disclosure is described. In order to overcome the above-mentioned shortcomings in the prior art and further improve the object recovery mechanism, this instant metadata-level recovery method is proposed.

[0035] At block 210, object metadata associated with the object is parsed from the log of the storage system 100. According to an embodiment of the present disclosure, the parsing process precedes the recovery process. In other words, the metadata associated with the object is parsed from the log in advance (e.g., at a predetermined frequency such as once a day, once a week, etc.), and whenever there is a need to recover the object, the object metadata corresponding to it can be directly found. In some embodiments, the parsed object metadata may include object metadata updates indicating operations on the object, etc.

[0036] At box 220, the parsed object metadata is stored in a storage space. Before recovery of the object, the object metadata parsed from the log is stored in a quickly retrievable storage space for object recovery, such as a hash storage space and a tree storage space. The hash storage space and the tree storage space are storage spaces organized in data structures such as hash tables or binary trees, and provide time complexities of O(1) and O(logN), respectively. In this way, according to an embodiment of the present disclosure, there is no need to stop space reclamation during recovery of the object.

[0037] In some embodiments, the storage space may be in the storage system 100 or another storage system different from the storage system 100. The storage space storing the object metadata parsed from the log may be configured in the storage system 100 that performs recovery for the object. In some embodiments, there may always be some reserved space in the object storage system 100 for storing the parsed object metadata. In addition, such storage space may be configured in another different storage system to improve data reliability and reduce operation conflicts.

[0038] At block 230, a request for restoring an object is received. Such a restore request may be sent by a user, or may be initiated autonomously by the system, for example, in the event that a reference to an object-block is lost. In some embodiments, such a request may include an object list indicating objects to be restored, and retrieval or filtering conditions for those objects.

[0039] At block 240, in response to receiving the request, the parsed object metadata is retrieved from the storage space. Before performing recovery for the object, the required object metadata has been parsed from the log in advance and stored in a dedicated storage space. Therefore, when performing recovery for the object, the object metadata corresponding to the object to be recovered can be directly retrieved from the storage space without parsing the entire log from scratch, which is very time-consuming.

[0040] At block 250, based on the retrieved object metadata, the link to the block corresponding to the object is rebuilt. Due to the asynchronous design of the object storage system 100, when an object is deleted, it does not mean that the deleted object is unrecoverable. Based on the object metadata associated with the object to be restored directly retrieved from the storage space, the link to the block corresponding to the target object can be rebuilt. From the user's perspective, the object can be restored.

[0041] By using the method 200 for recovering an object in the storage system 100 according to an embodiment of the present disclosure, other services or operations of the storage system, such as space recovery, can be not affected during the recovery of the object. In addition, the time spent in the recovery process is reduced, thereby improving the recovery success rate of the object. In the following, object recovery according to an embodiment of the present disclosure will be further described in detail.

[0042] Figure 3 3 is a timing diagram 300 illustrating the time range of object recovery according to an embodiment of the present disclosure. As described above, the object storage system 100 according to an embodiment of the present disclosure is log-based and append-only. When an object is deleted, it does not necessarily mean that the deleted object is unrecoverable. This is due to the asynchronous nature of the object storage system 100, which causes a delay between client operations (e.g., deletion) and system operations (object metadata index compression and block clearing). Figure 3 Such asynchronous mechanisms are described in further detail.

[0043] like Figure 3 As shown in , at time t1, the user issues an instruction 310 to delete an object, and the object is deleted. At time t2, in response to the object being deleted, its object metadata is updated. At this time, the original data on the disk corresponding to the deleted object is not actually cleared. In other words, from t1 to t2, only the pointing relationship from the object metadata of the deleted object to the original data on the disk corresponding to the deleted object is deleted, and the object can be restored as long as the pointing relationship is retrieved. However, at t3, the original data on the disk is cleared in response to the system's recycling mechanism, and at this time, the object can no longer be restored.

[0044] According to an embodiment of the present disclosure, in the case where the object to be restored is a deleted object, in response to receiving a request for restoring the object, it can be determined whether the current time is between the first time when the deleted object is deleted and the second time when the block corresponding to the deleted object is reclaimed. Recovery of the deleted object can be performed based on determining that the current time is between the first time and the second time. In addition, based on determining that the current time is after the second time, an indication that recovery is not possible can be returned. In this way, the recovery operation can be performed based on the time range of object recovery to avoid unnecessary waste of computing power. It should be noted that in the case where the object to be restored is another type of object, the operation of determining the time range or interval is the same or similar to that described above and will not be repeated here.

[0045] As described above, the object metadata parsed in advance from the log may include object metadata updates, which indicate operations on the object, etc. By way of example, the object metadata update may indicate that the object is created, modified, deleted, restored, etc., and the time corresponding to these operations, etc. At the same time, the object metadata update may also identify the object and its corresponding user data segment.

[0046] Furthermore, according to an embodiment of the present disclosure, the storage consumption of object metadata update (hereinafter, also referred to as object update for short) may be further optimized, wherein the storage consumption is based on the storage device type. Figure 4 4 is a schematic diagram 400 illustrating metadata overhead according to an embodiment of the present disclosure, which shows the results of laboratory testing. Figure 4 To describe the storage consumption strategy according to an embodiment of the present disclosure.

[0047] like Figure 4 As shown in FIG. 400 , the horizontal axis of the diagram 400 shows the object size (in KB), and the vertical axis shows the metadata overhead / object size, which indicates the metadata overhead. Curve 410 refers to a lower version system, curve 420 refers to a higher version system, and curve 410 refers to a higher version system. The straight line 401 with an arrow indicates that the object size here is 10KB. From Figure 4 It can be seen that the ratios of metadata overhead / object size at 401 of the different versions of the system indicated by curves 410, 420 and 430 are all unsatisfactory or undesirable.

[0048] However, from Figure 4 It can also be observed that if the object size is larger than 128KB, the metadata overhead / object size will be in a relatively good range. Based on lab testing, the compressed object metadata updates are about 815 bytes, so it is planned to merge these compressed object metadata updates into larger files to avoid unnecessary metadata headers.

[0049] According to an embodiment of the present disclosure, object metadata updates can be compressed into update objects. The parsed object metadata updates can be converted into compressed update objects (also referred to as data objects) that contain only necessary information of the object, which reduces the capacity overhead of recovery.

[0050] By way of example and not limitation, in the case of, for example, 1,000,000 object metadata updates, the size of each object metadata update after compression is, for example, about 815 bytes. If 200 object updates are merged into 1 object and uploaded to the object storage system 100, only, for example, 15.81 MB is required. If 1,000,000 object metadata updates are uploaded directly, for example, 2.8621 GB is required, resulting in most of the capacity consumption being occupied by metadata overhead, which is to be avoided.

[0051] According to an embodiment of the present disclosure, an update object may be stored in a storage space and managed with a retention policy indicating that the update object is retained for a predetermined period of time and is deleted in response to expiration of the predetermined period of time.

[0052] Retention policies can also be configured for backup data to further improve overhead. For example, object metadata updates can be stored in a bucket of the object storage system 100 via the S3 protocol. When no longer needed, they can be deleted and standard space reclamation procedures are followed. More policy configurations according to embodiments of the present disclosure will be described below.

[0053] The policy configuration according to the embodiment of the present disclosure may include system policy and user policy. The system policy is also referred to as the system configuration, which describes the operation of the background. The system policy may specify a backup storage space for storing object metadata, that is, the storage space for storing object metadata parsed from the log described above. Such a backup storage space may be an external storage space or an internal storage space. And it may be used to support reading and writing object metadata to be retained. In addition, the system policy may specify access details.

[0054] According to an embodiment of the present disclosure, the system policy may also provide a scheduler configured to control the frequency at which other components of the system run at configurable time intervals. In some embodiments, based on the system policy, a frequency for updating object metadata parsed from logs may be determined, and object metadata parsed from logs may be updated at the determined frequency, for example, by a restorer or other component. It should be noted that the scheduler and restorer described herein may be business-based and may be implemented by a processor executing executable program code stored in a memory, or may be a hardware component, which is not limited by the embodiments of the present disclosure. Below, the operation of the restorer will be described in further detail.

[0055] The policy is also called user configuration, which describes the target object metadata to be filtered and processed and saved to the backup storage space. In other words, it indicates the filtering conditions for the target object metadata. In some embodiments, the user policy can indicate at least one of the following: replication group information, namespace, bucket name, object name, default metadata key and value, or custom metadata key and value.

[0056] In some embodiments, the conditions indicated by the user policy can be grouped. For example, policy set A may include "bucket name: fruit" and "object name: apple", and policy set B may include "replication group: color", "bucket name: green", and "object name: grass". Figure 5 The process of how metadata updates are parsed from the log and stored in advance is described in further detail.

[0057] Figure 5 is a diagram illustrating a parsing process 500 for metadata updates according to an embodiment of the present disclosure. As described above, since the system is log-based, operations on objects will be recorded in logs, such as logs in block form. According to an embodiment of the present disclosure, in response to operations on objects, new object metadata updates 510 will be recorded in log blocks 520 of the object storage system 100. In this way, historical object metadata update entries can be found in the log.

[0058] According to an embodiment of the present disclosure, logs can be distributed in local areas and remote areas. Figure 6 To describe the distributed layout of logs. Figure 6 6 is a diagram illustrating a distributed arrangement 600 of logs according to an embodiment of the present disclosure. Figure 6 As shown in , some log blocks are distributed in a local area (e.g., area A). The log blocks of area A distributed locally may include a local index repository (LIS) log block 610, which includes a LIS metadata log. In addition, some logs are distributed in a remote area (e.g., area B). The log blocks of area B distributed remotely may include a remote index storage block (RIS) log block 620, which includes a RIS metadata log.

[0059] Back to Figure 5 According to an embodiment of the present disclosure, for example, in response to a request for restoring an object, object metadata updates corresponding to the object to be restored may be parsed from log block 520 based on user policy 530, that is, Figure 5540. In some embodiments, the request may include a user policy 530 to indicate conditions for filtering objects from the log block 520. Thus, using the logging mechanism, log content filtering can be performed according to the filtering conditions defined in the user policy 530.

[0060] In the case where the above logs are distributed, according to an embodiment of the present disclosure, log entries that meet the user policy 530 can be filtered from both the local area and the remote area. The log entry may include a write type, a schema key, a timestamp, a log payload length, etc. It may also include several key details, such as object creation time, object bucket, object name, object namespace, object last modification time, etc.

[0061] According to an embodiment of the present disclosure, the parsed object metadata update 540 can be stored in the metadata bucket 550. When the filter conditions (one or more filter conditions or all filter conditions) are met, the log entry will be parsed and uploaded to the backup storage space. In the case where the storage space is a hash storage space, it can be stored in the metadata bucket 550 in the storage space. These log entries will be used in the recovery process. Figure 7 To describe the recovery process.

[0062] Figure 7 is a diagram illustrating a recovery process 700 for an object according to an embodiment of the present disclosure. The recovery process 700 for an object is based on an object table provided (e.g., by a user). The object table 710 may be included in a request for recovering an object and indicates the object to be recovered. For example, the object table 710 may include a bucket name and an object name information for finding previously stored object metadata updates. As shown above, the backup storage space may be pre-stored with object metadata updates parsed based on user policies.

[0063] In the case where the backup storage space is a hash storage space, the metadata bucket 550 may be pre-stored with the parsed object metadata updates. After receiving the object table 710, the restorer 720 according to an embodiment of the present disclosure may retrieve the object metadata updates associated with the object to be restored from the metadata bucket 550. The retrieved object metadata updates associated with the object to be restored may be inserted into the user bucket 730 by the restorer 720 to cover the historical object metadata updates, thereby achieving object recovery.

[0064] According to an embodiment of the present disclosure, in response to the object table 710 being updated, for example, the number of objects to be restored is increased (i.e., there are new objects that need to be restored), the log can be parsed only once based on the checkpoint to obtain updated object metadata updates. The parsing process can be based on user policies. The checkpoint can indicate the parsing history, such as the progress of the last parsed log, so that when the next parsing is performed, it can start directly from the checkpoint without starting from the beginning. In addition, the backup storage space has stored a certain amount of parsed object metadata updates, so even if the object table 710 is updated, parsing the log only once is sufficient to obtain updated object metadata updates. It should be noted that the checkpoint mechanism can be introduced in each parsing in the log parsing according to the embodiment of the present disclosure not only when the object table 710 is updated, but also in each parsing according to the embodiment of the present disclosure, so as to improve time and computing power costs.

[0065] Figure 8 8 is a timing diagram 800 illustrating the reconstruction of a link to a block according to an embodiment of the present disclosure. Figure 8 As shown in , object metadata update 1 810 may indicate that an object is created, and based on object metadata update 1 810, for example, blocks A, B, and C corresponding to the object are linked together, and data segments of the object are stored on blocks A, B, and C.

[0066] exist Figure 8 At the next time shown in , object metadata update 2 820 may indicate that the object is deleted. At this point, the object is marked as deleted, the object-block reference is deleted, and blocks A, B, and C are waiting to be reclaimed. Before blocks A, B, and C are reclaimed, there is still a chance to recover the object.

[0067] The object metadata update 3 830 may indicate that the object is restored. The retrieved object metadata update 3 830 will overwrite the historical metadata update, and the object-chunk reference may be rebuilt based on the object metadata update 3 830. Figure 8 As shown in , the links to chunks A, B, and C are rebuilt. When the links to the chunks corresponding to the object are re-added, the object can be considered recovered.

[0068] According to an embodiment of the present disclosure, the recovery of an object can be verified, and based on the result of the recovery of the object, a report indicating whether the object has been recovered can be generated. Such a verification mechanism can verify whether the object has been successfully recovered and provide a verification report for recording, such as being recorded in a log.

[0069] According to an embodiment of the present disclosure, an instant object metadata level recovery is provided. Through the technical solution of the embodiment of the present disclosure, the object metadata can be parsed from the log in advance and safely stored in the backup storage space, so that the log parsing result can be reused. In this way, it is possible to not affect space recovery during the recovery of the object, thereby improving the space utilization rate. In addition, the time spent on the recovery process is reduced, and the success rate of object recovery is improved.

[0070] Fig. 9 900 is a schematic block diagram of an example device that can be used to implement some embodiments of the present disclosure. Fig. 9 As shown in FIG. 1 , the device 900 includes a central processing unit (CPU) 901, which can perform various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) 902 or loaded from a storage unit 908 into a random access memory (RAM) 903. In the RAM 903, various programs and data required for the operation of the device 900 can also be stored. The CPU 901, the ROM 902, and the RAM 903 are connected to each other via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0071] A number of components in the device 900 are connected to the I / O interface 905, including: an input unit 906, such as a keyboard, a mouse, etc.; an output unit 907, such as various types of displays, speakers, etc.; a storage unit 908, such as a disk, an optical disk, etc.; and a communication unit 909, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 909 allows the device 900 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0072] The various processes and processing described above, such as method 200, may be performed by processing unit 901. For example, in some embodiments, method 200 may be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 908. In some embodiments, part or all of the computer program may be loaded and / or installed on device 900 via ROM 902 and / or communication unit 909. When the computer program is loaded into RAM 903 and executed by CPU 901, one or more actions of method 200 described above may be performed.

[0073] The present disclosure may be a method, a device, an apparatus, a system, and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for executing various aspects of the present disclosure.

[0074] Computer readable storage medium can be a tangible device that can hold and store instructions used by an instruction execution device. Computer readable storage medium can be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. More specific examples (non-exhaustive lists) of computer readable storage medium include: portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), static random access memories (SRAM), portable compact disk read-only memories (CD-ROM), digital versatile disks (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or convex structures in grooves on which instructions are stored, and any suitable combination thereof. Computer readable storage medium used herein is not interpreted as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (e.g., light pulses by optical fiber cables), or electrical signals transmitted by wires.

[0075] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in the computer-readable storage medium in each computing / processing device.

[0076] The computer program instructions for performing the operation of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages, such as Smalltalk, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. Computer-readable program instructions may be executed completely on a user's computer, partially on a user's computer, as an independent software package, partially on a user's computer, partially on a remote computer, or completely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider to connect via the Internet). In some embodiments, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be customized by utilizing the state information of the computer-readable program instructions, and the electronic circuit may execute the computer-readable program instructions, thereby realizing various aspects of the present disclosure.

[0077] Various aspects of the present disclosure are described herein with reference to flowcharts and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of boxes in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0078] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processing unit of the computer or other programmable data processing device, a device that implements the functions / actions specified in one or more boxes in the flowchart and / or block diagram is generated. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable medium storing the instructions includes a manufactured product, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0079] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operating steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0080] The flow chart and block diagram in the accompanying drawings show the possible architecture, function and operation of the system, method and computer program product according to multiple embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and a part of the module, program segment or instruction includes one or more executable instructions for realizing the specified logical function. In some alternative implementations, the function marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous square boxes can actually be executed substantially in parallel, and they can sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or action, or can be implemented with a combination of special hardware and computer instructions.

[0081] The embodiments of the present disclosure are described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A method for restoring an object in a storage system, comprising: parsing object metadata associated with the object from a log of the storage system; storing the parsed object metadata in a storage space; receiving a request to restore the object; In response to receiving the request, retrieving the parsed object metadata from the storage space; as well as Based on the retrieved object metadata, a link to the block corresponding to the object is reconstructed.

2. The method according to claim 1, wherein the object is a deleted object, the method further comprising: In response to receiving the request, determining whether a current time is between a first time when the deleted object is deleted and a second time when the block corresponding to the deleted object is reclaimed; Based on determining that the current time is between the first time and the second time, performing recovery for the deleted object; as well as Based on determining that the current time is after the second time, an indication of non-recoverability is returned.

3. The method of claim 1 , wherein the object metadata comprises an object metadata update indicating an operation on the object, and wherein: The object metadata updates are compressed into update objects, which are stored in the storage space and managed with a retention policy indicating that the update objects are retained for a predetermined period of time and deleted in response to expiration of the predetermined period of time.

4. The method of claim 3, wherein the object metadata updates are parsed from the log comprising: Based on a system policy, determining a frequency for parsing metadata updates of the object from the log; as well as The object metadata updates are parsed from the log at the determined frequency.

5. The method according to claim 4, wherein the log is distributed in a local area and a remote area, and parsing the object metadata update from the log comprises: Log entries satisfying a user policy are filtered from both the local zone and the remote zone.

6. The method of claim 5, wherein the user policy indicates at least one of the following: Copy group information; Namespace; Bucket name; Object name; Default metadata keys and values; or Custom metadata keys and values.

7. The method according to claim 5, wherein the storage space is a hash storage space, the method further comprising: retrieving the object metadata updates associated with the object from a metadata bucket in the hash storage space based on an object table included in the request indicating the object to be restored; as well as The object metadata update is inserted into the user bucket to overwrite the historical object metadata update.

8. The method according to claim 7, further comprising: In response to the object table being updated, the log is parsed only once to obtain updated object metadata updates based on a checkpoint identifying a parsing history.

9. The method according to claim 1, wherein: The storage space is in the storage system or another storage system different from the storage system.

10. The method according to claim 1, further comprising: verifying recovery of the object; as well as Based on the result of the recovery for the object, a report is generated indicating whether the object is recovered.

11. An electronic device, comprising: processor; as well as A memory, the memory being coupled to the processor and storing instructions, which, when executed by the processor, cause the device to perform actions, the actions comprising: parsing object metadata associated with the object from a log of the storage system; storing the parsed object metadata in a storage space; receiving a request to restore the object; In response to receiving the request, retrieving the parsed object metadata from the storage space; and Based on the retrieved object metadata, a link to the block corresponding to the object is reconstructed.

12. The apparatus according to claim 11, wherein the object is a deleted object, and the action further comprises: In response to receiving the request, determining whether a current time is between a first time when the deleted object is deleted and a second time when the block corresponding to the deleted object is reclaimed; Based on determining that the current time is between the first time and the second time, performing recovery for the deleted object; as well as Based on determining that the current time is after the second time, an indication of non-recoverability is returned.

13. The apparatus of claim 11, wherein the object metadata comprises an object metadata update indicating an operation on the object, and wherein: The object metadata updates are compressed into update objects, which are stored in the storage space and managed with a retention policy indicating that the update objects are retained for a predetermined period of time and deleted in response to expiration of the predetermined period of time.

14. The apparatus of claim 13, wherein the object metadata updates are parsed from the log comprising: Based on a system policy, determining a frequency for parsing metadata updates of the object from the log; as well as The object metadata updates are parsed from the log at the determined frequency.

15. The device according to claim 14, wherein the log is distributed in a local area and a remote area, and parsing the object metadata update from the log comprises: Log entries satisfying a user policy are filtered from both the local zone and the remote zone.

16. The device of claim 15, wherein the user policy indicates at least one of the following: Copy group information; Namespace; Bucket name; Object name; Default metadata keys and values; or Custom metadata keys and values.

17. The device according to claim 15, wherein the storage space is a hash storage space, and the actions further include: retrieving the object metadata updates associated with the object from a metadata bucket in the hash storage space based on an object table included in the request indicating the object to be restored; as well as The object metadata update is inserted into the user bucket to overwrite the historical object metadata update.

18. The apparatus of claim 17, the actions further comprising: In response to the object table being updated, the log is parsed only once to obtain updated object metadata updates based on a checkpoint identifying a parsing history.

19. The apparatus of claim 11, the actions further comprising: verifying recovery of the object; as well as Based on the result of the recovery for the object, a report is generated indicating whether the object is recovered.

20. A computer program product tangibly stored on a non-transitory computer readable storage medium and comprising computer executable instructions that, when executed, cause a computer to: parsing object metadata associated with the object from a log of the storage system; storing the parsed object metadata in a storage space; receiving a request to restore the object; In response to receiving the request, retrieving the parsed object metadata from the storage space; as well as Based on the retrieved object metadata, a link to the block corresponding to the object is reconstructed.

Images