Encrypting replication journals in a storage system

Abstract

Described embodiments provide systems and methods for encrypting journal data of a storage system. At least one key is generated, each key having an associated key identifier. The at least one key and the associated key identifiers are stored to a key store. User data is read from a replica volume of the storage system. The read user data is encrypted with an associated key. Encrypted data is written to a journal associated with the replica volume. The key identifier of the associated key is written to the journal.

Description

BACKGROUND

A distributed storage system may include a plurality of storage devices (e.g., storage arrays) to provide data storage to a plurality of nodes. The plurality of storage devices and the plurality of nodes may be situated in the same physical location, or in one or more physically remote locations. A distributed storage system may include data protection systems that back up production site data by replicating production site data on a secondary backup storage system. The production site data may be replicated on a periodic basis and/or may be replicated as changes are made to the production site data. The backup storage system may be situated in the same physical location as the production storage system, or in a physically remote location.

SUMMARY

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

One aspect provides a method of encrypting journal data of a storage system. At least one key is generated, each key having an associated key identifier. The at least one key and the associated key identifiers are stored to a key store. User data is read from a replica volume of the storage system. The read user data is encrypted with an associated key. Encrypted data is written to a journal associated with the replica volume. The key identifier of the associated key is written to the journal.

Another aspect provides a system that includes a processor and memory storing computer program code that when executed on the processor causes the processor to operate a storage system. The storage system is operable to perform the operations of encrypting journal data of a storage system. At least one key is generated, each key having an associated key identifier. The at least one key and the associated key identifiers are stored to a key store. User data is read from a replica volume of the storage system. The read user data is encrypted with an associated key. Encrypted data is written to a journal associated with the replica volume. The key identifier of the associated key is written to the journal.

Another aspect provides a computer program product including a non-transitory computer readable storage medium having computer program code encoded thereon that when executed on a processor of a computer causes the computer to operate a storage system. The computer program product includes computer program code for encrypting journal data of a storage system. At least one key is generated, each key having an associated key identifier. The at least one key and the associated key identifiers are stored to a key store. User data is read from a replica volume of the storage system. The read user data is encrypted with an associated key. Encrypted data is written to a journal associated with the replica volume. The key identifier of the associated key is written to the journal.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

Objects, aspects, features, and advantages of embodiments disclosed herein will become more fully apparent from the following detailed description, the appended claims, and the accompanying drawings in which like reference numerals identify similar or identical elements. Reference numerals that are introduced in the specification in association with a drawing figure may be repeated in one or more subsequent figures without additional description in the specification in order to provide context for other features. For clarity, not every element may be labeled in every figure. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments, principles, and concepts. The drawings are not meant to limit the scope of the claims included herewith.

FIG. 1 is a block diagram of a data protection system, according to an illustrative embodiment of the instant disclosure;

FIG. 2 is a diagram illustrating a journal history of write transactions for the data protection system of FIG. 1, according to an illustrative embodiment of the instant disclosure;

FIG. 3 is a block diagram of an example of a data protection system to perform snapshot replication on a storage system, according to an illustrative embodiment of the instant disclosure;

FIG. 4 is a flowchart of an example of a process to generate encryption keys, according to an illustrative embodiment of the instant disclosure;

FIG. 5 is a flowchart of an example of a process to write encrypted journal data, according to an illustrative embodiment of the instant disclosure;

FIG. 6 is a flowchart of an example of a process to access encrypted journal data, according to an illustrative embodiment of the instant disclosure;

FIG. 7 is a flowchart of an example of a process to delete encrypted journal data, according to an illustrative embodiment of the instant disclosure;

FIG. 8 is a flowchart of an example of a process to perform garbage collection of deleted journal data, according to an illustrative embodiment of the instant disclosure; and

FIG. 9 is a block diagram of an example of a hardware device that may perform at least a portion of the processes in FIGS. 4-8.

DETAILED DESCRIPTION

Before describing embodiments of the concepts, structures, and techniques sought to be protected herein, some terms are explained. In some embodiments, the term “I/O request” or simply “I/O” may be used to refer to an input or output request. In some embodiments, an I/O request may refer to a data read or data write request. In some embodiments, the term “storage system” may encompass physical computing systems, cloud or virtual computing systems, or a combination thereof. In some embodiments, the term “storage device” may refer to any non-volatile memory (NVM) device, including hard disk drives (HDDs), solid state drivers (SSDs), flash devices (e.g., NAND flash devices), and similar devices that may be accessed locally and/or remotely (e.g., via a storage attached network (SAN)). In some embodiments, the term “storage device” may also refer to a storage array including multiple storage devices.

Referring to the example embodiment shown in FIG. 1, a data protection system 100 may include two sites, Site I 100a and Site II 100b, which communicate via a wide area network (WAN) 128, such as the Internet. In some embodiments, under normal operation, Site I 100a may correspond to a source site (i.e., the transmitter within a data replication workflow) of system 100 and Site II 100b may be a target site (i.e., the receiver within a data replication workflow) of data protection system 100. Thus, in some embodiments, during normal operations, the direction of replicated data flow may be from Site I 100a to Site II 100b.

