Backups of file system instances with root object encrypted by metadata encryption key

BACKGROUND

0001Computing systems may store data. Some example computing systems may operate data virtualization platforms that control how data is stored. The data may be encrypted for privacy and security purposes. Computing systems may create backups of data to protect against loss.

BRIEF DESCRIPTION OF THE DRAWINGS

0002Various examples will be described below with reference to the following figures.

0003<figref idref="DRAWINGS">FIG. 1</figref> depicts an example environment where a node may create backups of file system instances with encrypted data objects.

0004<figref idref="DRAWINGS">FIG. 2</figref> depicts an example file system instance where data objects are encrypted using a Data Encryption Key.

0005<figref idref="DRAWINGS">FIG. 3</figref> depicts an example system with a machine readable medium that includes instructions to encrypt data objects using a Data Encryption Key and to create a backup of a file system instance having encrypted data objects.

0006<figref idref="DRAWINGS">FIG. 4</figref> depicts an example system with a machine readable medium that includes instructions to delete a Data Encryption Key to cryptographically erase file system instances and backups.

0007<figref idref="DRAWINGS">FIG. 5</figref> depicts an example method that includes creating a backup of a file system instance having encrypted data objects.

0008<figref idref="DRAWINGS">FIG. 6</figref> depicts an example method that includes deleting a Data Encryption Key to cryptographically erase a file system instance and backups.

0009<figref idref="DRAWINGS">FIG. 7</figref> depicts an example environment where a node may create backups of file system instances with encrypted data objects.

0010<figref idref="DRAWINGS">FIG. 8</figref> depicts an example system with a machine readable medium that includes instructions to encrypt a root object of the file system instance using a Metadata Encryption Key and to create a backup of the file system instance.

0011<figref idref="DRAWINGS">FIG. 9</figref> depicts an example system with a machine readable medium that includes instructions to verify an unencrypted reconstructed root object and instructions to delete a Metadata Encryption Key to cryptographically erase a selected backup.

0012<figref idref="DRAWINGS">FIG. 10</figref> depicts an example method that includes encrypting a root object using a Metadata Encryption Key.

0013<figref idref="DRAWINGS">FIG. 11</figref> depicts an example method that includes verifying a reconstructed root object.

0014<figref idref="DRAWINGS">FIG. 12</figref> depicts an example method that includes deleting a Metadata Encryption Key to cryptographically erase a selected file system instance and backup.

0015Throughout the drawings, identical reference numbers may designate similar, but not necessarily identical, elements. Throughout the drawings, a hyphenated index number “N” appended to some of the reference numerals may be understood to merely denote plurality and may be replaced by an integer to provide a particular example. Additionally, use herein of a reference numeral without a hyphenated index number, where such reference numeral is referred to elsewhere with a hyphenated index number, may be a general reference to the corresponding plural elements, collectively or individually.

DETAILED DESCRIPTION

0016Data may be stored on computing systems, such as servers, computer appliances, workstations, storage systems or storage arrays, converged or hyperconverged systems, or the like. Computing systems connected by a network may also be referred to as nodes and vice versa. To store data, some computing systems may utilize a data virtualization platform that abstracts aspects of the physical storage hardware on which the data is physically stored (e.g., aspects such as addressing, configurations, etc.) and presents virtualized or logical storage to a user environment (e.g., to an operating system, applications, processes, etc.). The virtualized storage may be pooled from multiple storage hardware (e.g., hard disk drives, solid state drives, etc.) into a data store, out of which the virtualized or logical storage may be provided. The data virtualization platform may also provide data services such as deduplication, compression, replication, and the like.

0017In some implementations, the data virtualization platform may be instantiated, maintained, and managed by, at least in part, a virtual controller. A virtual controller may be a virtual machine (VM) executing on hardware resources, such as a processor and memory, with specialized processor-executable instructions to establish and maintain virtualized storage according to various examples described herein. In such instances, the virtual controller may be operating alongside guest virtual machines (also called client or user virtual machines), and on a same hypervisor or virtual machine manager as the guest virtual machines for example.

0018In some instances, the data virtualization platform may be object-based. An object-based data virtualization platform may differ from block level storage (e.g., implemented in storage area networks and presented via a storage protocol such as iSCSI or Fibre Channel) and file level storage (e.g., a virtual file system which manages data in a file hierarchy and is presented via a file protocol such as NFS or SMB/CIFS), although an object-based data virtualization platform may underlie block or file storage protocols in some implementations.

0019Components of an example object-based data virtualization platform may include a flat object store and one or more file system instances, among other things. Data may be stored as objects in the object store. For example, user accessible files and directories may be made up of multiple data objects. The object store may also store metadata objects related to the operation of the data virtualization platform, as will be described below. In an example, objects may be of a predetermined fixed size in the object store (e.g., 4 kib or 8 kib for data objects and 1 kib for metadata objects). Each object may be identified by a signature (also referred to as an object fingerprint), which, in some implementations, may include a cryptographic hash digest of the content of that object. An object index can correlate the signature of an object in the object store to a physical address of the object's content (i.e., a physical address on storage hardware such as disk).

0020A file system instance may refer to an organization of metadata objects and data objects that relate the data objects hierarchically to a root object. Thus, a file system instance may be identified by its root object. For example, the file system instance may be a Merkle tree or any other hierarchical arrangement (e.g., directed acyclic graphs, etc.). In the case of a hierarchical Merkle tree, data objects may be located at the lowest tree level of any branch (that is, most distant from the root object) and may also referred to as leaf data objects. A parent object includes as its content the signatures of child objects. For example, a parent object of leaf data objects is a metadata object that stores as its content the signatures of its child leaf data objects. The root object and other internal objects of a tree may also be metadata objects that store as content the signatures of respective child objects. A metadata object may be able to store a number of signatures that is at least equal to a branching factor of the hierarchical tree, so that it may hold the signatures of all of its child objects.

0021In example implementations, data of one or more guest virtual machines may be stored by one or more file system instances (e.g., one guest VM using storage from multiple file system instances, many guest VMs using storage from a file system instance, or any variation in between). In a particular example, each guest virtual machine may be associated with a respective file system instance on a one-to-one basis. The data virtualization platform may export a file protocol mount point (e.g., an NFS or SMB mount point) by which a guest virtual machine can access the storage provided by a file system instance via the namespace of the file protocol. In some implementations, objects in an object store may be referenced more than once in a single file system instance or may be referenced multiple times in file system instances. Thus, the multiply-referenced object can be stored once but referenced many times to provide deduplication.

0022File system instances and data objects thereof may be replicated from one computing system to another computing system to provide data protection. The process of replicating data may also be referred to as backing up data. For example, data may be replicated between two or more nodes in a cluster, and such replication may be deemed a local backup. In another example, data may be replicated from a source node to a remote node, and such replication may be deemed a remote backup. The remote node may be a node at a third-party backup service, a node in the public cloud, or a geographically separated node owned by the same entity that owns the source node. A series of snapshots may capture a file system instance at various points in time and these snapshots can be backed up as a series of backups.

0023Stored data may be encrypted to provide security, confidentiality, and privacy. Data may be encrypted using an encryption algorithm and an encryption key. In some instances, including compliance with governmental standards or corporate policies, the deletion of encrypted data must ensure that the data cannot be recovered.

0024Thus, it may be useful to provide for secure backups of encrypted data while still enabling data efficiencies from deduplication and compression. Examples described herein may relate to hierarchical file system instances being contained and isolated in a security domain. Those file system instances may be made secure by encrypting constituent data objects using a Data Encryption Key (DEK) that is specific to the security domain. The DEK is wrapped (i.e., encapsulated by symmetric encryption) by a Key Encryption Key (KEK) shared exclusively by the nodes in a particular cluster, which limits the nodes trusted to access the secure data. In some implementations, encryption of the data objects may also use encryption algorithm tweak values based on for example, respective positions of the data objects in the file system instance (e.g., positions based on the hierarchical relationships in the file system instance), such that the tree structure of the file system instance needs to be known to decrypt encrypted data objects.

0025A secure backup of the file system instance may be created on a local or remote backup node by replicating encrypted data objects to the backup node. The backup node cannot decrypt the backup unless the backup node is a member of the cluster and has access to the KEK to unwrap the DEK. By virtue of a Data Encryption Key being specific to a security domain and a Key Encryption Key being used exclusively by a cluster and nodes thereof, deduplication of encrypted data can be performed across backup file system instances associated with a same security domain but not across backup file system instances associated with different security domains, thus preventing intermingling of data outside of a security domain. Moreover, a DEK may be deleted to cryptographically erase a secure, encrypted file system instance and all related secure, encrypted backups in an efficient manner and without disturbing any unencrypted data or any file system instances and backups in other security domains. Thus, both security and deduplication may be achieved for a series of backups, such as in a series of snapshots of a file system.

