Search

US-12625987-B2 - Method and system for executing a secure file-level restore from a block-based backup

US12625987B2US 12625987 B2US12625987 B2US 12625987B2US-12625987-B2

Abstract

A method for managing a block-based backup (BBB) includes: sending a file system parsing request to a file system, in which the file system is backed up in a backup storage as the BBB; obtaining file system metadata, in which the file system metadata is generated and stored in the backup storage in response to the file system parsing request; analyzing the file system metadata to generate an index for each asset of the file system; reordering the index of each asset to generate a reordered index; determining a user access level of a user; identifying assets in the reordered index to obtain a set of permitted assets for the user; providing a graphical user interface (GUI) specifying the set of permitted assets; receiving selected assets among the set of permitted assets via the GUI; and restoring the selected assets from the BBB.

Inventors

  • Sunil Yadav
  • Shelesh Chopra

Assignees

  • DELL PRODUCTS L.P.

Dates

Publication Date
20260512
Application Date
20220725

Claims (20)

  1. 1 . A method for managing a block-based backup (BBB), the method comprising: receiving a BBB request from a user to back up a file system (FS) to a backup storage; initiating, based on the BBB request, backing up of the FS to the backup storage as the BBB; sending an FS parsing request to the FS, wherein the FS parsing request is sent after the FS is backed up to the backup storage, wherein the FS is backed up in accordance with a backup schedule that is configured based on a user's recovery point objective; obtaining FS metadata, wherein the FS metadata is generated for each asset of the FS using a snapshot of the FS and stored to the backup storage in response to the FS parsing request, wherein the FS metadata comprises an identifier of a parent folder comprising an asset, a size of the asset, an offset for data of the asset stored in a file of the FS, and an attribute of the asset, wherein the attribute specifies how the FS should manage the asset; marking, after the FS metadata is stored to the backup storage, the BBB as completed on a graphical user interface (GUI) to notify to the user; obtaining, after the marking, the FS metadata from the backup storage; analyzing the FS metadata to generate an index for each asset of the FS; reordering the index of each asset to generate a reordered index, wherein the reordered index reflects an FS hierarchy of the FS and an access level of each asset, wherein the access level of each asset specifics a user access level the user must have to view each asset on the GUI; and after the reordered index is displayed: receiving a BBB selection request from the user; determining, in response to the BBB selection request, a user access level of the user; identifying assets in the reordered index to define a set of permitted assets for the user, wherein the access level of each asset of the set of permitted assets is less than or equal to the user access level of the user; displaying the set of permitted assets on the GUI, wherein assets with access levels greater than the user access level are not displayed on the GUI; receiving selected assets among the set of permitted assets via the GUI, wherein the selected assets are selected by the user via the GUI; sending a restore request to a recovery agent (RA) to restore the selected assets from the BBB, wherein the restore request comprises details associated with the FS metadata; and receiving a notification from the RA regarding a restoring status of the selected assets.
  2. 2 . The method of claim 1 , wherein the selected assets are restored in a recovery host.
  3. 3 . The method of claim 1 , wherein the reordered index is stored in an index database.
  4. 4 . The method of claim 1 , wherein the FS metadata further comprises identifiers of the selected assets and at least one access control list (ACL) associated with the selected assets.
  5. 5 . The method of claim 1 , wherein the FS is backed up using a virtual hard disk (VHDX) file format.
  6. 6 . The method of claim 1 , wherein the FS is a new technology file system (NTFS).
  7. 7 . The method of claim 1 , wherein the selected assets are files and folders of the FS.
  8. 8 . A non-transitory computer readable medium comprising computer readable program code, which when executed by a computer processor enables the computer processor to perform a method for managing a block-based backup (BBB), the method comprising: receiving a BBB request from a user to back up a file system (FS) to a backup storage; initiating, based on the BBB request, backing up of the FS to the backup storage as the BBB; sending an FS parsing request to the FS, wherein the FS parsing request is sent after the FS is backed up to the backup storage, wherein the FS is backed up in accordance with a backup schedule that is configured based on a user's recovery point objective; obtaining FS metadata, wherein the FS metadata is generated for each asset of the FS using a snapshot of the FS and stored to the backup storage in response to the FS parsing request, wherein the FS metadata comprises an identifier of a parent folder comprising an asset, a size of the asset, an offset for data of the asset stored in a file of the FS, and an attribute of the asset, wherein the attribute specifies how the FS should manage the asset; marking, after the FS metadata is stored to the backup storage, the BBB as completed on a graphical user interface (GUI) to notify to the user; obtaining, after the marking, the FS metadata from the backup storage; analyzing the FS metadata to generate an index for each asset of the FS; reordering the index of each asset to generate a reordered index, wherein the reordered index reflects an FS hierarchy of the FS and an access level of each asset, wherein the access level of each asset specifics a user access level the user must have to view each asset on the GUI; and after the reordered index is displayed: receiving a BBB selection request from the user; determining, in response to the BBB selection request, a user access level of the user; identifying assets in the reordered index to define a set of permitted assets for the user, wherein the access level of each asset of the set of permitted assets is less than or equal to the user access level of the user; displaying the set of permitted assets on the GUI, wherein assets with access levels greater than the user access level are not displayed on the GUI; receiving selected assets among the set of permitted assets via the GUI, wherein the selected assets are selected by the user via the GUI; sending a restore request to a recovery agent (RA) to restore the selected assets from the BBB, wherein the restore request comprises details associated with the FS metadata; and receiving a notification from the RA regarding a restoring status of the selected assets.
  9. 9 . The non-transitory computer readable medium of claim 8 , wherein the selected assets are restored in a recovery host.
  10. 10 . The non-transitory computer readable medium of claim 8 , wherein the reordered index is stored in an index database.
  11. 11 . The non-transitory computer readable medium of claim 8 , wherein the FS metadata further comprises identifiers of the selected assets and at least one access control list (ACL) associated with the selected assets.
  12. 12 . The non-transitory computer readable medium of claim 8 , wherein the FS is backed up using a virtual hard disk (VHDX) file format.
  13. 13 . The non-transitory computer readable medium of claim 8 , wherein the FS is a new technology file system (NTFS).
  14. 14 . The non-transitory computer readable medium of claim 8 , wherein the selected assets are files and folders of the FS.
  15. 15 . A system for managing a block-based backup (BBB), the system comprising: a processor comprising circuitry, memory comprising instructions, which when executed perform a method, the method comprising: receiving a BBB request from a user to back up a file system (FS) to a backup storage; initiating, based on the BBB request, backing up of the FS to the backup storage as the BBB; sending an FS parsing request to the FS, wherein the FS parsing request is sent after the FS is backed up to the backup storage, wherein the FS is backed up in accordance with a backup schedule that is configured based on a user's recovery point objective; obtaining FS metadata, wherein the FS metadata is generated for each asset of the FS using a snapshot of the FS and stored to the backup storage in response to the FS parsing request, wherein the FS metadata comprises an identifier of a parent folder comprising an asset, a size of the asset, an offset for data of the asset stored in a file of the FS, and an attribute of the asset, wherein the attribute specifies how the FS should manage the asset; marking, after the FS metadata is stored to the backup storage, the BBB as completed on a graphical user interface (GUI) to notify to the user; obtaining, after the marking, the FS metadata from the backup storage; analyzing the FS metadata to generate an index for each asset of the FS; reordering the index of each asset to generate a reordered index, wherein the reordered index reflects an FS hierarchy of the FS and an access level of each asset, wherein the access level of each asset specifics a user access level the user must have to view each asset on the GUI; and after the reordered index is displayed: receiving a BBB selection request from the user; determining, in response to the BBB selection request, a user access level of the user; identifying assets in the reordered index to define a set of permitted assets for the user, wherein the access level of each asset of the set of permitted assets is less than or equal to the user access level of the user; displaying the set of permitted assets on the GUI, wherein assets with access levels greater than the user access level are not displayed on the GUI; receiving selected assets among the set of permitted assets via the GUI, wherein the selected assets are selected by the user via the GUI; sending a restore request to a recovery agent (RA) to restore the selected assets from the BBB, wherein the restore request comprises details associated with the FS metadata; and receiving a notification from the RA regarding a restoring status of the selected assets.
  16. 16 . The system of claim 15 , wherein the selected assets are restored in a recovery host.
  17. 17 . The system of claim 15 , wherein the reordered index is stored in an index database.
  18. 18 . The system of claim 15 , wherein the FS metadata further comprises identifiers of the selected assets and at least one access control list (ACL) associated with the selected assets.
  19. 19 . The system of claim 15 , wherein the FS is backed up using a virtual hard disk (VHDX) file format.
  20. 20 . The system of claim 15 , wherein the FS is a new technology file system (NTFS).