In certain embodiments, Site I 100a and Site II 100b may be remote from one another. In other embodiments, Site I 100a and Site II 100b may be local to one another and may be connected via a local area network (LAN). In some embodiments, local data protection may have the advantage of minimizing data lag between target and source, and remote data protection may have the advantage of being robust in the event that a disaster occurs at the source site.

In particular embodiments, data protection system 100 may include a failover mode of operation, wherein the direction of replicated data flow is reversed. In particular, in some embodiments, Site I 100a may behave as a target site and Site II 100b may behave as a source site. In some embodiments, failover may be triggered manually (e.g., by a user) or automatically. In many embodiments, failover may be performed in the event of a disaster at Site I 100a. In some embodiments, both Site I 100a and Site II 100b may behave as source site for some stored data and may behave simultaneously as a target site for other stored data. In certain embodiments, a portion of stored data may be replicated from one site to the other, and another portion may not be replicated.

In some embodiments, Site I 100a corresponds to a production site (e.g., a facility where one or more hosts run data processing applications that write data to a storage system and read data from the storage system) and Site II 100b corresponds to a backup or replica site (e.g., a facility where replicated production site data is stored). Thus, in some embodiments, Site II 100b may be responsible for replicating production site data and may enable rollback of data of Site I 100a to an earlier point in time. In some embodiments, rollback may be used in the event of data corruption of a disaster, or alternatively in order to view or to access data from an earlier point in time.

Described embodiments of Site I 100a may include a source host 104, a source storage system (or “storage array”) 108, and a source data protection appliance (DPA) 112 coupled via a first storage area network (SAN). Similarly, in some embodiments, Site II 100b may include a target host 116, a target storage system 120, and a target DPA 124 coupled via a second SAN. In some embodiments, each SAN may include one or more devices (or “nodes”) that may be designated an “initiator,” a “target”, or both. For example, in some embodiments, the first SAN may include a first fiber channel switch 148 and the second SAN may include a second fiber channel switch 168. In some embodiments, communication links between each host 104 and 116 and its corresponding storage system 108 and 120 may be any appropriate medium suitable for data transfer, such as fiber communication channel links. In many embodiments, a host communicates with its corresponding storage system over a communication link, such as an InfiniBand (TB) link or Fibre Channel (FC) link, and/or a network, such as an Ethernet or Internet (e.g., TCP/IP) network that may employ, for example, the iSCSI protocol.

In some embodiments, each storage system 108 and 120 may include storage devices for storing data, such as disks or arrays of disks. Typically, in such embodiments, storage systems 108 and 120 may be target nodes. In some embodiments, in order to enable initiators to send requests to storage system 108, storage system 108 may provide (e.g., expose) one or more logical units (LU) to which commands are issued. Thus, in some embodiments, storage systems 108 and 120 may be SAN entities that provide multiple logical units for access by multiple SAN initiators. In some embodiments, an LU is a logical entity provided by a storage system for accessing data stored therein. In some embodiments, a logical unit may be a physical logical unit or a virtual logical unit. In some embodiments, a logical unit may be identified by a unique logical unit number (LUN).

In the embodiment shown in FIG. 1, storage system 108 may expose logical unit 136, designated as LU A, and storage system 120 exposes logical unit 156, designated as LU B. LU B 156 may be used for replicating LU A 136. In such embodiments, LU B 156 may be generated as a copy of LU A 136. In one embodiment, LU B 156 may be configured so that its size is identical to the size of LU A 136.

As shown in FIG. 1, in some embodiments, source host 104 may generate a host device 140 (“Device A”) corresponding to LU A 136 and source host 116 may generate a host device 160 (“Device B”) corresponding to LU B 156. In some embodiments, a host device may be a logical entity within a host through which the host may access an LU. In some embodiments, an operating system of a host may generate a host device for each LU exposed by the storage system in the host SAN.

In some embodiments, source host 104 may act as a SAN initiator that issues I/O requests through host device 140 to LU A 136 using, for example, SCSI commands. In some embodiments, such requests may be transmitted to LU A 136 with an address that includes a specific device identifier, an offset within the device, and a data size.

In some embodiments, source DPA 112 and target DPA 124 may perform various data protection services, such as data replication of a storage system, and journaling of I/O requests issued by hosts 104 and/or 116. In some embodiments, when acting as a target DPA, a DPA may also enable rollback of data to an earlier point-in-time (PIT), and enable processing of rolled back data at the target site. In some embodiments, each DPA 112 and 124 may be a physical device, a virtual device, or may be a combination of a virtual and physical device.