0026Some examples relate to encrypting root objects of different file system instances with different Metadata Encryption Keys (MEK). By virtue of deleting a selected, a particular file system instance and any related backups may be cryptographically erased without disturbing other file system instances associated with the security domain. For example, MEKs may be useful for cryptographically erasing a particular snapshot in a series of snapshots. Additional advantages will be apparent in view of the following descriptions.

0027Referring now to the figures, <figref idref="DRAWINGS">FIG. 1</figref> illustrates an example computing environment that includes a node-1 <b>110</b> with a processing resource <b>112</b> and a machine readable medium <b>114</b>. The node-1 <b>110</b> may also be in communication with a wired and/or wireless network via a network interface. <figref idref="DRAWINGS">FIG. 1</figref> also illustrates a node-2 <b>140</b> and a node-3 <b>160</b>, each of which may include structure and functionality similar in many respects to the node-1 <b>110</b> described herein, and may communicate with each other and with node-1 <b>110</b> via a network. Each of the node-1 <b>110</b>, node-2 <b>140</b>, and node-3 <b>160</b> may also be referred to as a computing system and each may be a server, a computer appliance, a workstation, a storage system, a storage array, a converged system, a hyperconverged systems, or the like.

0028The processing resource <b>112</b> may include a microcontroller, a microprocessor, central processing unit core(s), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc. The machine readable medium <b>114</b> may be non-transitory (i.e., does not encompass transitory propagating signals) and may include random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, a hard disk drive, solid state disk, etc. The processing resource <b>112</b> may execute instructions (i.e., programming or software code) stored on the machine readable medium <b>114</b>. Additionally or alternatively, the processing resource <b>112</b> may include electronic circuitry for performing the instructions and functionality described herein.

0029A data virtualization platform <b>116</b> may operate on the node-1 <b>110</b>. In some implementations, a data virtualization platform <b>116</b> may be instantiated by a virtual controller (e.g., a virtual machine) that itself may be implemented for example as instructions encoded on machine readable medium <b>114</b> and executed by the processing resource <b>112</b>. The data virtualization platform may be object-based as described above, which may maintain file system instances backed by an object store <b>120</b>. A file system instance may provide storage to a client such as a guest VM, operating system, or the like, which may be executing on the node-1 <b>110</b> or on another computing system in communication with the data virtualization platform <b>116</b> of node-1 <b>110</b> via a network. In some implementations, data of a guest VM, such as files and directors, may be stored in the object store <b>120</b> as data objects that are identifiable by content-based hash signatures and related in the file system instance of the guest VM in a hierarchical arrangement (e.g., a Merkle tree) to a root object. Although examples described herein may relate to guest VM data, it should be understood that the techniques described herein may also support other client environments, including non-virtualized environments.

0030The node-1 <b>110</b> may be grouped together with one or more other nodes to form a cluster. For example, node-1 <b>110</b> and node-2 <b>140</b> share common membership in cluster <b>150</b>. The cluster <b>150</b> may have a Key Encryption Key (KEK) <b>152</b> that is shared by all nodes in that cluster <b>150</b>, including node-1 <b>110</b> and node-2 <b>140</b>. In an environment where multiple clusters co-exist, each cluster may be associated with a different KEK. In other words, a given KEK is exclusive to an associated cluster and the nodes of that cluster. In some implementations, a node in the cluster <b>150</b> may retrieve the KEK <b>152</b> from a key management system (not shown) that may generate Key Encryption Keys. In some implementations, a KEK may be a 256-bit AES-256 key.

0031The cluster <b>150</b> may contain one or more security domains. A security domain is a container for secure file system instance(s). Said differently, one or more secure file system instances may belong to a security domain. In some examples, a security domain may be deemed a property of a file system instance or a VM associated with the file system instance. Each security domain is associated with a different Data Encryption Key (DEK). A DEK is used to encrypt data objects of the file system instances of the associated security domain. A DEK may be created for a security domain by the data virtualization platform <b>116</b> (e.g., a control plane of the data virtualization platform) when that security domain is created. In some implementations, a DEK may be a 512-bit XTS-AES-256 key. The DEK may be wrapped under the KEK of the cluster containing the security domain. Key wrapping, such as the wrapping of the DEK by the KEK, may be performed by a symmetric key encapsulation algorithm, for example.

0032The file system instances in a security domain may be, for example, snapshots of the data of a guest VM at different points in time. In some implementations, each snapshot is itself a file system instance. In another example, a security domain may contain file system instances of different guest VMs, which may also include snapshots for one or more of those different guest VMs in further examples. A security domain may be configured by a user or by policy. It may be understood that a security domain is a collection of file system instances to be encrypted by a same DEK.

0033In the example of <figref idref="DRAWINGS">FIG. 1</figref>, cluster <b>150</b> includes a security domain <b>124</b>, which contains file system instances <b>122</b>-<b>1</b> through <b>122</b>-N (also referred to generally or collectively as file system instance(s) <b>122</b>). Other security domains may be operative on the node-1 <b>110</b>, as depicted by a stack under the security domain <b>124</b>, and the node-1 <b>110</b> may hold different DEKs for each of those additional security domains. The file system instances <b>122</b> are secure according to techniques described here, and the data objects <b>126</b> making up secure file system instances <b>122</b> are encrypted with DEK <b>130</b>. Lines connecting some data objects <b>126</b> to some file system instances <b>122</b> illustrate, by way of example, that certain file system instances include certain data objects. In some implementations, the data objects <b>126</b> are encrypted using the DEK and respective tweak values that are based on a positions of the data objects within the file system instances <b>122</b> (e.g., position based on an inode number, inode tree number, offset, etc.), as will be described further herein below.

0034Each file system instance <b>122</b>-<b>1</b> through <b>122</b>-N may be identified by a respective root object <b>128</b>-<b>1</b> through <b>128</b>-N (also referred to generally or collectively as root object(s) <b>128</b>), as illustrated for example by a line connecting file system instance <b>122</b>-<b>1</b> and root object <b>128</b>-<b>1</b> and a line connecting file system instance <b>122</b>-N and root object <b>128</b>-N. In an example implementation, the root objects <b>128</b> may remain unencrypted in a secure file system instance, while the root objects <b>128</b> may be encrypted in other implementations described below. A root object <b>128</b> of a file system instance <b>122</b> may be hierarchically related to the encrypted data objects <b>126</b> through internal metadata objects <b>127</b>, forming a Merkle tree with branching factor N, for example. Although some internal metadata objects <b>127</b> form part of a file system instance <b>122</b>, lines are not drawn in <figref idref="DRAWINGS">FIG. 1</figref> for purposes of clarity. In some implementations, internal metadata objects <b>127</b> may remain unencrypted.

0035In an example, file system instances <b>122</b> on node-1 <b>110</b> may each be snapshots of the data of a particular guest VM. In another example, some of the file system instances <b>122</b> may correspond to different guest VMs.

0036The node-1 <b>110</b> may participate in creating a secure, encrypted backup of a file system instance <b>122</b> to another node (also referred to herein as a backup file system instance). For example, a local backup <b>142</b> may be created on node-2 <b>140</b> in the cluster <b>150</b> (i.e., a local node) ora remote backup <b>162</b> may be created on node-3 <b>160</b> (i.e., a remote node). Because node-2 <b>140</b> is in the cluster <b>150</b>, node-2 <b>140</b> may include security domain <b>124</b> to contain the secure backup of the file system instance <b>122</b>, and thus node-2 <b>140</b> may be able to perform additional operations that involve access to at least the KEK and DEK, such as a backup restore for example, that a remote node, such as node-3 <b>160</b>, that is not part of the cluster <b>150</b> and does not include the security domain <b>124</b> may be unable to perform. The backups may preserve deduplication and compression by virtue of originating from the same security domain, as will be described below. A backup originating from the security domain <b>124</b> generally refers to a backup made of a file system instance <b>122</b> contained in the security domain <b>124</b>. A backup originating from the security domain <b>124</b> may also be contained in the security domain <b>124</b> if the backup is on a local node such as node-2 <b>140</b>, and may be not contained in the security domain <b>124</b> if the backup is on a remote node such as node-3 <b>160</b>. Node-2 <b>140</b> and node-3 <b>160</b> may each operate a data virtualization platform similar to data virtualization platform <b>116</b> to store one or more backups.

