Patent ID: 12197296

DETAILED DESCRIPTION

The system described herein provides the ability to efficiently back up and restore files within a service, such as a network-based file hosting service or a collaboration service. The system is configured to improve file restoration (may also be referred to as recovery) that occurs in response to an event (may also be referred to as an incident) that compromises a tenant device on which the files reside, thereby preventing access to the files or corrupting the files that are available to the tenant. An example of an event includes a ransomware attack. As described above, the files may include documents, emails, spreadsheets, slide decks, executable files, images, videos.

FIG.1illustrates an example environment100in which a system102that composes part of a service104is able to back up and restore files within a service boundary106. More specifically, the system102stores mutable file metadata within a metadata database108and immutable file content within a blob store110.

The described system102backs up tenant files112and restores the tenant files112, as needed, within a boundary of the service106. The boundary of the service106is created based on a defined set of resources (e.g., processing resources, storage resources, network resources) that are dedicated to the service104. Therefore, the backup exposure to the tenant files112is limited to an operator of the service104that contains the set of defined resources and an owner of the tenant files112(e.g., the tenant users). Stated alternatively, the boundary of the service106separates the defined set of resources from (i) other resources that are operated by a different operator or (ii) or other resources that are dedicated to a different service (e.g., with different tenants). Therefore, as part of the backup process, the tenant files112never leave the boundary of the service106.

As described herein, by backing up and restoring the tenant files112internally within the service104, a tenant is no longer required to contract with a third-party backup service114to export116different versions of a file over a period of time (as illustrated via the X through the third-party backup service114). The conventional approach that uses the third-party backup service114stores the files externally, outside of the service boundary106. Storing the files externally requires the system102to export116the different versions of the file, outside the service104, to the third-party backup service114. Conventionally, in a scenario in which the tenant files112needs to be restored, the tenant of the service104relies on the third-party backup service114to import118a desired version of the file back into the service104, so the state of the file is returned to a non-compromised state.

Utilizing the third-party backup service114, as described above, increases the amount of time needed to restore a group of files for a tenant as the files must be communicated from the third-party backup service114to the service104. This increased amount of time often hinders a tenant's productivity and/or affects the tenant's operations, thereby reducing the tenant satisfaction with the service104. The described system102eliminates the need for the third-party backup service114, as illustrated.

Furthermore, by backing up and restoring files internally within the service104, the tenant of the service104is no longer required to configure additional file access control and protection mechanisms associated with the communications (e.g., the exportation116and the importation118) of the file for backup and restoration purposes using the third-party backup service114. Consequently, the management overhead is reduced for the tenant and the need to manage access in multiple domains is eliminated. For example, when files are transmitted over public networks to a new location, access control to the files must be managed independently in the new location and must be secured or encrypted during transit to maintain the original security and access control posture.

To efficiently implement the backup and restoration of tenant files112within the service boundary106, the system102described herein configures and uses a metadata database108and a binary large object (blob) store110. The metadata database108(e.g., an SQL database) is configured to store file metadata (e.g., access control lists (ACLs), owner of file, size of file, title of the file) in a mutable manner. Mutable means that the file metadata is subject to change or the backed-up version of metadata121is capable of being updated. Accordingly, only one version of the file metadata is stored in the metadata database108throughout the backup process for the tenant files112.

The blob store110is configured to store file content as a group of content objects in an immutable manner. Accordingly, a set of content objects are referred to herein as immutable content objects. An immutable content object is a discrete and self-contained unit of content within a larger context, such as a file (e.g., the file is divided into smaller content objects). In one example, the immutable content objects are referred to as blobs. Immutable means previous versions of the file content are never updated or changed as new versions of the file content are backed-up and stored. Rather, a new version of the file content is stored as a new set of immutable content objects, and thus, different versions of the same file are stored within the system102over a period of time, though the different versions of the same file may contain different file content.

The system102separates the storage of the file metadata and the file content to improve the efficiency with regard to backing up and restoring the tenant files112. The blob store110is a basic component that supports a limited number of operations. For instance, the blob store110may only support write, read, and delete operations related to a set of immutable content objects. Consequently, the blob store110is not configured to support a large number of query operations. Rather, the limited number of operations supported of the blob store110allows for faster storage and retrieval of files and cost efficiency.

In contrast to the blob store110, the metadata database108is configured to support more complex operations including various query operations Consequently, the metadata database108is more expensive to configure and operate. However, the file metadata amounts to an insignificant percentage of the total storage since the file content outweighs the metadata. Therefore, the backup and restore operations that copy and recall the state of the metadata at a particular point in time is extremely efficient.