In some embodiments, a DPA may be a cluster of such computers. In some embodiments, use of a cluster may ensure that if a DPA computer is down, then the DPA functionality switches over to another computer. In some embodiments, the DPA computers within a DPA cluster may communicate with one another using at least one communication link suitable for data transfer, for example, an InfiniBand (IB) link, a Fibre Channel (FC) link, and/or a network link, such as an Ethernet or Internet (e.g., TCP/IP) link to transfer data via fiber channel or IP based protocols, or other such transfer protocols. In some embodiments, one computer from the DPA cluster may serve as the DPA leader. In some embodiments, the DPA cluster leader may coordinate between the computers in the cluster, and may also perform other tasks that require coordination between the computers, such as load balancing.

In certain embodiments, a DPA may be a standalone device integrated within a SAN. Alternatively, in some embodiments, a DPA may be integrated into storage system. In some embodiments, the DPAs communicate with their respective hosts through communication links suitable for data transfer, for example, an InfiniBand (IB) link, a Fibre Channel (FC) link, and/or a network link, such as an Ethernet or Internet (e.g., TCP/IP) link to transfer data via, for example, SCSI commands or any other protocol.

In various embodiments, the DPAs may act as initiators in the SAN. For example, in some embodiments, the DPAs may issue I/O requests using, for example, SCSI commands, to access LUs on their respective storage systems. In some embodiments, each DPA may also be configured with the necessary functionality to act as targets, e.g., to reply to I/O requests, such as SCSI commands, issued by other initiators in the SAN, including their respective hosts. In some embodiments, being target nodes, the DPAs may dynamically expose or remove one or more LUs. As described herein, in some embodiments, Site I 100a and Site II 100b may each behave simultaneously as a production site and a backup site for different logical units. As such, in some embodiments, DPA 112 and DPA 124 may each behave as a source DPA for some LUs and as a target DPA for other LUs, at the same time.

In the example embodiment shown in FIG. 1, hosts 104 and 116 include protection agents 144 and 164, respectively. In some embodiments, protection agents 144 and 164 may be intercept commands (e.g., SCSI commands) issued by their respective hosts to LUs via host devices (e.g., host devices 140 and 160). In some embodiments, a protection agent may act on intercepted SCSI commands issued to a logical unit in one of the following ways: send the SCSI commands to its intended LU; redirect the SCSI command to another LU; split the SCSI command by sending it first to the respective DPA and, after the DPA returns an acknowledgement, send the SCSI command to its intended LU; fail a SCSI command by returning an error return code; and delay a SCSI command by not returning an acknowledgement to the respective host. In some embodiments, protection agents 144 and 164 may handle different SCSI commands, differently, according to the type of the command. For example, in some embodiments, a SCSI command inquiring about the size of a certain LU may be sent directly to that LU, whereas a SCSI write command may be split and sent first to a DPA within the host's site.

In various embodiments, a protection agent may change its behavior for handling SCSI commands, for example as a result of an instruction received from the DPA. For example, in some embodiments, the behavior of a protection agent for a certain host device may depend on the behavior of its associated DPA with respect to the LU of the host device. In some embodiments, when a DPA behaves as a source site DPA for a certain LU, then during normal course of operation, the associated protection agent may split I/O requests issued by a host to the host device corresponding to that LU. Similarly, in some embodiments, when a DPA behaves as a target device for a certain LU, then during normal course of operation, the associated protection agent fails I/O requests issued by host to the host device corresponding to that LU.

In some embodiments, communication between protection agents 144 and 164 and a respective DPA 112 and 124 may use any protocol suitable for data transfer within a SAN, such as fiber channel, SCSI over fiber channel, or other protocols. In some embodiments, the communication may be direct, or via a logical unit exposed by the DPA.

In certain embodiments, protection agents may be drivers located in their respective hosts. Alternatively, in some embodiments, a protection agent may also be located in a fiber channel switch, or in any other device situated in a data path between a host and a storage system or on the storage system itself. In some embodiments, in a virtualized environment, the protection agent may run at the hypervisor layer or in a virtual machine providing a virtualization layer.

As shown in the example embodiment shown in FIG. 1, target storage system 120 may expose a journal LU 176 for maintaining a history of write transactions made to LU B 156, referred to herein as a “journal.” In some embodiments, a journal may be used to provide access to storage at specified points-in-time (PITs), as discussed in greater detail in regard to FIG. 2. In some embodiments, the journal may be stored across multiple LUs (e.g., using striping, etc.). In some embodiments, target DPA 124 may include a journal processor 180 for managing the journal within journal LU 176. Referring back to the example embodiment of FIG. 1, journal processor 180 may manage the journal entries of LU B 156. Specifically, in some embodiments, journal processor 180 may enter write transactions received by the target DPA 124 from the source DPA 112 into the journal by writing them into journal LU 176, read the undo information for the transaction from LU B 156, update the journal entries in journal LU 176 with undo information, apply the journal transactions to LU B 156, and remove already-applied transactions from the journal. In one embodiment, journal processor 180 may perform processing such as described in the patent titled “METHODS AND APPARATUS FOR OPTIMAL JOURNALING FOR CONTINUOUS DATA REPLICATION” and with U.S. Pat. No. 7,516,287, issued Apr. 7, 2009, which is hereby incorporated by reference.