0037For example, backup-1 <b>144</b>-<b>1</b> through backup-N <b>144</b>-N (also referred to generally or collectively as backup(s) <b>144</b>) are backups or replicas of file system instance-1 <b>122</b>-<b>1</b> through file system instance-N <b>122</b>-N, respectively, and can be stored on node-2 <b>140</b>, node-3 <b>160</b>, or both node-2 <b>140</b> and node-3 <b>160</b>, or other nodes not shown. The term backup, backup of file system instance, or backup file system instance may be used interchangeably herein. In some implementations, a backup <b>144</b> is a replica (e.g., an identical copy) of a source file system instance <b>122</b>, and thus each of the backups <b>144</b> also may be hierarchical file system instances backed by an object store. In some implementations, the backup process may include sending <b>170</b> at least some of the encrypted data objects <b>126</b> and the DEK <b>130</b> to a backup node. Secure file system instances <b>122</b> and backups <b>144</b> may be cryptographically erased by deleting the associated DEK <b>130</b>. Cryptographic erasure refers to no longer being able to decrypt data to a usable form, generally by virtue of destroying the associated key. The data of a cryptographically erased file system instance or backup may be subject to garbage collection process of the data virtualization platform <b>116</b>.

0038<figref idref="DRAWINGS">FIG. 2</figref> depicts an example file system instance <b>200</b>. The file system instance <b>200</b> may be an example implementation of a file system instance <b>122</b> of <figref idref="DRAWINGS">FIG. 1</figref>. In <figref idref="DRAWINGS">FIG. 2</figref>, the file system instance <b>200</b> may include circular objects representing metadata objects and rectangular objects representing data objects. The metadata and data objects of the file system instance <b>200</b> may be maintained in an object store, such as object store <b>120</b>.

0039The file system instance <b>200</b> is identified by a root object <b>202</b>, which may be an example of the root objects <b>128</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The file system instance <b>200</b> includes data objects <b>204</b>, which may be examples of data objects <b>126</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The file system instance <b>200</b> is in the form of a Merkle tree (also referred to as a hash tree) with a branching factor N, where the data objects <b>204</b> are located at a leaf level and are hierarchically related to the root object <b>202</b>. In particular, content-based signatures of the data objects <b>204</b> are calculated and stored as content in an associated parent metadata object <b>206</b>, a content-based signature of that parent metadata object <b>206</b> is calculated and stored in its parent metadata object, and so on until the root object <b>202</b> is reached. The metadata objects between the leaf data objects <b>204</b> and the root object <b>202</b>, such as objects <b>206</b>, <b>208</b> (described below), may be referred to as internal metadata objects, which may be examples of internal metadata objects <b>127</b> of <figref idref="DRAWINGS">FIG. 1</figref>.

0040A tree level <b>220</b> is a dimensional aspect of the file system instance <b>200</b> tree that represent how many levels away from the root object <b>202</b> a given object is (e.g., in increasing integer values, with the root being zero). An offset <b>230</b> into the file system instance <b>200</b> is a dimensional aspect that represents a position of an object at a given tree level (e.g., in increasing integer values from left to right), and may further be specified as either an offset into the entire file system instance <b>200</b> tree at a given tree level or an offset into a subtree <b>212</b> of the file system instance <b>200</b> at a given tree level.

0041The file system instance <b>200</b> also includes an inode mapping <b>207</b> that is a specialized level of metadata objects, each of which map or correspond to an inode at a user-level storage protocol above the file system instance <b>200</b> (e.g., an inode in a guest VM). An inode at the user-level storage protocol represents a file or a directory in, for example, a guest VM dataset. For example object <b>208</b>-<b>1</b> may map to an inode 0, object <b>208</b>-K may map to an inode K, and object <b>208</b>-N may map to an inode N. Thus, an inode number (e.g., 0 through N) is implicit in the position (i.e., in the offset <b>230</b> dimension) of an object in the tree at the inode mapping <b>207</b> level.

0042In some implementations, each of the inode metadata objects <b>208</b>-<b>1</b> through <b>208</b>-N (also referred to generally or collectively as inode metadata object(s) <b>208</b>) may reference data objects that store attribute and/or extended attribute data for that inode. Additionally, each of the inode metadata objects may reference a data subtree that hierarchically relates down to the data objects that comprise the data of the user-accessible file or directory corresponding to the inode number. The size of a data subtree may vary for different implementations. An inode tree number may be useful for identifying the type of child reference from an inode metadata object, including a data subtree (e.g., inode tree number 0), an attribute object (e.g., inode tree number 1), or an extended attribute object (e.g., inode tree number 2). To illustrate, <figref idref="DRAWINGS">FIG. 2</figref> depicts inode metadata object <b>208</b>-K for inode K referencing inode attribute data object <b>210</b> (inode tree number 1), inode extended attribute data object <b>211</b> (inode tree number 2), and a data subtree <b>212</b> (inode tree number 0) that ultimately relates down to data objects <b>204</b> via in part metadata object <b>206</b> that is a parent to the data objects <b>408</b>.

0043Example implementations of secure backup and erase functionality of node-1 <b>110</b> will now be described in <figref idref="DRAWINGS">FIGS. 3-6</figref>. In some implementations, the secure backup and erase functionality described herein may be implemented as instructions stored on machine readable medium <b>114</b> and executed by the processing resource <b>112</b>, and more particularly, may be functionality of the data virtualization platform <b>116</b>. Example implementation details may be described with reference back to <figref idref="DRAWINGS">FIGS. 1 and 2</figref>.

0044<figref idref="DRAWINGS">FIG. 3</figref> depicts an example system <b>300</b> with a machine readable medium <b>304</b> encoded with instructions <b>306</b>, <b>308</b>, <b>310</b> that are executable by a processing resource <b>302</b>. System <b>300</b> may serve as or form part of node-1 <b>110</b>. The system <b>300</b> may belong to a cluster, such as cluster <b>150</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The processing resource <b>302</b> and the machine readable medium <b>304</b> may be analogous in many respects to the processing resource <b>112</b> and the machine readable medium <b>114</b>. The machine readable medium <b>304</b> may be non-transitory.

0045Instructions <b>306</b>, when executed, cause the processing resource <b>302</b> to encrypt data objects of a file system instance (e.g., <b>122</b>-<b>1</b> or <b>200</b>) to generate encrypted data objects (e.g., <b>126</b> or <b>204</b>) using a DEK (e.g., <b>130</b>) that is specific to the security domain (e.g., <b>124</b>) that contains the file system instance. The types of data objects encrypted by instructions <b>306</b> may include data objects (e.g., <b>204</b>) in an inode data subtree (e.g., <b>212</b>), inode attribute data objects (e.g., <b>210</b>), or inode extended attribute data objects (e.g., <b>211</b>), using the DEK. The DEK is wrapped by a KEK (e.g., <b>152</b>) shared exclusively within the cluster (e.g., <b>150</b>). Instructions <b>306</b> may utilize XTS-AES encryption using the DEK, or alternatively, instructions <b>306</b> may utilize other encryption algorithms, such as Adiantum, which is based on ChaCha20 and Poly1305.

0046In some implementations, instructions <b>306</b> may encrypt data objects using the DEK and also using respective tweak values that are based on positions of the data objects in the file system instance. For example, the position of a data object may be based on an inode number, an inode tree number, an offset, or a tree level, as described above, or other dimensional or relational aspects of a tree, or any combination of the foregoing. In an example implementation, a position of a data object may be a mathematical combination (e.g., a sum) of an inode number (e.g., 0-N), an inode tree number (e.g., 0-2), and an offset (e.g., 0 for attribute and extended attribute data objects, and an integer in the offset <b>230</b> dimension for data subtree data objects). By virtue of encrypting data objects of a file system using respective positions, the structure of the file system instance must be known in order to decrypt any of the encrypted data objects, thus providing another security mechanism.

0047In some implementations, instructions <b>306</b> may be triggered upon a request to secure existing guest VM data corresponding to the file system instance, upon a request to create a new secure file system instance, or as new data objects are added to an existing secure file system instance.

0048In some implementations, the file system instance hierarchically relates the encrypted data objects located at a leaf level to a root object through references to signatures calculated based on the encrypted data objects, as described above with respect to <figref idref="DRAWINGS">FIG. 2</figref>. In some implementations, internal metadata objects of the file system instance between the root object and the encrypted data objects at the leaf level may be unencrypted.