The system102further includes a control plane application programming interface (API)120usable by the service104and/or the tenants to access the metadata database108and the blob store110. The control plane API120orchestrates the process for a file backup122(e.g., storing a tenant file112in the metadata database108and the blob store110). In one example, the control plane API120is usable to back up the tenant files112at various times in accordance with a predefined schedule124. In this example, the system102may set the predefined schedule124to every hour, every six hours, every day, every week, and so forth. In another example, the control plane API120is usable to back up the files when modifications125to the files occur. The control plane API120further orchestrates the process for retrieving information and restoring the tenant files112via the reception of a restoration request126that specifies a restore time128.

As part of the file backup process122, the system102captures a current version of a file130(e.g., a tenant file112) accessible to the tenant via a tenant device132. The current version of the file130includes current metadata134and current content136. As shown inFIG.1, the system102updates138the mutable version of the metadata140for the file that has already been backed-up and stored in the metadata database108based on previous versions of the file142. Furthermore, the system102stores the current content136of the current version of the file130in the blob store110as a new version of immutable content objects144. Due to the immutability of the blob store110, the new version of immutable content objects144is stored in addition to previous content146associated with the previous versions of the file142, stored as previous versions of immutable content objects148(1-N).

After the current metadata134of the file and the current content136of the file, as made available via the tenant device132, are backed up multiple times over a period of time as defined in the predefined schedule124, there may be an event150(e.g., a ransomware attack) that compromises the tenant device132thereby corrupting the tenant files112or preventing access to the tenant files112.

After the event150occurs, the tenant initiates the restoration request126and provides the restoration request126to the control plane API120of the system102. The tenant provides input that defines the restore time128that is known to occur before a time at which the event150starts, and the restore time128is specified in the restoration request126. Based on the restoration request126, the system102via the control plane API124retrieves, within the boundary106and via the metadata database108, the backed-up version of the metadata140for the file. The backed-up version of the metadata140includes timing information and references to a previous version of immutable content objects (one of148(1-N)), which are stored for a previous version of the file142associated with the restore time130such that the tenant file can be restored to a non-compromised state.

In one example, a ransomware attack occurs at 2:30 P.M. If the system102backs up a file at 8:00 A.M. and 3:00 P.M. there is a possibility that the backed-up version of the file at 3:00 P.M. is compromised as the system102continues to back up new versions of the file even after the ransomware attack. In order to restore the file to a non-compromised version, the immutable content objects148from the 8:00 A.M. backup are retrieved in response to the restoration request132(e.g., assuming the 8:00 A.M. backup time is the closest backup time before the ransomware attack occurs at 2:30 P.M.—as specified in the restore time128). The immutable content objects from the 8:00 A.M. backup is identified over the immutable content objects from the 3:00 P.M backup even though the 3:00 P.M. backup is closer in time to the occurrence of the ransomware attack at 2:30 P.M.

In various examples, the predefined schedule124for backing up the tenant files112can be implemented as part of a service policy that backs up a group of related files within a container (e.g., a specific site where files are stored for collaboration, a specific location that stores files for an authorized user). Accordingly, all the tenant files112stored within the container are backed up at the same time and this is referred to as a container-level backup.

The described system102is customizable to the needs of each tenant. For example, an operator of the service104and the tenant can compose a tenant agreement152(e.g., a service level agreement (SLA)) that defines a retention period154associated with a tenant's backup and restoration policy. The retention period154determines how long a backed-up version of a file exists within the blob store110. In one example, the retention period154for the tenant files112is flexible and can be negotiated with a tenant and defined in the tenant agreement152. In another example, the retention period154(e.g., one year) for the tenant files112is applied to the tenant agreement152as part of a general policy applicable to multiple different tenants. Upon reaching the end of the retention period154, an expired version of immutable objects is deleted from the blob store110and the file metadata140is updated to reflect the deletion (e.g., the timestamp associated with the deleted version of immutable objects is removed from the metadata). The tenant's backup and restoration policy (e.g., the retention period146) can be customized based on the needs of the industry within which the tenant operates.

Implementing the techniques described herein enable point in time restores (e.g., for files contained in a site, a storage box, an account) to occur with massive scale and at unparalleled speeds that are unachievable by the conventional techniques that use the third-party restoration service114configured outside the service boundary106. The techniques described herein also enable seamless integration with security and compliance features due to the fact that the tenant files112no longer need to be exported116and imported118with respect to the service boundary106.

FIG.2illustrates an example environment in which the system restores a tenant file by mapping a restore time128in the restoration request126to an identifiable non-compromised version of the file. As shown, in addition to the restore time the restoration request may include a file identification (ID)202, which identifies a specific tenant file112. In various examples, the file ID202may be included as part of a container-level ID204. Examples of the containers identifiable via the container-level ID204include sites and storage accounts. The system102uses the file ID202to access a backed-up version of the metadata206for a particular tenant file112, as stored in the metadata database108.