Some embodiments of data protection system 100 may be provided as physical systems for the replication of physical LUs, or as virtual systems for the replication of virtual LUs. For example, in one embodiment, a hypervisor may consume LUs and may generate a distributed file system on the logical units such as Virtual Machine File System (VMFS) that may generate files in the file system and expose the files as LUs to the virtual machines (each virtual machine disk is seen as a SCSI device by virtual hosts). In another embodiment, a hypervisor may consume a network based file system and exposes files in the Network File System (NFS) as SCSI devices to virtual hosts.

In some embodiments, in normal operation (sometimes referred to as “production mode”), DPA 112 may act as a source DPA for LU A 136. Thus, in some embodiments, protection agent 144 may act as a source protection agent, specifically by splitting I/O requests to host device 140 (“Device A”). In some embodiments, protection agent 144 may send an I/O request to source DPA 112 and, after receiving an acknowledgement from source DPA 112, may send the I/O request to LU A 136. In some embodiments, after receiving an acknowledgement from storage system 108, host 104 may acknowledge that the I/O request has successfully completed.

In some embodiments, when source DPA 112 receives a replicated I/O request from protection agent 144, source DPA 112 may transmit certain I/O information characterizing the write request, packaged as a “write transaction”, over WAN 128 to target DPA 124 for journaling and for incorporation within target storage system 120. In some embodiments, when applying write operations to storage system 120, target DPA 124 may act as an initiator, and may send SCSI commands to LU B 156.

In some embodiments, source DPA 112 may send its write transactions to target DPA 124 using a variety of modes of transmission, including (i) a synchronous mode, (ii) an asynchronous mode, and (iii) a snapshot mode.

In some embodiments, in synchronous mode, source DPA 112 may send each write transaction to target DPA 124, may receive back an acknowledgement from the target DPA 124, and in turn may send an acknowledgement back to protection agent 144. In some embodiments, in synchronous mode, protection agent 144 may wait until receipt of such acknowledgement before sending the I/O request to LU 136. In some embodiments, in asynchronous mode, source DPA 112 may send an acknowledgement to protection agent 144 upon receipt of each I/O request, before receiving an acknowledgement back from target DPA 124.

In some embodiments, in snapshot mode, source DPA 112 may receive several I/O requests and combine them into an aggregate “snapshot” or “batch” of write activity performed in the multiple I/O requests, and may send the snapshot to target DPA 124 for journaling and incorporation in target storage system 120. In some embodiments, in snapshot mode, source DPA 112 may send an acknowledgement to protection agent 144 upon receipt of each I/O request, before receiving an acknowledgement back from target DPA 124.

In some embodiments, a snapshot replica may be a differential representation of a volume. For example, the snapshot may include pointers to the original volume, and may point to log volumes for locations of the original volume that store data changed by one or more I/O requests. In some embodiments, snapshots may be combined into a snapshot array, which may represent different images over a time period (e.g., for multiple PITs).

As described herein, in some embodiments, in normal operation, LU B 156 may be used as a backup of LU A 136. As such, while data written to LU A 136 by host 104 is replicated from LU A 136 to LU B 156, target host 116 should not send I/O requests to LU B 156. In some embodiments, to prevent such I/O requests from being sent, protection agent 164 may act as a target site protection agent for host device B 160 and may fail I/O requests sent from host 116 to LU B 156 through host device B 160. In some embodiments, in a recovery mode, target DPA 124 may undo the write transactions in journal LU 176 so as to restore the target storage system 120 to an earlier state.

Referring to FIG. 2, in some described embodiments, a write transaction 200 may be included within a journal and stored within a journal LU. In some embodiments, write transaction 200 may include one or more identifiers; a time stamp indicating the date and time at which the transaction was received by the source DPA; a write size indicating the size of the data block; a location in the journal LU where the data is entered; a location in the target LU where the data is to be written; and the data itself.

Referring to both FIGS. 1 and 2, in some embodiments, transaction 200 may correspond to a transaction transmitted from source DPA 112 to target DPA 124. In some embodiments, target DPA 124 may record write transaction 200 in the journal that includes four streams. In some embodiments, a first stream, referred to as a “DO” stream, includes a copy of the new data for writing to LU B 156. In some embodiments, a second stream, referred to as a “DO METADATA” stream, includes metadata for the write transaction, such as an identifier, a date and time, a write size, the offset within LU B 156 where the new data is written, and a pointer to the offset in the DO stream where the corresponding data is located. In some embodiments, a third stream, referred to as an “UNDO” stream, includes a copy of the data being overwritten within LU B 156 (referred to herein as the “old” data). In some embodiments, a fourth stream, referred to as an “UNDO METADATA” stream, includes an identifier, a date and time, a write size, a beginning address in LU B 156 where data was (or will be) overwritten, and a pointer to the offset in the UNDO stream where the corresponding old data is located.