0049Instructions <b>308</b>, when executed, cause the processing resource <b>302</b> to create a backup (e.g., <b>144</b>-<b>1</b>) of the file system instance (e.g., <b>122</b>-<b>1</b>) comprising at least some of the encrypted data objects (e.g., <b>126</b>). In particular, instructions <b>308</b> may create the backup on a backup node that is different from the system <b>300</b>, such as a local node (e.g., <b>140</b>) belonging to the same cluster as the system <b>300</b> or to a remote node (e.g., <b>160</b>) outside of and remote to the cluster.

0050In some implementations, the backup node may also be operating a data virtualization platform that is the same as or compatible with the data virtualization platform of the system <b>300</b>, and the backup node and system <b>300</b> may cooperate to perform the backup operation. Creating the backup may include replicating at least some of the encrypted data objects from the system <b>300</b> to the backup node, and in particular, replicating encrypted data objects that do not already exist on the backup node and not replicating encrypted data objects to the backup node for which respective signatures are found on the backup node. In particular, as will be described further below, not replicating encrypted data objects may be part of a deduplication process and may occur where other backups exist at the backup node, such as backups of other snapshots for the same guest VM data. In this manner, the backup process may be take advantage of deduplication properties and may be WAN efficient. Moreover, in some implementations, encrypted data objects are replicated to a backup node but internal metadata objects and root objects are not replicated, to reduce network traffic and to improve WAN efficiency. Instead, internal metadata objects and root objects may be reconstructed at the backup node by recalculating content and signature from the encrypted data objects, in a manner applicable for Merkle trees.

0051In an example implementation, instructions <b>308</b> may be triggered when system <b>300</b> makes a snapshot of guest VM data that results in a file system instance (e.g., <b>122</b>-<b>1</b>) as the snapshot. Instructions <b>308</b> may subsequently create a backup (e.g., <b>144</b>-<b>1</b>) of that file system instance to the backup node.

0052Instructions <b>310</b>, when executed, cause the processing resource <b>302</b> to send the DEK wrapped by the KEK to the backup node. For example, as illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, a copy of DEK <b>130</b> may be sent to and persisted on backup node-2 <b>140</b> and/or backup node-3 <b>160</b>. The backup node cannot decrypt the backup unless the node belongs to the same cluster as the system <b>200</b> and has access to the KEK to unwrap the DEK. For example, if the backup node is remote to the cluster, that node does not have access to the KEK since it does not belong to the cluster, cannot unwrap the DEK without the appropriate KEK, and thus cannot decrypt the backup without the DEK. Thus, the backup remains secure outside of the cluster.

0053<figref idref="DRAWINGS">FIG. 4</figref> depicts an example system <b>400</b> with a machine readable medium <b>404</b> encoded with instructions <b>404</b>, <b>408</b>, <b>410</b>, <b>412</b> that are executable by a processing resource <b>402</b>. System <b>400</b> may serve as or form part of node-1 <b>110</b>. In some examples, the instructions of system <b>400</b> may be implemented in combination with the instructions of system <b>300</b>. The system <b>400</b> may belong to a cluster, such as cluster <b>150</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The processing resource <b>402</b> and the machine readable medium <b>404</b> may be analogous in many respects to the processing resource <b>112</b> and the machine readable medium <b>114</b>. The machine readable medium <b>404</b> may be non-transitory.

0054Instructions <b>406</b>, when executed, cause the processing resource <b>402</b> to generate a signature for an object of the file system instance based on, for example, the content of the object. Instructions <b>406</b> may be used to calculate a signature for an encrypted data object (e.g., <b>126</b> or <b>204</b>), an encrypted inode attribute or extended attribute data object (e.g., <b>210</b> or <b>211</b>), an internal metadata object (e.g., <b>127</b>, <b>206</b>, <b>208</b>), or a root object (e.g., <b>128</b> or <b>202</b>). Thus, an encrypted data object or a metadata object can be identified by a corresponding signature generated by instructions <b>406</b>.

0055In some implementations, generating a signature of an object may include, for example, calculating a cryptographic hash digest of that object, using a hash function such as SHA-1, SHA-256, MD5, etc. For example, an unencrypted data object (uncompressed or compressed) of a particular file system instance may be encrypted by instructions <b>306</b> using a DEK specific to the file system instance as described above (and also using a position, in some implementations), and then that encrypted data object may be passed to instructions <b>406</b> for calculation of a corresponding signature.

0056In some implementations, instructions <b>406</b> may calculate hash-based message authentication codes (HMACs) to serve as the signatures of objects. For example, calculating an HMAC signature for an object may involve concatenating the object with a key and calculating a cryptographic hash of the concatenation result. In some implementations, the key may be based on the position of the object in the file system instance, as indicated on <figref idref="DRAWINGS">FIG. 2</figref>. More particularly, the position of an encrypted data object may be, for example, analogous to the position used as an encryption tweak value in implementations described above, and may be based on an inode number, an inode tree number, and/or an offset. The position of the tree root may be zero, for example. The position of metadata objects may be based on, for example, a tree level and an offset. By virtue of using an object position to calculate the object signature and because file system instances do not store back pointer signatures, a file system instance cannot be reconstructed once the root object is deleted or cryptographically erase, an example of which will be described further herein with reference to <figref idref="DRAWINGS">FIG. 9</figref> for example.

0057Instructions <b>408</b>, when executed, cause the processing resource <b>402</b> to create a backup of a file system instance on a backup node. Certain features of instructions <b>408</b> may be similar in many respects to instructions <b>308</b>. For example, in some implementations, instructions <b>408</b> may be triggered by a snapshot on the system <b>400</b> or by a backup request. Instructions <b>408</b> may create the backup on a local backup node or a remote backup node, by replicating at least some of the encrypted objects of the file system instance.

0058In some instances, instructions <b>408</b> may be executed to create an additional or subsequent backup of data in the security domain, where earlier backups or a series of backups in or originating from the security domain already exists. To illustrate with reference to <figref idref="DRAWINGS">FIG. 1</figref>, file system instance-1 <b>122</b>-<b>1</b> may have been backed up previously as backup-1 <b>144</b>-<b>1</b> on node-2 <b>140</b> and/or node-3 <b>160</b>, and file system instance-1 <b>122</b>-<b>1</b> and backup-1 <b>144</b>-<b>1</b> may correspond to a first snapshot of guest VM data for example. At a later point in time, another snapshot of the guest VM data may be generated, resulting in a file system instance-N <b>122</b>-N, for which instructions <b>408</b> can be executed to create a backup-N <b>144</b>-N on node-2 <b>140</b> and/or node-3 <b>160</b>. In another example, file system instance-1 <b>122</b>-<b>1</b> and file system instance-N <b>122</b>-N may not be snapshots of data of the same guest VM, but may be snapshots of data of different guest VMs.

0059In some implementations, the system <b>400</b> may be replicating data changes (e.g., of guest VM data) to the backup node on an ongoing basis, for high availability purposes for example. The ongoing replication may involve sending encrypted data objects to the backup node as they are written or modified on the system <b>400</b>. In such instances, instructions <b>408</b> to create a backup may involve the system <b>400</b> creating a snapshot file system instance (e.g., <b>122</b>-N) of the data and instructing the backup node to create a corresponding backup (e.g., <b>144</b>-N) based on the data changes that were replicated on an ongoing basis since a last backup (e.g., <b>144</b>-(N−1)).

0060Instructions <b>410</b>, when executed, cause the processing resource <b>402</b> to deduplicate objects based on signatures of the objects (e.g., as generated by instructions <b>406</b>). Deduplication may be performed for data objects and/or metadata objects. In some implementations, instructions <b>410</b> may perform inline deduplication, which may include, for example, comparing signatures of objects that are staged to be written to the object store against signatures of objects that are already stored in the object store and deciding to not write objects for which the same signatures already exist. Instead, the deduplicated file system instance may reference the existing objects using the existing signatures. In other implementations, instructions <b>410</b> may perform post-process deduplication, which may include removing objects from the object store having the same signature. Instructions <b>410</b> may be executed when creating a snapshot on a source node where the guest VM is running (e.g., node-1 <b>110</b>) or when creating a backup to a local backup node (e.g., node-2 <b>140</b>) or to a remote backup node (e.g., node-3 <b>160</b>).