Description

BACKGROUND Computing devices may include any number of internal components such as processors, memory, and persistent storage. Computing resources associated with (e.g., used by) each of these internal components may be used to generate, store, and backup data. Such utilization of computing resources may affect the overall performance of the computing devices. BRIEF DESCRIPTION OF DRAWINGS Certain embodiments of the invention will be described with reference to the accompanying drawings. However, the accompanying drawings illustrate only certain aspects or implementations of the invention by way of example, and are not meant to limit the scope of the claims. FIG. 1 shows a diagram of a system in accordance with one or more embodiments of the invention. FIG. 2 shows a diagram of a production host in accordance with one or more embodiments of the invention. FIG. 3 shows a diagram of a recovery host in accordance with one or more embodiments of the invention. FIGS. 4.1-4.3 show a method for executing a secure file-level restore from a block-based backup (BBB) in accordance with one or more embodiments of the invention. FIG. 5.1 shows an example file system metadata in accordance with one or more embodiments of the invention. FIGS. 5.2 and 5.3 show an example reordered index in accordance with one or more embodiments of the invention. FIG. 6 shows a diagram of a computing device in accordance with one or more embodiments of the invention. DETAILED DESCRIPTION Specific embodiments of the invention will now be described in detail with reference to the accompanying figures. In the following detailed description of the embodiments of the invention, numerous specific details are set forth in order to provide a more thorough understanding of one or more embodiments of the invention. However, it will be apparent to one of ordinary skill in the art that one or more embodiments of the invention may be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description. In the following description of the figures, any component described with regard to a figure, in various embodiments of the invention, may be equivalent to one or more like-named components described with regard to any other figure. For brevity, descriptions of these components will not be repeated with regard to each figure. Thus, each and every embodiment of the components of each figure is incorporated by reference and assumed to be optionally present within every other figure having one or more like-named components. Additionally, in accordance with various embodiments of the invention, any description of the components of a figure is to be interpreted as an optional embodiment, which may be implemented in addition to, in conjunction with, or in place of the embodiments described with regard to a corresponding like-named component in any other figure. Throughout this application, elements of figures may be labeled as A to N. As used herein, the aforementioned labeling means that the element may include any number of items, and does not require that the element include the same number of elements as any other item labeled as A to N. For example, a data structure may include a first element labeled as A and a second element labeled as N. This labeling convention means that the data structure may include any number of the elements. A second data structure, also labeled as A to N, may also include any number of elements. The number of elements of the first data structure, and the number of elements of the second data structure, may be the same or different. Throughout the application, ordinal numbers (e.g., first, second, third, etc.) may be used as an adjective for an element (i.e., any noun in the application). The use of ordinal numbers is not to imply or create any particular ordering of the elements nor to limit any element to being only a single element unless expressly disclosed, such as by the use of the terms “before”, “after”, “single”, and other such terminology. Rather, the use of ordinal numbers is to distinguish between the elements. By way of an example, a first element is distinct from a second element, and the first element may encompass more than one element and succeed (or precede) the second element in an ordering of elements. As used herein, the phrase operatively connected, or operative connection, means that there exists between elements/components/devices a direct or indirect connection that allows the elements to interact with one another in some way. For example, the phrase ‘operatively connected’ may refer to any direct connection (e.g., wired directly between two devices or components) or indirect connection (e.g., wired and/or wireless connections between any number of devices or components connecting the operatively connected devices). Thus, any path through which information may travel may be considered an operative connection