Since the journal contains the “undo” information necessary to rollback storage system 120, in some embodiments, data that was stored in specific memory locations at a specified point in time may be obtained by undoing write transactions that occurred subsequent to such point in time (PIT).

In some embodiments, each of the four streams may hold a plurality of write transaction data. In some embodiments, as write transactions are received dynamically by the target DPA, the write transactions may be recorded at the end of the DO stream and the end of the DO METADATA stream, prior to committing the transaction.

In some embodiments, a metadata stream (e.g., UNDO METADATA stream or the DO METADATA stream) and the corresponding data stream (e.g., UNDO stream or DO stream) may be kept in a single stream by interleaving metadata and data.

Some described embodiments may validate that point-in-time (PIT) data replicas (e.g., data replicated to LU B 156) are valid and usable, for example to verify that the data replicas are not corrupt due to a system error or inconsistent due to violation of write order fidelity. In some embodiments, validating data replicas can be important, for example, in data replication systems employing incremental backup where an undetected error in an earlier data replica may lead to corruption of future data replicas.

Referring to FIG. 3, in an illustrative embodiment, a data protection system 300 may include host 302a, host 302b, backup storage system 304 (e.g., a deduplicated storage system) and a datastore 306. In some embodiments, host 302a may include production virtual machine 310 and splitter 314 (e.g., data protection agent 144 of FIG. 1). In some embodiments, host 302b may be a hypervisor and splitter 314 may operate either in the hypervisor kernel or in another layer in the hypervisor, which allows splitter 314 to intercept I/O requests sent from host 302a to one or more virtual machine disks (VMDKs) 342. In some embodiments, host 302b may include a virtual data protection appliance (e.g., DPA appliance 124 of FIG. 1) having snapshot replication module 320 and splitter 334 (e.g., data protection agent 164 of FIG. 1). In an embodiment, splitter 334 of host 302b enables protection of virtual machines on the host 302b. In some embodiments, splitter 334 of host 302b may also provide faster access to VMDKs 342 from virtual DPA (vDPA) 316.

In an embodiment, datastore 306 may include one or more production virtual machine disks, shown as production VMDK 342, and one or more differential virtual machine disks, shown as differential VMDKs 346. Some embodiments of datastore 306 may also include journal virtual machine disk 348. In some embodiments, the differential VMDKs 346 may be used to store differential snapshot data representative of changes that happened to data stored on production VMDK 342. In one example, a first differential VMDK 346 may include changes due to writes that occurred to production VMDK 342 from time t1 to time t2, a second differential VMDK 346 may include the changes due to writes that occurred to production VMDK 342 from time t2 to time t3, and so forth.

In some embodiments, differential VMDKs 346 may be thin provisioned. Thin provisioning allocates storage space to volumes of a SAN in a flexible manner among multiple volumes based on a minimum space requirement for each volume at any given time. In some embodiments, production VMDK 342, one or more differential VMDKs 346, and one or more snapshot replicas stored on storage system 304 may form a consistency group. In some embodiments, a consistency group may treat source volumes (e.g., production volumes) and target volumes (e.g., backup volumes) as a single logical entity for data replication and migration.

In some embodiments, journal 352 may be stored in journal VMDK 348. Journal 352 includes one or more delta marker streams (DMS) 362. In some embodiments, each DMS 362 may include metadata associated with data that may be different between one differential VMDK and another differential VMDK. In one example, DMS 362 may include the metadata differences between a current copy of the production VMDK 342 and a copy currently stored in backup storage 304. In some embodiments, journal 352 does not include the actual data changes, but rather metadata associated with the changes. In some embodiments, the data of the changes may be stored in the differential VMDKs.

Although not shown in FIG. 3, in some embodiments, host 302b, datastore 306 and backup storage system 304 may be integrated into a single device, such as an integrated protection appliance to backup and protect production data.

As described herein, some embodiments may employ journals (e.g., the DO and UNDO METADATA of FIG. 2) to maintain a history of replica copies. This history may be employed when a replica copy is used by the data protection system to roll back a volume to a specific point in time (PIT). In some embodiments, the history data may be stored on journal volumes (e.g., journal VMDK 348).

In some embodiments, in synchronous mode (e.g., continuous replication), the size of the journal may be related to a recovery time objective (RTO) and/or a recovery point objective (RPO) of data protection system 100. For example, the size of the journal may be related to a size of a protection window of the data protection system. In some embodiments, the protection window may determine a range of PITs to which volumes may be rolled back. In some systems, expired PIT replicas may be deleted to allow space in the journal volume to save new PIT replicas.

In some instances, since journal data represents data changed on a production volume, the journal data may contain sensitive information and, as such, could represent a security vulnerability of the data protection system if the journal data were to be accessed indirectly (e.g., by a device that is not an authorized component of the data protection system). The security vulnerability could be especially important in embodiments employing virtual or cloud storage volumes to store replica data.