0061Data security may be maintained while still preserving the ability to deduplicate data by virtue of different DEKs being used to encrypt data objects belonging to or originating from different security domains. In an example, data objects having identical unencrypted content but belonging to different file system instances of the same security domain will be encrypted using the same DEK, which may result in identical encrypted data objects, and those encrypted data objects may be hashed to produce identical signatures.

0062On the other hand, data objects having identical unencrypted content but belonging to different file system instances from different security domains are encrypted by different DEKs, resulting in encrypted data objects with different encrypted content, which in turn would result in different signatures generated by instructions <b>406</b>. The different signatures would cause the data objects from different security domains to not be deduplicated across those different security domains, according to instructions <b>410</b>, even though they have identical unencrypted content.

0063Moreover, if object position is used to encrypt objects and/or calculate object signatures as previously described with reference to instructions <b>306</b>, then objects with identical unencrypted content would need to be at the same position within respective file system instances (such as snapshots) to be deduplicated in a security domain. In other words, if object position is used for encryption and signature calculation, objects with identical unencrypted content may not be deduplicated within a same file system instance and may not be deduplicated between file system instances from different security domains. However, deduplication may occur for objects with identical unencrypted content at the same position between file system instances from the same security domain.

0064An example where deduplication may occur, particularly when object position is used to encrypt objects and calculate signatures, is among backups of snapshots of secure data of the same guest VM. In such a case, deduplication is beneficial, because snapshots in time may share large amounts of common data. For example, instructions <b>408</b> may be executed a plurality of times to create a plurality of backup file system instances (e.g., <b>144</b>-<b>1</b> through <b>144</b>-N), and instructions <b>410</b> may deduplicate objects against those backup file system instances. The deduplication by instructions <b>410</b> may occur inline in conjunction with instructions <b>408</b> so as to identify and remove duplicate objects (e.g., encrypted data objects in particular) during the backup process before they are replicated to the backup node such that replication is generally limited to additional encrypted data objects that are not already present on the backup node. Thus the amount of data transferred to the backup node may be reduced, making the backup process more WAN efficient. In other implementations, instructions <b>410</b> may perform post-process deduplication on the backup node.

0065Instructions <b>412</b>, when executed, cause the processing resource <b>402</b> to delete a DEK (e.g., <b>130</b>) to cryptographically erase any file system instance (e.g., <b>122</b>), backups (e.g., <b>144</b>), and series of backups (e.g., <b>144</b>) contained by and belonging to the security domain (e.g., <b>124</b>) associated with the DEK. In some implementations, instructions <b>412</b> may be triggered by a user request to delete the security domain. In some implementations, execution of instructions <b>412</b> instructs other nodes in the cluster to delete their respective copies of the DEK and to provide confirmation. By deleting a DEK, any data objects encrypted by the DEK can no longer be decrypted, thus providing cryptographic erasure of the sensitive data of a security domain.

0066In some implementations, machine readable medium <b>404</b> may be encoded with other instructions, such as instructions to delete a KEK. Because a KEK is exclusive to a particular cluster, deleting the KEK would cause the cryptographic erasure of every security domain associated with that cluster, as well as every file system instance contained by or originating from those security domains.

0067<figref idref="DRAWINGS">FIGS. 5 and 6</figref> are flow diagrams depicting various example methods. In some implementations, one or more blocks of the methods may be executed substantially concurrently or in a different order than shown. In some implementations, a method may include more or fewer blocks than are shown. In some implementations, one or more of the blocks of a method may, at certain times, be ongoing and/or may repeat. In some implementations, blocks of the methods may be combined.

0068The methods shown in <figref idref="DRAWINGS">FIGS. 5 and 6</figref> may be implemented in the form of executable instructions stored on a machine readable medium (e.g., such as machine readable medium <b>114</b>, <b>304</b>, or <b>404</b>) and executed by a processing resource (e.g., such as processing resource <b>112</b>, <b>302</b>, or <b>402</b>) and/or in the form of electronic circuitry. For example, aspects of the methods may be described below as being performed by a node in a cluster. In some implementations, aspects of the methods may be performed in particular by the data virtualization platform <b>116</b>, the system <b>300</b>, or the system <b>400</b>, described above.

0069<figref idref="DRAWINGS">FIG. 5</figref> is a flow diagram depicting an example method <b>500</b>. Method <b>500</b> starts at block <b>502</b> and continues to block <b>504</b>, where a node (e.g., a computing system in a cluster) encrypts data objects of a file system instance using a DEK to generate encrypted data objects. The file system instance belongs to a security domain within a cluster to which the node belongs. The DEK is specific to the security domain, and the DEK is wrapped by a KEK shared exclusively by nodes in the cluster. In some implementations, encrypting a data object may also use an encryption algorithm tweak value, which may be based on a position of the data object within the file system instance (e.g., a position based on inode number, inode tree number, and/or an offset). In some implementations, block <b>504</b> may be performed at least in part by executing instructions <b>306</b> described above.

0070The file system instance hierarchically relates the encrypted data objects to a root object based on object signatures. For example, the file system instance may be a Merkle tree similar to the file system instance <b>200</b> described above. In an implementation, to form the Merkle tree, signatures may be calculated for the encrypted data objects generated by block <b>504</b> and for any internal metadata objects of the Merkle tree until the root object is derived, in a manner described above. Signatures of encrypted data objects and internal metadata objects may be calculated using a cryptographic hash function. In some implementations, the signature of an object, whether an encrypted data object or internal metadata object, may be an HMAC based on a cryptographic hash of the content of that object using the position of that object within the file system instance as a key. Signature calculation may be performed at least in part by executing instructions <b>406</b> described above.

0071At block <b>506</b>, the node creates a backup of the file system instance on a backup node (e.g., a remote or local backup node). The backup may comprise at least some of the encrypted data objects encrypted at block <b>504</b>. In some implementations, block <b>506</b> may be performed at least in part by executing instructions <b>308</b> described above.

0072At block <b>508</b>, the node sends the DEK wrapped by the KEK to the backup node. The backup node cannot decrypt the backup unless the backup node is also a member of the same cluster and has access to the KEK to unwrap the DEK. In some implementations, block <b>508</b> may be performed at least in part by executing instructions <b>310</b> described above. At block <b>510</b>, method <b>500</b> ends.

0073<figref idref="DRAWINGS">FIG. 6</figref> is a flow diagram depicting an example method <b>600</b>. Method <b>600</b> starts at block <b>602</b> and continues to block <b>604</b>, where a node compresses a data object before encrypting the data object. For example, in some implementations, a node may perform block <b>604</b> before performing block <b>504</b>.

0074At block <b>606</b>, the node deduplicates the encrypted data objects based on signatures calculated from the encrypted data objects. Deduplication may be inline deduplication or post-process deduplication. In some implementations, block <b>606</b> may be performed at least in part by executing instructions <b>406</b> to calculate signatures and by executing instructions <b>410</b> to deduplicate objects. Block <b>606</b> may also be performed to deduplicate encrypted objects stored locally on the source node itself (e.g., during a snapshot process).

0075As described above with reference to instructions <b>410</b>, data objects having identical unencrypted content but belonging to different file system instances from different security domains are encrypted by different DEKs and are associated with different signatures. Thus, block <b>606</b> may not deduplicate the data objects having identical unencrypted content from different security domains, due to those signatures being different.

0076On the other hand, block <b>606</b> may include deduplicating encrypted data objects across file system instances and backups within or from a same security domain. In particular, block <b>608</b> may be performed when creating a backup to a backup node (e.g., by performing block <b>506</b>) to preclude sending encrypted data objects to the backup node when signatures are found on the backup node in a series of backups.

0077In an example, the node may periodically create snapshots of a file system instance, and each of those snapshots may trigger block <b>506</b> described above to be performed to create backups of those file system instance snapshots on the backup node. Thus, block <b>506</b> may be performed multiple times (e.g., iterations of method <b>500</b>) to create a series of backup file system instances on the backup node, where each backup file system instance in the series (e.g., <b>144</b>-<b>1</b> through <b>144</b>-N) is a backup of a corresponding snapshot (e.g., <b>122</b>-<b>1</b> through <b>122</b>-N). Additionally, the series of backups belong to and originate from the same security domain and thus include encrypted data objects that are encrypted using the same DEK. By virtue of performing deduplication at block <b>608</b> in conjunction with block <b>506</b>, creating some of the backups may involve sending only additional encrypted data objects that are not already present on the backup node, including data objects that may have identical unencrypted content as data objects on the backup node but are not in the same position within the file system instance structure, if position is used for encryption and signature generation.