The system uses the restore time128to identify and/or locate reference(s) to a non-compromised version of the tenant file associated with the file ID202. For example, the system compares208the restore time128to a group of timestamps210associated with the backed-up versions of the file. The timestamps210correspond to the scheduled times at which the file content for file ID202is captured and backed-up in the blob store110. Stated alternatively, the backed-up version of metadata206for file ID202includes information that indicates a backup schedule and that maps to different sets of immutable content objects212(1-N) stored for different previous versions of the file.

Based on the comparison208, the system102is able to select the timestamp that is closest to the restore time128and before the restore time128such that the corresponding version of the file is guaranteed to be a non-compromised version of the file (e.g., not corrupted due to an event150). The selected timestamp is useable by the system102to identify214reference(s) to the non-compromised version of the file216.

As described above, previous versions of file content may be backed up despite being compromised. For example, the previous version of file content at time T3212(3) may have been backed up after the restore time128(e.g., after the compromising event150occurs), and thus, may be compromised. Regardless, the system102is still configured to store the version of file content at time T3212(3) as a set of immutable content objects in the blob store110. The reference to the non-compromised version of the file216retrieves218the previous version of file content at a time T2216(2) that is closes to the restore time128and before the restore time128. Consequently, the previous version of file content at time T2212(2) is not compromised because T2is a time before a time at which the compromising event150occurs. Accordingly,FIG.2illustrates that the previous version of file content at time T2216(2) is retrieved218and used to restore the file to a non-compromised version220(e.g., provide the non-compromised version of the file to the tenant device132).

In various examples, when restoring the files at the container-level (e.g., a collaboration site), the system102can flush the “bad” versions of the files so they no longer exist in the blob store110(e.g., the ones that have been affected by the ransomware). Consequently, the system102provides the benefit of a “roll back” to a prior point in time when the files are healthy.

FIG.3illustrates a diagram in which the control plane API120copies snapshots of the file metadata to the blob store to enable restoration of a tenant file. As shown, the mutable and backed-up version of the metadata140in the metadata database108includes timestamps302(1-N) associated with when different versions of the file content are stored in the blob store110(as captured inFIG.1via elements142,146, and148(1-N)). To help with restoring the file to a full fidelity version, the control plane API120copies304the mutable and backed-up version of the metadata140at the different times associated with the timestamps302(1-N) to the blob store110as metadata snapshots306(1-N). As shown, the metadata snapshots306(1-N) are associated with the different versions of immutable content objects148(1-N) for the file. Accordingly, a corresponding metadata snapshot can be accessed and retrieved based on the timestamp selected, as described above inFIG.2, and the corresponding metadata snapshot can be used to restore the previous version of the file associated with the restore time.

Turning now toFIG.4an example flow diagram400showing aspects of a method implemented to provide backing up and restoring files for a tenant of a service that contains a set of defined resources within a boundary such that backup exposure to the files is limited to an operator of the service that contains the set of defined resources and an owner of the data.

At operation402, the system captures current metadata of the current version of the file accessible to the tenant via a tenant device.

At operation404, the system captures current content of the current version of the file accessible to the tenant via the tenant device.

At operation406, the system updates, in the metadata database, the version of the metadata for the file based on the current metadata in the current version of the file.

At operation408, the system stores, in the blob store, the current content of the current version of the file as a new version of immutable content objects. The new version of immutable content objects is stored in addition to previous versions of immutable content objects stored for previous versions of the file. As described above, in one example operations402,404,406,408can be iteratively performed in accordance with the predefined schedule124. In another example, operations402,404,406,408are performed when a file is modified or edited.

At operation410, the system receives a request to restore the file, wherein the request includes a restore time.

Lastly, at operation412, the system responds to receiving the request, retrieving, within the boundary, the version of the metadata for the file and a reference to a previous version of immutable content objects stored for a previous version of the file associated with the restore time.

For ease of understanding, the method discussed in this disclosure are delineated as separate operations represented as independent blocks. However, these separately delineated operations should not be construed as necessarily order dependent in their performance. The order in which the method is described is not intended to be construed as a limitation, and any number of the described blocks may be combined in any order to implement the method or an alternate method. Moreover, it is also possible that one or more of the provided operations is modified or omitted.

The particular implementation of the technologies disclosed herein is a matter of choice dependent on the performance and other requirements of a computing device. Accordingly, the logical operations described herein may be referred to variously as states, operations, structural devices, acts, or modules. These states, operations, structural devices, acts, and modules can be implemented in hardware, software, firmware, in special-purpose digital logic, and any combination thereof. It should be appreciated that more or fewer operations can be performed than shown in the figures and described herein. These operations can also be performed in a different order than those described herein.