Some embodiments of data protection system 100 may employ one or more encryption keys to encrypt journal data (e.g., journal 352 and/or DMS 362) and/or journal volumes (e.g., journal VMDK 348). Some embodiments may periodically change the encryption keys employed to encrypt journal data (for example, the UNDO METADATA of FIG. 2) to enable efficient control of the protection window. For example, described embodiments may periodically generate new encryption keys. In some embodiments, each key may be used to encrypt data that is read from a replica copy volume (e.g., differential VMDK 346) before it is written to the undo stream of an associated journal (e.g., journal 352).

In some embodiments, a given encryption key may be destroyed after a determined time (e.g., after the protection window expires), making older data in the journal unusable since it can no longer be decrypted. In some embodiments, for example if the replica copy volume (e.g., differential VMDK 346) is located in a hostile, uncontrolled, and/or third-party environment, asymmetric encryption (e.g., public key encryption) may be employed. For example, the replica site may be provided access only to a public encryption key. The data protection system may maintain a private decryption key to decrypt journal data (and/or replicas).

Referring to FIG. 4, a flowchart of an example process, 400, is shown for generating encryption keys by data protection system 100. At block 402, key generation process 400 begins. In some embodiments, at block 404, a key expiration period of the system may be set. For example, data protection system 100 may periodically generate new encryption key(s). Some embodiments may allow a user of data protection system 100 to configure the key expiration period, for example as a number of hours, days, etc. In some embodiments, the key expiration period may be selected based upon the replica protection window. In an illustrative embodiment, a key expiration period of one hour may be employed.

In some embodiments, at block 406, one or more new encryption and/or decryption keys are generated. For example, some embodiments may employ public-private key pairs (e.g., for asymmetric encryption), and some embodiments may employ a unique key (or key pair) for each volume. In some embodiments, at block 408, each key is associated with a unique identifier (key ID). In some embodiments, the mapping between the key ID and the key may be managed by a secure key manager of data protection system 100 (e.g., vDPA 316 of FIG. 3). In embodiments employing asymmetric encryption, the public key may be used to encrypt data and may be written to the undo stream as a key ID. In some embodiments, the private key may be used to decrypt data and be stored in the secure key manager and be identified based on the public key (e.g., key ID).

In some embodiments, at block 410, the key expiration period is started. In some embodiments, during this period, one or more replicas and/or associated journal data may be encrypted using the key(s) generated at block 406. For example, the keys generated at block 406 may be used to encrypt data that is read from the replica volume and written to the journal (e.g., the UNDO METADATA). In some embodiments, the corresponding key ID may also be written to the journal data (e.g., the UNDO METADATA). In some embodiments, at block 412, when the key expiration period is reached, process 400 returns to block 406 to generate one or more new keys.

In some embodiments, in continuous replication (e.g., synchronous mode), most history data in the journal is in the undo stream (e.g., indicating data changes between replicas). Thus, some described embodiments encrypt data before writing to the undo stream (e.g., the UNDO METADATA). Referring to FIG. 5, an example process, 500, for writing journal data is shown. At block 502, process 500 begins. In some embodiments, at block 504, data may be read from a replica volume, and at block 506, the read data may be encrypted with an associated key. For example, in reference to FIG. 3, vDPA 316 may read data from a differential VDMK 346, and encrypt the read data with an associated key. In some embodiments, at block 508, the encrypted data may be written to an associated journal (e.g., journal 352 of FIG. 3). In some embodiments, at block 510, a key ID associated with the key used to encrypt the journal data may also be written to the journal. At block 512, process 500 completes.

In some embodiments, once data is written to the journal (e.g., the UNDO METADATA), the data may be decrypted to roll back a production volume to a PIT, based upon the undo data. Referring to FIG. 6, a flowchart of an example process, 600, to access the journal data is shown. At block 602, process 600 begins, for example when data protection system 100 begins to roll back to a previous PIT replica. In some embodiments, at block 604, the encrypted journal data is read (e.g., by vDPA 316 of FIG. 3). In some embodiments, at block 606, the key ID of the encryption key is determined from the encrypted journal data read at block 604. In some embodiments, at block 608, the decryption key is retrieved (e.g., from a secure key manager of vDPA 316) based upon the determined key ID. In some embodiments, at block 610, the encrypted journal data is decrypted using the retrieved decryption key. In some embodiments, at block 612, the decrypted journal data is written to a replica. In some embodiments, at block 614, the decrypted journal data is written to a journal to roll back the production volume (e.g., to the DO METADATA). At block 616, process 600 completes.

In some embodiments, when a PIT replica expires (e.g., the protection window expires, the journal volume becomes full, etc.), the expired replica and associated expired journal data may be deleted. Referring to FIG. 7, a flowchart of an example process, 700, to delete encrypted journal data is shown. At block 702, process 700 begins. In some embodiments, at block 704, the key(s) associated with the key ID of the expired journal data is deleted. In some embodiments, deleting the key(s) associated with the expired journal data makes the expired journal data inaccessible. At block 706, process 700 completes.