0078At block <b>610</b>, a DEK can be deleted to cryptographically erase a file system instance and a series of backups. In some implementations, block <b>610</b> may involve instruction all nodes having a copy of the DEK to delete their copy of the DEK. In some implementations, block <b>610</b> may be performed by executing instructions <b>412</b>. Method <b>600</b> may end at block <b>612</b>.

0079<figref idref="DRAWINGS">FIG. 7</figref> depicts an example computing environment similar in many respects to the example illustrated in <figref idref="DRAWINGS">FIG. 1</figref>. For example, a node-1 <b>110</b> may encrypt data objects of file system instances to secure those file system instances and may create backups on local or remote nodes. As previously described, a secure file system instance <b>122</b> may comprise some of the encrypted data objects <b>126</b> that are hierarchically related up to a root object <b>128</b>, in a Merkle tree for example.

0080In an example, each file system instance <b>122</b> may correspond to a different snapshot of a guest VM or other type of dataset, and each file system instance may be identified by a different corresponding root object <b>128</b>. Moreover, each root object <b>128</b> may be encrypted using a different respective Metadata Encryption Key (MEK). For example, a first root object-1 <b>128</b>-<b>1</b> may be encrypted using a first MEK-1 <b>732</b>-<b>1</b> and a second root object-2 <b>128</b>-<b>2</b> (N=2 on <figref idref="DRAWINGS">FIG. 7</figref>) may be encrypted using a second MEK-2 <b>732</b>-<b>2</b>. Thus, MEKs are specific to an associated root object. In some implementations, even if two file system instances <b>122</b> are the same, such as when no changes are made to the data between two snapshots, different MEKs would be used to encrypt the root objects of those two file system instances. In some implementations, encrypted root objects may be persisted in a separate storage medium apart from other metadata objects or data objects.

0081A MEK may be a 512-bit XTS-AES-256 key and may be generated, in some implementations, by the data virtualization platform <b>116</b> (e.g., at a control plane the data virtualization platform <b>116</b>). The MEKs <b>732</b>-<b>1</b> through <b>732</b>-N (generally or collectively MEK(s) <b>732</b>) are wrapped by the DEK <b>130</b> of the security domain <b>124</b> containing the file system instances <b>122</b> having root objects <b>128</b> encrypted by the MEKs <b>732</b>. In this manner, a security domain may be associated with a single DEK and multiple MEKs.

0082The node-1 <b>110</b> may create a backup <b>144</b> of a file system instance <b>122</b> to a backup node such as a local node-2 <b>140</b> within the same cluster <b>150</b> or to a remote node-3 <b>160</b> outside the cluster <b>150</b>. The node-1 <b>110</b> may send <b>770</b> the DEK <b>130</b> (wrapped by KEK <b>152</b>) and the MEK <b>732</b> (wrapped by DEK <b>130</b>) corresponding to the file system instance being backed up to the backup node. For example, as part of the backup process of file system instance-N <b>122</b>-N, node-1 <b>110</b> may replicate <b>770</b> at least some of the encrypted data objects <b>126</b> to the backup node (e.g., encrypted data objects that are not subject to deduplication) and may send <b>770</b> MEK-N <b>732</b>-N. As depicted in <figref idref="DRAWINGS">FIG. 7</figref>, the backup nodes <b>140</b>, <b>160</b> may store DEK <b>130</b>, MEK-1 <b>732</b>-<b>1</b>, and MEK-N <b>732</b>-N, for example.

0083In some implementations, the backup process does not send the root object-N <b>128</b>-N or other internal metadata objects <b>127</b> (e.g., metadata objects between the root object and encrypted data objects at a leaf level), but instead the backup node may reconstruct the backup file system instance <b>144</b>-N up to a reconstructed root object based on encrypted data objects that are received from the node-1 <b>110</b> or are already resident on the backup node (e.g., if deduplicated). The backup node may send the reconstructed root object <b>772</b> to the source node, node-1 <b>110</b>, for verification, as will be described below with reference to <figref idref="DRAWINGS">FIGS. 9 and 11</figref>.

0084Example implementations supporting cryptographic erasure of a selected backup will now be described in <figref idref="DRAWINGS">FIGS. 8-12</figref>. In some implementations, the functionality described herein may be implemented as instructions stored on machine readable medium <b>114</b> and executed by the processing resource <b>112</b>, and more particularly, may be functionality of the data virtualization platform <b>116</b>. Example implementation details may be described with reference back to <figref idref="DRAWINGS">FIGS. 2 and 7</figref>.

0085<figref idref="DRAWINGS">FIG. 8</figref> depicts an example system <b>800</b> with a machine readable medium <b>804</b> encoded with instructions <b>806</b>, <b>808</b>, <b>810</b>, <b>812</b> that are executable by a processing resource <b>802</b>. System <b>800</b> may serve as or form part of node-1 <b>110</b>. The system <b>800</b> may belong to a cluster, such as cluster <b>150</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The processing resource <b>802</b> and the machine readable medium <b>804</b> may be analogous in many respects to the processing resource <b>112</b> and the machine readable medium <b>114</b>. The machine readable medium <b>804</b> may be non-transitory.

0086Instructions <b>806</b>, when executed, cause the processing resource <b>802</b> to encrypt data objects of a file system instance to generate encrypted data objects using a DEK specific to a security domain containing the file system instance. Instructions <b>806</b> may share similarities with instructions <b>306</b> described above. The DEK is wrapped by a KEK shared exclusively within a cluster to which the system <b>800</b> belongs. The file system instance hierarchically relates the encrypted data objects (e.g., <b>126</b>) located at a leaf level to a root object (e.g., <b>128</b>-<b>1</b>) through references to signatures of the encrypted data objects. For example, the file system instance may resemble file system instance <b>200</b>, where data objects <b>204</b> are related hierarchically in a Merkle tree to the root object <b>202</b>. Signatures may be generated by performing instructions <b>406</b> described above, for example.

0087Instructions <b>808</b>, when executed, cause the processing resource <b>802</b> to encrypt the root object (e.g., <b>128</b>-<b>1</b>) using a Metadata Encryption Key (MEK, e.g., <b>732</b>-<b>1</b>). The MEK may be wrapped by the DEK and may be specific to the root object.

0088Instructions <b>810</b>, when executed, cause the processing resource <b>802</b> to create a backup (e.g., <b>144</b>-<b>1</b>) of the file system instance on another computing system, such as a backup node (e.g., <b>140</b> or <b>160</b>). Instructions <b>810</b> may share similarities with instructions <b>308</b> described above. In some implementations, instructions <b>810</b> may be executed in conjunction with instructions <b>410</b> to deduplicate the backup as described above.

0089Instructions <b>812</b>, when executed, cause the processing resource <b>802</b> to send the DEK (e.g., <b>130</b>) and the MEK (e.g., <b>732</b>-<b>1</b>) to the backup node, together with the backup (e.g., <b>144</b>-<b>1</b>). Instructions <b>806</b>, <b>808</b>, <b>810</b>, <b>812</b> may be executed multiple times, such as with each snapshot of a guest VM, thus creating a series of backups (e.g., <b>144</b>) of file system instances (e.g., <b>122</b>) identified by respective root objects (e.g., <b>128</b>) encrypted by corresponding MEKs (e.g., <b>732</b>).

0090In some implementations, the system <b>800</b> may be replicating data changes (e.g., of guest VM data) to the backup node on an ongoing basis, for high availability purposes for example. The ongoing replication may involve sending encrypted data objects to the backup node as they are written or modified on the system <b>800</b>. In such instances, instructions <b>810</b> to create a backup may involve the system <b>800</b> creating a snapshot file system instance (e.g., <b>122</b>-N) of the data and instructing the backup node to create a backup of the snapshot file system instance (e.g., <b>144</b>-N) based on the data changes that were replicated on an ongoing basis since a last backup (e.g., <b>144</b>-(N−1)). As part of creating a backup, the backup node may generate a root object for the backup hierarchically related to signatures of the data changes and other encrypted data objects in the backup and may encrypt the root object with a MEK specific to the backup and snapshot file system instances. The system <b>800</b> and backup node may coordinate, at a control plane level for example, to ensure that the same MEK is used to encrypt the root objects of the snapshot file system instance and the corresponding backup.