It also should be understood that the illustrated method can end at any time and need not be performed in its entirety. Some or all operations of the method, and/or substantially equivalent operations, can be performed by execution of computer-readable instructions included on a computer-storage media, as defined below. The term “computer-readable instructions,” and variants thereof, as used in the description and claims, is used expansively herein to include routines, applications, application modules, program modules, programs, components, data structures, algorithms, and the like. Computer-readable instructions can be implemented on various system configurations, including single-processor or multiprocessor systems, minicomputers, mainframe computers, personal computers, hand-held computing devices, microprocessor-based, programmable consumer electronics, combinations thereof, and the like.

Thus, it should be appreciated that the logical operations described herein are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance and other requirements of the computing system.

FIG.5shows additional details of an example computer architecture500for a device, such as a computer or a server capable of executing computer instructions. The computer architecture500illustrated inFIG.5includes processing unit(s)502, a system memory504, including a random-access memory506(RAM) and a read-only memory (ROM)508, and a system bus510that couples the memory504to the processing unit(s)502. The processing units502may also comprise or be part of a processing system. In various examples, the processing units502of the processing system are distributed. Stated another way, one processing unit502of the processing system may be located in a first location (e.g., a rack within a datacenter) while another processing unit502of the processing system is located in a second location separate from the first location.

Processing unit(s), such as processing unit(s)502, can represent, for example, a CPU-type processing unit, a GPU-type processing unit, a field-programmable gate array (FPGA), another class of digital signal processor (DSP), or other hardware logic components that may, in some instances, be driven by a CPU. For example, illustrative types of hardware logic components that can be used include Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-a-Chip Systems (SOCs), Complex Programmable Logic Devices (CPLDs), and the like.

A basic input/output system containing the basic routines that help to transfer information between elements within the computer architecture500, such as during startup, is stored in the ROM508. The computer architecture500further includes a mass storage device512for storing an operating system514, application(s)516, modules518, and other data described herein.

The mass storage device512is connected to processing unit(s)502through a mass storage controller connected to the bus510. The mass storage device512and its associated computer-readable media provide non-volatile storage for the computer architecture500. Although the description of computer-readable media contained herein refers to a mass storage device, it should be appreciated by those skilled in the art that computer-readable media can be any available computer-readable storage media or communication media that can be accessed by the computer architecture500.

Computer-readable media includes computer-readable storage media and/or communication media. Computer-readable storage media includes one or more of volatile memory, nonvolatile memory, and/or other persistent and/or auxiliary computer storage media, removable and non-removable computer storage media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Thus, computer storage media includes tangible and/or physical forms of media included in a device and/or hardware component that is part of a device or external to a device, including RAM, static RAM (SRAM), dynamic RAM (DRAM), phase change memory (PCM), ROM, erasable programmable ROM (EPROM), electrically EPROM (EEPROM), flash memory, compact disc read-only memory (CD-ROM), digital versatile disks (DVDs), optical cards or other optical storage media, magnetic cassettes, magnetic tape, magnetic disk storage, magnetic cards or other magnetic storage devices or media, solid-state memory devices, storage arrays, network attached storage, storage area networks, hosted computer storage or any other storage memory, storage device, and/or storage medium that can be used to store and maintain information for access by a computing device.

In contrast to computer-readable storage media, communication media can embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanism. As defined herein, computer storage media does not include communication media. That is, computer-readable storage media does not include communications media consisting solely of a modulated data signal, a carrier wave, or a propagated signal, per se.

According to various configurations, the computer architecture500may operate in a networked environment using logical connections to remote computers through the network520. The computer architecture500may connect to the network520through a network interface unit522connected to the bus510.

It should be appreciated that the software components described herein may, when loaded into the processing unit(s)502and executed, transform the processing unit(s)502and the overall computer architecture500from a general-purpose computing system into a special-purpose computing system customized to facilitate the functionality presented herein. The processing unit(s)502may be constructed from any number of transistors or other discrete circuit elements, which may individually or collectively assume any number of states. More specifically, the processing unit(s)502may operate as a finite-state machine, in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions may transform the processing unit(s)502by specifying how the processing unit(s)502transition between states, thereby transforming the transistors or other discrete hardware elements constituting the processing unit(s)502.

While certain example embodiments have been described, these embodiments have been presented by way of example only and are not intended to limit the scope of the inventions disclosed herein. Thus, nothing in the foregoing description is intended to imply that any particular feature, characteristic, step, component, module, or block is necessary or indispensable. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions, and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions disclosed herein. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of certain of the inventions disclosed herein.

It should be appreciated that any reference to “first,” “second,” etc. elements within the Summary and/or Detailed Description is not intended to and should not be construed to necessarily correspond to any reference of “first,” “second,” etc. elements of the claims. Rather, any use of “first” and “second” within the Summary, Detailed Description, and/or claims may be used to distinguish between two different instances of the same element (e.g., two different versions).

In closing, although the various configurations have been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended representations is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed subject matter.