In some embodiments, deleting a key associated with an expired PIT, makes the expired journal data inaccessible (since it can no longer be decrypted), but the inaccessible data is still stored in the journal (e.g., the UNDO METADATA). Thus, some described embodiments may perform periodic “garbage collection” to delete journal data associated with expired/deleted keys. For example, the garbage collection may be performed as a background process during otherwise idle time of data protection system 100.

Referring to FIG. 8, a flowchart of an example process, 800, to perform garbage collection of journal data is shown. At block 802, process 800 begins. In some embodiments, at block 804, if the key(s) associated with the journal data have been deleted, then at block 806, the inaccessible journal data is deleted, and process 800 continues to block 808. Otherwise, at block 806, if the key(s) associated with the journal data have not been deleted, process 800 continues to block 808. At block 808, process 800 completes.

As described herein, illustrative embodiments may provide a fast and efficient manner to deny access to old PIT data by permanently delete a decryption key (e.g., as shown in FIG. 7). This is a fast operation that does not require access to the storage array (e.g., only to the key manager). Thus, some described embodiments can still invalidate expired PIT data even if access to the storage array was lost. For example, a hacker could not prevent the expiration of old data by preventing communication between data protection system (e.g., host 302b of FIG. 3) and the storage array (e.g., datastore 306). Further, by deleting the decryption key, old PIT data may be simultaneously invalidated across multiple replica copies in multi-copy replication system.

In some described embodiments, host devices (e.g., hosts 104 and 116 of FIG. 1 or hosts 302a and 302b of FIG. 3) may each correspond to one computer, a plurality of computers, or a network of distributed computers. For example, in some embodiments, a host device may be implemented as one or more computers such as shown in FIG. 9. As shown in FIG. 9, computer 900 may include processor 902, volatile memory 904 (e.g., RAM), non-volatile memory 906 (e.g., one or more hard disk drives (HDDs), one or more solid state drives (SSDs) such as a flash drive, one or more hybrid magnetic and solid state drives, and/or one or more virtual storage volumes, such as a cloud storage, or a combination of physical storage volumes and virtual storage volumes), graphical user interface (GUI) 908 (e.g., a touchscreen, a display, and so forth) and input/output (I/O) device 920 (e.g., a mouse, a keyboard, etc.). Non-volatile memory 906 stores computer instructions 912, an operating system 916 and data 918 such that, for example, the computer instructions 912 are executed by the processor 902 out of volatile memory 904 to perform at least a portion of the processes shown in FIGS. 4-8. Program code may be applied to data entered using an input device of GUI 908 or received from I/O device 920.

The processes shown in FIGS. 4-8 are not limited to use with the hardware and software of FIG. 7 and may find applicability in any computing or processing environment and with any type of machine or set of machines that may be capable of running a computer program. The processes may be implemented in hardware, software, or a combination of the two.

The processes described herein are not limited to the specific embodiments described. For example, the processes are not limited to the specific processing order shown in FIGS. 4-8. Rather, any of the blocks of the processes may be re-ordered, combined or removed, performed in parallel or in serial, as necessary, to achieve the results set forth herein.

Processor 902 may be implemented by one or more programmable processors executing one or more computer programs to perform the functions of the system. As used herein, the term “processor” describes an electronic circuit that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations may be hard coded into the electronic circuit or soft coded by way of instructions held in a memory device. A “processor” may perform the function, operation, or sequence of operations using digital values or using analog signals. In some embodiments, the “processor” can be embodied in an application specific integrated circuit (ASIC). In some embodiments, the “processor” may be embodied in a microprocessor with associated program memory. In some embodiments, the “processor” may be embodied in a discrete electronic circuit. The “processor” may be analog, digital or mixed-signal. In some embodiments, the “processor” may be one or more physical processors and/or one or more “virtual” (e.g., remotely located or “cloud”) processors.

Various functions of circuit elements may also be implemented as processing blocks in a software program. Such software may be employed in, for example, one or more digital signal processors, microcontrollers, or general purpose computers. Described embodiments may be implemented in hardware, a combination of hardware and software, software, or software in execution by one or more physical or virtual processors.

Some embodiments may be implemented in the form of methods and apparatuses for practicing those methods. Described embodiments may also be implemented in the form of program code, for example, stored in a storage medium, loaded into and/or executed by a machine, or transmitted over some transmission medium or carrier, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation. A non-transitory machine-readable medium may include but is not limited to tangible media, such as magnetic recording media including hard drives, floppy diskettes, and magnetic tape media, optical recording media including compact discs (CDs) and digital versatile discs (DVDs), solid state memory such as flash memory, hybrid magnetic and solid state memory, non-volatile memory, volatile memory, and so forth, but does not include a transitory signal per se. When embodied in a non-transitory machine-readable medium and the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the method.