0091<figref idref="DRAWINGS">FIG. 9</figref> depicts an example system <b>900</b> with a machine readable medium <b>904</b> encoded with instructions <b>905</b>, <b>906</b>, <b>908</b>, <b>910</b>, <b>912</b> that are executable by a processing resource <b>902</b>. System <b>900</b> may serve as or form part of node-1 <b>110</b>. In some implementations, the instructions of system <b>900</b> may be implemented in combination with instructions of system <b>800</b>. System <b>900</b> may belong to a cluster, such as cluster <b>150</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The processing resource <b>902</b> and the machine readable medium <b>904</b> may be analogous in many respects to the processing resource <b>112</b> and the machine readable medium <b>114</b>. The machine readable medium <b>904</b> may be non-transitory.

0092Instructions <b>905</b>, when executed, may cause the processing resource <b>902</b> to generate a different MEK to encrypt a root object of each different file system instance to be secured. For example, each time a snapshot is made of guest VM data, a new file system instance (e.g., <b>122</b>) may be created and a new MEK (e.g., <b>732</b>) may be generated by instructions <b>905</b> to encrypt the root object (e.g., <b>128</b>) of that new file system instance. In some implementations, instructions <b>905</b> may form part of a control plane of a data virtualization platform (e.g., <b>116</b>).

0093Instructions <b>906</b>, <b>908</b>, <b>910</b> may be useful for verifying reconstruction of a secure backup on a backup node, and in particular, reconstruction on a remote backup node. For example, a backup process may send only encrypted data objects (e.g., <b>126</b>, <b>204</b>, <b>210</b>, or <b>211</b>) of a file system instance but not a root object (e.g., <b>128</b> or <b>202</b>) or any internal metadata objects (e.g., <b>127</b>, <b>206</b>, <b>208</b>, etc.) to a backup node (e.g., <b>140</b> or <b>160</b>), as an optimization to reduce network traffic. The backup node can then reconstruct a hierarchical file system instance, such as a Merkle tree, by calculating signatures for objects at each level (starting at leaf level), including those signatures in a parent object, and repeating the process until the root object (e.g., <b>202</b>) is reached. Signature calculation may be performed by executing instructions <b>406</b> described above. Thus, a reconstructed root object will have in its content the signatures of its child objects. However, in a remote backup (e.g., <b>162</b>), a remote node (e.g., <b>160</b>) may not have access to the KEK (e.g., <b>152</b>) to unwrap the DEK (e.g., <b>130</b>), and thus the MEK (e.g., <b>732</b>-<b>1</b>) cannot be unwrapped and used to encrypt the reconstructed root object.

0094Instructions <b>906</b>, when executed, may cause the processing resource <b>902</b> to receive an unencrypted reconstructed root object sent (e.g., <b>772</b>) from a backup node (e.g., <b>140</b> or <b>160</b>). Alternatively or additionally, instructions <b>906</b> may receive a signature of the unencrypted reconstructed root object from the backup node.

0095Instructions <b>908</b>, when executed, may cause the processing resource <b>902</b> to verify the unencrypted reconstructed root object against a corresponding root object. For example, the unencrypted reconstructed root object may be associated a given backup (<b>144</b>-<b>1</b>) that is a backup of a corresponding file system instance (e.g., <b>122</b>-<b>1</b>) on the system <b>900</b>. The system <b>900</b>, as the source system that initiated the backup, may decrypt an associated root object (e.g., <b>128</b>-<b>1</b>) of that file system instance (e.g., on object store <b>120</b>) and compare that unencrypted root object (e.g., <b>128</b>-<b>1</b>) against the received unencrypted reconstructed root object. The comparison may include comparing hash-based signatures or checksums of both the unencrypted reconstructed root object and the decrypted root object or any other type of data comparison. A match between the unencrypted reconstructed root object from the backup node and the decrypted root object from the system <b>900</b> (i.e., the source node) signifies that the verification is successful, while a mismatch signifies that the verification is unsuccessful.

0096If the verification is not successful, then the system <b>900</b> may issue an error message. An unsuccessful verification may indicate that the backup has failed. If the verification is successful, instructions <b>910</b> may be executed to cause the processing resource <b>902</b> to send the MEK-encrypted root object to the backup node for storage. For example, the backup node may replace the unencrypted root object with the encrypted root object received from the system <b>900</b>, and the backup file system instance will subsequently be identified and referenced via the encrypted root object.

0097Instructions <b>912</b>, when executed, may cause the processing resource <b>902</b> to delete a selected MEK corresponding to a backup selected for cryptographic erasure. In some implementations, instructions <b>912</b> may include coordinating or instructing any node storing a copy of the selected MEK to delete their respective copies of the selected MEK and to provide confirmation.

0098For example, user input may be received by the system <b>900</b> indicating a file system instance (e.g., <b>122</b>-<b>1</b>), and a corresponding backup (e.g., <b>144</b>-<b>1</b>) by association, is to be cryptographically erased. The system <b>900</b> can identify the MEK (e.g., <b>732</b>-<b>1</b>) associated with the root object (e.g., <b>128</b>-<b>1</b>) that identifies the selected file system instance. The selected file system instance (e.g., <b>122</b>-<b>1</b>) and backup (e.g., <b>144</b>-<b>1</b>) may be among a plurality of file system instances (e.g., <b>122</b>) and backups (e.g., <b>144</b>), and the selected MEK (<b>732</b>-<b>1</b>) may be among a plurality of different respective MEKs (e.g., <b>732</b>). As described above, the file system instances (e.g., <b>122</b>) and backups (e.g., <b>144</b>) of file system instances are identified by respective root objects (e.g., <b>128</b>) that are encrypted using different respective MEKs (e.g., <b>732</b>). Thus, by deleting a selected MEK, the corresponding root object cannot be decrypted and is rendered cryptographically inaccessible. The corresponding file system instance and backup can no longer be accessed, since a hierarchical tree-based file system instance is traversed starting from the root object. At the same time, other file system instances and backups associated with the same security domain remain undisrupted.

0099More particularly, because back pointer signatures are not stored in metadata objects of the file system instances and backups, rendering an encrypted root object cryptographically inaccessible prevents a cryptographically erased file system instance or backup from being reconstructed in implementations where object position is used to calculate HMAC signatures for objects of the file system instance. By contrast, if position where not used in signature calculation, it could be possible to reconstruct a file system instance by calculating data object signatures and matching those signatures to signatures stored in metadata objects. However, the tree structure is not made available in some implementations and thus keys are not available to recalculate the correct HMAC signatures.

0100<figref idref="DRAWINGS">FIGS. 10-12</figref> are flow diagrams depicting various example methods. In some implementations, one or more blocks of a method may be executed substantially concurrently or in a different order than shown. In some implementations, a method may include more or fewer blocks than are shown. In some implementations, one or more of the blocks of a method may, at certain times, be ongoing and/or may repeat. In some implementations, blocks of <figref idref="DRAWINGS">FIGS. 10-12</figref> may be combined.

0101The methods may be implemented in the form of executable instructions stored on a machine readable medium (e.g., such as machine readable medium <b>114</b>, <b>804</b>, or <b>904</b>) and executed by a processing resource (e.g., such as processing resource <b>112</b>, <b>802</b>, or <b>902</b>) and/or in the form of electronic circuitry. For example, aspects of the methods may be described below as being performed by a node in a cluster. In some implementations, aspects of the methods may be performed in particular by the data virtualization platform <b>116</b>, the system <b>800</b>, or the system <b>900</b>, described above.

0102<figref idref="DRAWINGS">FIG. 10</figref> is a flow diagram depicting an example method <b>1000</b>. Method <b>1000</b> starts at block <b>1002</b> and continues to block <b>1004</b>, where a node (e.g., a computing system in a cluster) encrypts data objects of a file system instance to generate encrypted data objects using a DEK specific to a security domain containing the file system instance. The DEK is wrapped by a KEK shared exclusively by nodes in cluster. The file system instance hierarchically relates the encrypted data objects located at a leaf level to a root object through references to signatures of the encrypted data objects. For example, the file system instance may be a Merkle tree similar to the file system instance <b>200</b> described above. In some implementations, block <b>1004</b> may be performed at least in part by executing instructions <b>806</b> described above.

0103At block <b>1006</b>, the node encrypts the root object using a MEK to generate an encrypted root object. The MEK is wrapped by the DEK and is specific to the root object. In some implementations, block <b>1006</b> may be performed at least in part by executing instructions <b>808</b> described above.