When implemented on a processing device, the program code segments combine with the processor to provide a unique device that operates analogously to specific logic circuits. Such processing devices may include, for example, a general purpose microprocessor, a digital signal processor (DSP), a reduced instruction set computer (RISC), a complex instruction set computer (CISC), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic array (PLA), a microcontroller, an embedded controller, a multi-core processor, and/or others, including combinations of one or more of the above. Described embodiments may also be implemented in the form of a bitstream or other sequence of signal values electrically or optically transmitted through a medium, stored magnetic-field variations in a magnetic recording medium, etc., generated using a method and/or an apparatus as recited in the claims.

Various elements, which are described in the context of a single embodiment, may also be provided separately or in any suitable subcombination. It will be further understood that various changes in the details, materials, and arrangements of the parts that have been described and illustrated herein may be made by those skilled in the art without departing from the scope of the following claims.

Claims

1. A method of encrypting journal data of a storage system, the method comprising: generating keys, each of the keys having an associated key identifier;storing the keys and the associated key identifiers to a key store;reading user data from a replica volume of the storage system;encrypting the read user data with one of the keys;writing encrypted user data to a journal associated with the replica volume;writing the key identifier of the key used to the encrypted user data to the journal;determining, from encrypted journal data of the journal, the key identifier of the key corresponding to the encrypted user data;decrypting the encrypted journal data with the key from the key store, the retrieved key corresponding to the key identifier;writing the decrypted journal data to a roll back replica;rolling back a production volume to an earlier point in time based upon the roll back replica; andwriting decrypted journal data to a metadata stream associated with the roll back replica and rolling back the production volume based upon the metadata stream.

2. The method of claim 1, wherein generating the keys comprises generating, periodically based on a key expiration period, at least one new key to replace at least one expired key.

3. The method of claim 1, further comprising: setting, based upon a protection window of the storage system, journal data as expired; anddetermining a key identifier associated with the expired journal data; andpermanently deleting the key associated with the determined key identifier.

4. The method of claim 3, further comprising: periodically performing a garbage collection operation to delete journal data associated with deleted keys.

5. The method of claim 4, wherein the garbage collection operation is performed as a background operation during idle time of the storage system, and wherein the key expiration period is set based upon the protection window.

6. A system comprising: a processor; andmemory storing computer program code that when executed on the processor causes the processor to operate a storage system, the storage system operable to encrypting journal data by performing the operations of: generating keys, each of the keys having an associated key identifier;storing the keys and the associated key identifiers to a key store;reading user data from a replica volume of the storage system;encrypting the read user data with one of the keys;writing encrypted user data to a journal associated with the replica volume;writing the key identifier of the key used to encrypt the user data to the journal;determining, from encrypted journal data of the journal, the key identifier of the key corresponding to the encrypted user data;decrypting the journal data with a key retrieved from the key store;writing the decrypted journal data to a roll back replica;rolling back the production volume to an earlier point in time based upon the roll back replica; andwriting decrypted journal data to a metadata stream associated with the roll back replica and rolling back the production volume based upon the metadata stream.

7. The system of claim 6, wherein the storage system is further operable to perform the operation of generating, periodically based on a key expiration period, at least one new key to replace at least one expired key.

8. The system of claim 6, wherein the storage system is further operable to perform the operations of: setting, based upon a protection window of the storage system, journal data as expired; anddetermining a key identifier associated with the expired journal data; andpermanently deleting the key associated with the determined key identifier.

9. The system of claim 8, wherein the storage system is further operable to perform the operation of: periodically performing a garbage collection operation to delete journal data associated with deleted keys,wherein the garbage collection operation is performed as a background operation during idle time of the storage system, and wherein the key expiration period is set based upon the protection window.

10. A computer program product including a non-transitory computer readable storage medium having computer program code encoded thereon that when executed on a processor of a computer causes the computer to operate a storage system, the computer program product comprising: computer program code for performing operations, comprising:generating keys, each of the keys having an associated key identifier;storing the keys and the associated key identifiers to a key store;reading user data from a replica volume of the storage system;encrypting the read user data with one of the keys;writing encrypted user data to a journal associated with the replica volume;writing the key identifier of the key used to encrypt the user data to the journal; androlling back a production volume of the storage system to an earlier point in time, comprising:determining, from encrypted journal data of the journal, the key identifier of the key corresponding to the encrypted user data;decrypting the journal data with the key from the key store, the retrieved key corresponding to the key identifier;writing the decrypted journal data to a roll back replica;rolling back the production volume to the earlier point in time based upon the roll back replica; andwriting decrypted journal data to a metadata stream associated with the roll back replica and rolling back the production volume based upon the metadata stream.

11. The computer program product of claim 10, further comprising computer program code for generating, periodically based on a key expiration period, at least one new key to replace at least one expired key.

12. The computer program product of claim 10, wherein the computer program code further performs operations comprising: setting, based upon a protection window of the storage system, journal data as expired; anddetermining a key identifier associated with the expired journal data; andpermanently deleting the key associated with the determined key identifier.

13. The computer program product of claim 12, further comprising computer program code for periodically performing a garbage collection operation to delete journal data associated with deleted keys, wherein the garbage collection operation is performed as a background operation during idle time of the storage system, and wherein the key expiration period is set based upon the protection window.