0104At block <b>1008</b>, the node creates a backup of the file system instance on a backup node by replicating at least some of the encrypted data objects to the backup node. In some implementations, the backup may be deduplicated. In some implementations, block <b>1008</b> may be performed at least in part by executing instructions <b>810</b> described above.

0105At block <b>1010</b>, the node sends the DEK that is wrapped by the KEK and the MEK that is wrapped by the DEK to the backup node with the backup. In some implementations, block <b>1010</b> may be performed at least in part by executing instructions <b>812</b> described above. The method <b>1000</b> ends at block <b>1012</b>.

0106In an illustration, at least some blocks of method <b>1000</b> may be performed multiple times to create a series of backup file system instances on the backup node. For example, a first file system instance (e.g., <b>122</b>-<b>1</b>) may be secured by encrypting data objects thereof using a DEK (e.g., <b>130</b>) by performing block <b>1004</b>, and a first root object (e.g., <b>128</b>-<b>1</b>) of the first file system instance may be encrypted by a first MEK (e.g., <b>732</b>-<b>1</b>) by performing block <b>1006</b>. A first backup (e.g., <b>144</b>-<b>1</b>) may be created by performing block <b>1008</b>, and the DEK and first MEK may be sent (e.g., <b>770</b>) to a backup node (e.g., <b>140</b> or <b>160</b>) by performing block <b>1010</b>. At a later point in time, a second file system instance (e.g., <b>122</b>-<b>2</b>) may be generated, by a snapshot for example. The second file system instance may include additional data objects not present in the first file system instance, and those additional data objects may also be encrypted using the same DEK (e.g., <b>130</b>) by performing block <b>1004</b>. A second root object (e.g., <b>128</b>-<b>2</b>) may be generated for the second file system instance by calculating signatures up through a Merkle tree, and the second root object may be encrypted by performing block <b>1006</b> using a second MEK (e.g. <b>732</b>-<b>2</b>) that is different from the first MEK. A second backup (e.g., <b>144</b>-<b>2</b>) may be created on the backup node by performing block <b>1008</b>, and the DEK and second MEK may be sent to the backup node by performing block <b>1010</b>. Both the first backup and the second backup are contained by or originate from the same security domain. A signature of the encrypted first root object is different from a signature of the encrypted second root object by virtue of at least being encrypted by different MEKs, if not also due to different data content in the respective file system instances.

0107<figref idref="DRAWINGS">FIG. 11</figref> is a flow diagram depicting an example method <b>1100</b>. Method <b>1100</b> starts at block <b>1102</b> and continues to block <b>1104</b>, where a node (e.g., a source node that previously initiated a backup, such as node-1 <b>110</b>) receives, from a backup node (e.g., <b>140</b> or <b>160</b>), an unencrypted reconstructed root object or a signature of the unencrypted reconstructed root object (e.g., <b>772</b>). In particular, the backup node is not a member of the cluster that the receiving node is a member of, and the unencrypted reconstructed root object is generated by the backup node based on encrypted data objects of a backup. For example, the unencrypted reconstructed root object may be generated in a manner described above, with respect to <figref idref="DRAWINGS">FIG. 2</figref> for example. Block <b>1104</b> may be performed by executing instructions <b>906</b> for example.

0108At block <b>1106</b>, the node may verify the unencrypted reconstructed root object against a root object. For example, verifying may include decrypting the root object at the source node and comparing the decrypted root object to the received unencrypted reconstructed root object (e.g., a signature comparison). In some implementations, block <b>1106</b> may be performed by executing instructions <b>908</b> described above. Verification is successful if the decrypted root object and the unencrypted reconstructed root object match.

0109If the verifying is successful (“YES” at block <b>1108</b>), method <b>1100</b> proceeds to block <b>1110</b>, where the source node may send the encrypted root object (e.g. <b>128</b>-<b>1</b>) to the backup node. The backup node may persist the encrypted root object, which may include using the encrypted root object to identify the file system instance on the backup node. In some implementations, block <b>1108</b> may be performed by executing instructions <b>910</b>. If the verifying is unsuccessful (“NO” at block <b>1108</b>), method <b>1100</b> proceeds to block <b>1112</b>, where the source node and/or backup node may return an error message. Method <b>1100</b> may end at block <b>1114</b>.

0110<figref idref="DRAWINGS">FIG. 12</figref> is a flow diagram depicting an example method <b>1200</b>. Method <b>1200</b> starts at block <b>1202</b> and continues to block <b>1204</b>, where a node receives a selection of a file system instance to be cryptographically erased. The node receiving the selection may be a node that either stores or manages the selected file system instance or a backup thereof. The receiving node may transmit instructions indicating that the selected file system instance is to be cryptographically erased to other nodes that may either store or manage the selected file system instance or a backup thereof. The receiving node may identify a selected MEK that corresponds to the selected file system instance. The selected MEK may be among a plurality of different MEKs that encrypted respective root objects of a plurality of different file system instances and backups thereof.

0111At block <b>1206</b>, the node may delete the selected MEK to cryptographically erase the selected file system instance and any associated backup of the selected file system instance, without affecting, modifying, or otherwise disrupting any other file system instance or backups associated with the same security domain. To illustrate with reference to <figref idref="DRAWINGS">FIG. 7</figref>, MEK <b>732</b>-<b>1</b> may be deleted to cryptographically erase file system instance <b>122</b>-<b>1</b> and backup-1 <b>144</b>-<b>1</b>. In some implementations, block <b>1206</b> may be performed by executing instructions <b>912</b> described above. Method <b>1200</b> may end at block <b>1208</b>.

0112In some implementations, systems described herein (e.g., node-1 <b>110</b>, systems <b>300</b>, <b>400</b>, <b>800</b>, <b>900</b>) may include additional functionality, which may be implemented as instructions encoded on a non-transitory machine readable medium executable by a processing resource. For example, the machine readable medium may include instructions to decrypt a backup file system instance using an associated DEK and MEK. The instructions to decrypt a backup may include instructions to unwrap the DEK using a KEK that is available to a system by virtue of the cluster membership(s) of the system and to unwrap the MEK using the unwrapped DEK. If the system is not a member of the cluster associated with the KEK, then the DEK cannot be unwrapped and decryption will fail. On the other hand, if DEK and MEK unwrapping are successful, control may pass to instructions to use the unwrapped MEK to unencrypt a root object of the backup. The unencrypted root object can be used by the data virtualization platform to traverse the file system instance to reach encrypted data objects at the leaf level. Decryption may be useful in various read or restore scenarios. For example, specific encrypted data objects may be addressed by a read request (e.g., addressed by inode and subtree offset). As another example, the data virtualization platform may be restoring a part or the whole of the backup file system instance. The encrypted data objects may be decrypted using the DEK.

0113In some cases, the system may be attempting to restore a backup file system instance to a different security domain. In such a case, the system may execute instructions to unwrap the DEK (and MEK if applicable) using the KEK and decrypt the backup file system instance. Then, the decrypted backup file system instance or a copy thereof (i.e., via a deep copy) may be reencrypted using a different DEK associated with the different security domain.

0114In some cases, the system may be attempting to restore a backup file system instance of a foreign cluster, that is, a cluster of which the system is not a member. In this example, the system may be deemed a remote node relative to the foreign cluster, which may also be deemed the source cluster in this instance. In such cases, the system may not have access to the KEK associated with the foreign cluster to unwrap a DEK associated with that backup file system instance. The system may execute instructions to send the wrapped DEK back to the foreign cluster and request access to the backup file system instance. The foreign cluster may authenticate the system and authorize the system to access the backup file system instance. If the system is authenticated and authorized, the foreign cluster may unwrap the DEK using the KEK of the foreign cluster and return to the system the unwrapped DEK encrypted using a public key of the system. The system may then execute instructions to decrypt the DEK using a private key and then execute instructions to rewrap the decrypted DEK using a KEK available to the system (i.e., a KEK of the cluster to which the system belongs). The system may now have access to the backup file system instance. In some implementations, the system may execute instructions to perform a deep copy of the backup file system instance to create a new file system instance (i.e., copying all decrypted data objects and copying or recreating the metadata objects referencing the decrypted data objects) and encrypt the new file system instance using a new DEK wrapped under the KEK available to the system. In this manner, the system may copy a backup file system instance of a foreign cluster into a new security domain in a cluster to which the system belongs.

0115In the foregoing description, numerous details are set forth to provide an understanding of the subject matter disclosed herein. However, implementation may be practiced without some or all of these details. Other implementations may include modifications, combinations, and variations from the details discussed above. It is intended that the following claims cover such modifications and variations.