WO2021223852A1

WO2021223852A1 - Device and method for data protection

Info

Publication number: WO2021223852A1
Application number: PCT/EP2020/062415
Authority: WO
Inventors: Assaf Natanzon; Michael Hirsch
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2020-05-05
Filing date: 2020-05-05
Publication date: 2021-11-11
Also published as: CN113906382A

Abstract

The present disclosure relates to a device and method for a production site. An entity is configured to: intercept a plurality of IOs, for writing to a volume of a storage entity at the production site. Further, the entity is configured to aggregate the plurality of IOs. The entity is further configured to store the aggregated IOs as a first object in an object storage at the production site. In this way, a solution to leverage the cloud ability to replicate objects and snapshots, is provided. This disclosure can reduce the need for configuration and may reduce price.

Description

DEVICE AND METHOD FOR DATA PROTECTION

TECHNICAL FIELD

The present disclosure relates to the field of data protection, in particular, to continuous data protection (CDP) systems. The disclosure is concerned with to leveraging a cloud’s ability to replicate snapshots, in order to create a multi-site CDP system. To this end, the present disclosure provides an entity for a production site.

BACKGROUND

CDP refers to backup of computer data by automatically saving a copy of every change made to that data, essentially capturing every version of the data that the user saves. Typically, a CDP system includes the following components: a production volume, a splitter, a local data mover, a remote data mover, a replica volume, and a journal, as shown in FIG. 1.

The production volume refers to a volume being protected, and is located at a production site. The splitter refers to a driver in the data path, which intercepts write input/output (IOs) arriving at the production volume, and sends the IOs to the production volume and a local data mover. The local data mover refers to an appliance or micro- service, which receives the splitter IOs, and sends them to a remote data mover. The remote data mover refers to an appliance receiving the IOs from the local data mover, and writes them to the remote copy of the replicated volume and to a journal. The replica volume refers to a full copy of the production volume, and is located at a replica site. The system may maintain multiple snapshots of the replica volume at various points in time, to allow recovery to multiple points in time. The journal contains the log of changes applied to the volume. The changes from the journal can be applied to the replica volume as well.

The workflow may comprise a sequence of tasks that process IOs. This includes that IOs are sent from the splitter to a local data mover, the local data mover compresses and packages the IOs and sends them to a remote data mover, and the remote data mover writes the IOs to a journal and applies them from the journal to a replica volume.

Generally, conventional CDP systems have the requirement for a public IP for the connection between the local data mover to the replica appliance. This is common to all known CDP systems. In addition, conventional CDP systems also need a data mover on the replica site. This requires computation resources on the replica site, which are expensive.

SUMMARY

In view of the above-mentioned challenges, embodiments of the disclosure aim to provide an entity and a method for a production site. An objective is, in particular, to leverage the ability of a cloud to replicate objects and snapshots, in order to enable a multi-site CDP system without any need for compute nodes. It is desired to only use the compute node during restore operations and only for limited amount of time. One aim is to reduce the cost for compute nodes.

The objective is achieved by the embodiments of the disclosure as described in the enclosed independent claims. Advantageous implementations of the embodiments of the disclosure are further defined in the dependent claims.

A first aspect of the present disclosure provides an entity for a production site, the entity being configured to: intercept a plurality of IOs, for writing to a volume of a storage entity at the production site; aggregate the plurality of IOs; store the aggregated IOs as a first object in an object storage at the production site.

Embodiments of this disclosure propose to aggregate a plurality of IOs, and to write them, e.g. as a group, i.e., as an object, to the object storage. Notably, the IOs are writing to production volume immediately upon arrival, and periodically a snapshot of the production volume may be created.

In an implementation form of the first aspect, the entity is configured to: obtain a notification, to start intercepting the plurality of IOs in a first time period, from a controller at the production site; intercept the plurality of IOs in each first time period; continuously aggregate and store the plurality of IOs in each first time period as an object in the object storage; and associate each object with a previous object in the object storage and a previous snapshot of the volume, wherein the previous snapshot is a snapshot created before the object is stored.

Optionally, incoming IOs are periodically frozen in the entity, and especially stored as objects in the object storage. In particular, the next object may point to the current object and a created snapshot.

In an implementation form of the first aspect, the entity is configured to: periodically receive an indication indicating that a snapshot of the volume will be created; hold incoming IOs; write to the volume according to objects associated with a previous snapshot of the snapshot; and create the snapshot of the volume after writing to the volume.

It can be seen that a snapshot is created less often, compared to an object in the object storage. Thus, each snapshot may have multiple objects attached to it or associated with it. Notably, before taking a snapshot, new IOs may be paused. Old IOs, which are already stored in the object storage, particularly, those associated with the previous snapshot, may be flushed into the volume. After that, a new snapshot may be created.

In an implementation form of the first aspect, the entity is configured to associate a newly stored object with the snapshot, after the snapshot has been created.

Notably, new objects which are stored after a respective snapshot has been created, may point to that snapshot.

In an implementation form of the first aspect, the production site is in a remote site, particularly a cloud.

Optionally, the production site is in another location, i.e., in a different place than where the snapshots are stored. For instance, the production site may be in the cloud.

In an implementation form of the first aspect, the entity is configured to create a first snapshot of the volume using an application programming interface (API) of the cloud.

Generally, the cloud may have APIs that allow creation of snapshots. That is, if the production site is in the cloud, it is possible to leverage the cloud’s ability to take snapshots of the volume.

In an implementation form of the first aspect, the entity is configured to: create a copy of the first snapshot and/or a copy of objects associated with the first snapshot using the API; and replicate the copy to the cloud and/or another production site in a remote site, using a cloud copy mechanism.

In addition, APIs may also allow creation of data copies. That is, if the production site is in the cloud, it may be possible to use the cloud mechanism to replicate objects and snapshots, and copy them from the production site to other remote sites, particularly to other cloud sites.

In an implementation form of the first aspect, the entity is configured to receive a copy of a snapshot and/or a copy of objects associated with the snapshot, the snapshot being of a volume of a storage entity at another production site, from the cloud, and/or from the another production site in the cloud through a cloud copy mechanism; and store the copy.

It should be understood that objects and snapshots from some other production sites may also be replicated by the cloud, and may be stored into this production site.

In an implementation form of the first aspect, the entity is configured to: receive an indication indicating that a second snapshot of the volume will be created, wherein the first snapshot is the previous snapshot of the second snapshot; hold new incoming IOs; write to the volume according to objects associated with the first snapshot; create the second snapshot of the volume after writing to the volume; and associate a newly stored object with the second snapshot, after the second snapshot has been created.

Notably, the first snapshot and the second snapshot may be contiguous in time.

In an implementation form of the first aspect, the entity is configured to: obtain a request to restore the volume to a given point in time, wherein the given point in time is a point in time after the first snapshot is created and before the second snapshot is created; obtain objects associated with the first snapshot, from the object storage; restore the first snapshot into a primary volume; and write to the primary volume according to the objects associated with the first snapshot, until the primary volume is at the given point in time.

In order to recover a site to a given point in time, the latest snapshot before that time may be restored first. In this case, the first snapshot is restored. Further, the relevant object(s) from the object storage may be read, and IOs in these objects may be applied until the volume is at the requested point in time. In an implementation form of the first aspect, the request is from another production site in the cloud.

Optionally, a specific site of the multiple cloud sites, which have replica copies of the snapshots and the objects, may request to recover the volume.

In an implementation form of the first aspect, an object in the object storage comprises a list of a plurality of IOs, and corresponding timestamps in which the plurality IOs occurred.

Timestamps of the IOs allow to recover a volume to a given point in time.

In an implementation form of the first aspect, the entity is configured to generate a restored volume, by writing IOs with corresponding timestamps before the given point in time, to the primary volume.

In an implementation form of the first aspect, the entity is configured to: restore the first snapshot into the primary volume using the API of the cloud service provider.

Optionally, a restore machine may restore the snapshot into a primary volume, using standard cloud APIs.

In an implementation form of the first aspect, the entity is configured to: scan snapshots using the API of the cloud service provider.

In an implementation form of the first aspect, the entity is configured to restore a volume of a storage device at the another production site.

A second aspect of the present disclosure provides a method comprising: intercepting a plurality of IOs for writing to a volume of a storage entity at a production site; aggregating the plurality of IOs; storing the aggregated IOs as a first object in an object storage at the production sitewriting to the volume immediately when they are arrived. The IOs may be held only on creation of snapshot time.

In an implementation form of the second aspect, the method further comprises: obtaining a notification, to start intercepting the plurality of IOs in a first time period, from a controller at the production site; intercepting the plurality of IOs in each first time period; continuously aggregating and storing the plurality of IOs in each first time period as an object in the object storage; and associating each object with a previous object in the object storage and a previous snapshot of the volume, wherein the previous snapshot is a snapshot created before the object is stored.

In an implementation form of the second aspect, the method further comprises: periodically receiving an indication indicating that a snapshot of the volume will be created; holding incoming IOs; writing to the volume according to objects associated with a previous snapshot of the snapshot; and creating the snapshot of the volume after writing to the volume.

In an implementation form of the second aspect, the method further comprises associating a newly stored object with the snapshot, after the snapshot has been created.

In an implementation form of the second aspect, the production site is in a remote site, particularly a cloud.

In an implementation form of the second aspect, the method further comprises creating a first snapshot of the volume using an API of the cloud.

In an implementation form of the second aspect, the method further comprises: creating a copy of the first snapshot and/or a copy of objects associated with the first snapshot using the API; and replicating the copy to the cloud and/or another production site in a remote site, using a cloud copy mechanism.

In an implementation form of the second aspect, the method further comprises: receiving a copy of a snapshot and/or a copy of objects associated with the snapshot, the snapshot being of a volume of a storage entity at another production site, from the cloud, and/or from the another production site in the cloud through a cloud copy mechanism; and storing the copy.

In an implementation form of the second aspect, the method further comprises: receiving an indication indicating that a second snapshot of the volume will be created, wherein the first snapshot is the previous snapshot of the second snapshot; holding new incoming IOs; write to the volume according to objects associated with the first snapshot; creating the second snapshot of the volume after writing to the volume; and associating a newly stored object with the second snapshot, after the second snapshot has been created.

In an implementation form of the second aspect, the method further comprises: obtaining a request to restore the volume to a given point in time, wherein the given point in time is a point in time after the first snapshot is created and before the second snapshot is created; obtain objects associated with the first snapshot, from the object storage; restoring the first snapshot into a primary volume; and writing to the primary volume according to the objects associated with the first snapshot, until the primary volume is at the given point in time.

In an implementation form of the second aspect, the request is from another production site in the cloud.

In an implementation form of the second aspect, an object in the object storage comprises a list of a plurality of IOs, and corresponding timestamps in which the plurality IOs occurred.

In an implementation form of the second aspect, the method further comprises generating a restored volume, by writing IOs with corresponding timestamps before the given point in time, to the primary volume.

In an implementation form of the second aspect, the method further comprises restoring the first snapshot into the primary volume using the API of the cloud service provider.

In an implementation form of the second aspect, the method further comprises scanning snapshots using the API of the cloud service provider.

In an implementation form of the second aspect, the method further comprises restoring a volume of a storage device at the another production site.

A third aspect of the present disclosure provides a computer program comprising a program code for carrying out, when implemented on a processor, the method according to the second aspect or any of its implementation forms.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. BRIEF DESCRIPTION OF DRAWINGS

The above described aspects and implementation forms will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows a conventional CDP system.

FIG. 2 shows an entity according to an embodiment of the disclosure.

FIG. 3 shows a CDP system according to an embodiment of the disclosure.

FIG. 4 shows a system including two production sites according to an embodiment of the disclosure.

FIG. 5 shows a method according to an embodiment of the disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

Illustrative embodiments of method, device, and program product for efficient packet transmission in a communication system are described with reference to the figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

Moreover, an embodiment/example may refer to other embodiments/examples. For example, any description including but not limited to terminology, element, process, explanation and/or technical advantage mentioned in one embodiment/example is applicative to the other embodiments/examples.

FIG. 2 shows an entity 200 according to an embodiment of the disclosure. The entity 200 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the entity 200 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application- specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. The entity 200 may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the entity 200 to be performed. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the entity 200 to perform, conduct or initiate the operations or methods described herein.

In particular, the entity 200, as shown in FIG. 2, is adapted for a production site 10. The production site may comprise a storage entity 200, and an object storage 400. In particular, the entity 200 is configured to intercept a plurality of IOs 201, for writing to a volume 301 of the storage entity 300 at the production site 10. The entity 200 is further configured to aggregate the plurality of IOs 201. Then, the entity 200 is configured to store the aggregated IOs 201 as a first object 401 in the object storage 400 at the production site 10. Further, the entity 200 is configured to write to the volume 301 according to the first object 401.

Notably, a cloud infrastructure may allow taking snapshots of virtual machines, replicating the snapshots to multiple availability zones, and the same may also be true for objects. The user can configure replication for his objects storage and specify on which availability zones he requires the objects. The objects may asynchronously be replicated to the other availability zones.

Embodiments of this disclosure thus propose a solution that can leverage a cloud’s ability to replicate objects and snapshots, in order to create multi-site CDP without any need for compute nodes, which are usually very expensive. The compute node may only be needed during restore operations and only for limited amount of time.

FIG. 3 shows a CDP system according to an embodiment of the disclosure. In particular, this system comprises a virtual machine (VM) VM1, a volume voll 301, an object storage 400 and a disaster recovery (DR) controller 500. In particular, the volume voll may be the volume 301 of the storage entity 300, as shown in FIG. 2, the object storage 400 may be the object storage 400 as shown in FIG. 2. For each replicated VM, a splitter driver may be installed in the kernel and a user space module. It may receive the writes, i.e., IOs, from the splitter, group them and write them as an object into an object storage (this group of writes is a journal entry). According to an embodiment of the disclosure, the entity 200 may comprise the VM, the splitter, and the splitter driver.

The DR controller 500 is to control disaster recover mechanisms and to tell each component what operation to perform. The DR controller 500 may periodically notify the splitter to hold the IOs. The DR controller 500 may also take a snapshot for the volume of the VM and release the IOs. The splitter may know to write that the new object belongs to a different snapshot.

As shown in FIG. 3, the entity 200 may be configured to obtain a notification 501, to start intercepting the plurality of IOs 201 in a first time period, from the DR controller 500 at the production site 10. That is, incoming IOs maybe periodically frozen in the entity 200. Optionally, the entity 200 may be configured to continuously aggregate and store the plurality of IOs 201 in each first time period as an object in the object storage 400. In particular, each object may be associated with a previous object in the object storage 400 and a previous snapshot of the volume, wherein the previous snapshot is a snapshot created before the object is stored.

Each object written by the user space splitter may have an ID, indicating which object is the predecessor object and to which snapshot the object refers to. Each object may also include a list of IOs with the timestamps, in which the IOs occurred. After every snapshot that was taken, the new object may include the new snapshot ID, but there may be no predecessor object.

The DR controller may also configure replication for the relevant objects in the object storage 400 as well as for the relevant snapshots. Notably, having copies of the snapshots and the objects, which include also the metadata, e.g., timestamps, may allow restoring each site to any point in time.

Optionally, the entity 200 may be configured to periodically receive an indication indicating that a snapshot of the volume will be created. It can be seen that a snapshot may be created less often, compared to the creation of objects in the object storage 400. For instance, one snapshot may be created daily for a volume. Thus, each snapshot may have multiple objects attached to it or associated with it. Notably, before taken a snapshot, new^IOs may be paused. The system may wait for IOs that have started the write procedure to the primary storage to end. Old IOs which are already stored in the volume, particularly, those associated with the previous snapshot, may be flushed into the object storage. In particular, the old IOs, which were stored in a memory cache of the host (the IOs are held by the splitter memory), may be transferred to a permanent memory, i.e., the object storage. After that, a new snapshot may be created. Accordingly, the entity 200 may be further configured to hold incoming IOs, and may write to the volume according to objects associated with a previous snapshot of the snapshot. Then, the entity 200 may be configured to create the snapshot of the volume after writing to the volume.

Notably, the new objects, which are stored after a respective snapshot has been created, may point to that snapshot. That is, the entity 200 may be further configured to associate a newly stored object with the snapshot, after the snapshot has been created.

This disclosure aims to leverage a cloud’s ability to replicate objects and snapshots, in order to create a multi-site CDP without any need for compute nodes, which are usually very expensive. Optionally, the production site 10 may be in a remote site, i.e., a different place than where snapshots are stored. For instance, the production site 10 may be in a cloud.

Optionally, the entity 200 may be configured to create a first snapshot of the volume 301 using an API of the cloud. Generally, the cloud usually has APIs that allow creation of snapshots, and replicating snapshots to multiple availability zones in the cloud. This may also apply for objects. That is, if the production site is in the cloud, it is possible to leverage the cloud’s ability to take snapshots of the volume.

Further, the entity 200 may be configured to: create a copy of the first snapshot and/or a copy of objects associated with the first snapshot using the API; and replicate the copy to the cloud and/or another production site 20 in a remote site, using a cloud copy mechanism.

Notably, the entity 200 may send an instruction or a message to the cloud, in order to instruct or indicate the cloud to take snapshots of virtual machines of a production site, or replicate snapshots to other replica sites in the cloud. According to embodiments of this disclosure, although the actions of creating a snapshot and replicating a snapshot are executed by the cloud, they may actually be initiated or triggered by signaling from the entity 200. In this way, a user of the cloud can configure replication for his objects storage and specify, on which availability zones he requires the objects. The objects may asynchronously be replicated to the other availability zones.

Optionally, the entity 200 may be further configured to receive a copy of a snapshot and/or a copy of objects associated with the snapshot, from the cloud. In particular, the snapshot is of a volume of a storage entity at another production site 20. Possibly, the entity 200 may also be configured to receive such copies from the another production site 20 in the cloud through a cloud copy mechanism. Accordingly, the copy of snapshots and/or the copy of objects will be stored in the entity 200.

It should be understood that objects and snapshots from some other production sites 20, may also be replicated by the cloud, and stored into this production site 10.

Another aspect of this disclosure is about the restore operation. In particular, according to an embodiment of this disclosure, a restore operation may work as follows. The user contacts the DR controller 500 and asks to restore to a specific point in time, and in a specific region. The DR controller 500 knows which copies of snapshot to select, as it can scan the available snapshots using the cloud APIs. The DR controller 500 may instantiate a restore machine. The restore machine may restore the selected snapshot into a primary volume, particularly using standard cloud APIs. It may then look for the relevant objects to look for the changes (i.e., IOs), and may apply all the required changes by reading the change objects and applying them to the volume 301. Once the volume 301 is ready, the restore machine may create a VM from the volume 301, and destroy itself. That is, the volume 301 is attached to a newly created VM, and the VM can start running.

FIG. 4 illustrates how the process works. According to an embodiment of the disclosure, the splitter writes the changes to journal entries. The DR controller 500 coordinates creation of snapshots and replication of the snapshot and journal entries. Notably, the entity 200 may further comprise the DR controller 500.

A value of this disclosure is that all the communication between regions, i.e., production sites, can be done by a cloud infrastructure. This reduces the need for configuration, and may reduce price. There is no need to compute, except for the DR controller 500, which is just a management unit with no data path and thus can control significant number of VMs with very little compute power. Further, according to an embodiment of the disclosure, a replication controller may configure snapshots and object storage to have copies in other sites. The replication controller may be the DR controller 500, as shown in FIG. 3 or FIG. 4.

In the following, an embodiment of the present disclosure is described in detail. In particular, steps of a CDP system may comprise the following:

1. A splitter is installed on the production VM.

2. The splitter intercepts IOs written to the production volume, the splitter copies IOs and forwards them to the production volume.

3. The splitter aggregates a group of IOs, and writes them as an obj ect to the object storage, each object points to the previous object, or to snapshot of the production volume.

4. Periodically the IOs are frozen in the splitter, the IOs in the memory are flushed and a snapshot of the production volume is created, the next object will point to the created snapshot. (This step is created by the replication controller).

In the following, the steps are the same as above, the periodical snapshot stops the splitter from writing, to create a consistent snapshot. After the snapshot is taken, it will go back to step 2, and the new IOs will be written into a change set of a new snapshot.

An embodiment of the present disclosure, in particular, steps of a recovery process is described in detail as following:

1. User selects a point in time to recover and a site to recover.

2. The replication controller restores the latest snapshot before the time the user requested at the requested site.

3. The replication controller configures a restore VM, attaches the restored volume to the VM, and reads the relevant object(s) from the object storage and applies the IOs from the IOs in the object storage until the volume is at the requested point in time.

4. The volume is attached to a newly created VM and the VM starts running.

According to aforementioned embodiments of this disclosure, an entity 200 is proposed, in order to save computation cost, and possibly also to save costs for public IPs. The cloud’s ability to replicate objects and snapshots can thus be leveraged, in order to create multi-site CDP without any need for compute nodes. It is known that compute nodes are usually very expensive. According to embodiment of the disclosure, the compute node will only be needed during restore operations and only for limited amount of time.

FIG. 5 shows a method 500 according to an embodiment of the disclosure. In a particular embodiment of the disclosure, the method 500 is performed by an entity 200 shown in FIG. 2. The method 500 comprises: a step 501 of intercepting a plurality of IOs 201 for writing to a volume 301 of a storage entity 300 at a production site 10; a step 502 of aggregating the plurality of IOs 201; a step 503 of storing the aggregated IOs 201 as a first object 401 in an object storage 400 at the production site 10.

Notably, the method 500 may further comprise actions as described in aforementioned embodiments of the entity 200.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed disclosure, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Furthermore, any method according to embodiments of the disclosure may be implemented in a computer program, having code means, which when run by processing means causes the processing means to execute the steps of the method. The computer program is included in a computer readable medium of a computer program product. The computer readable medium may comprise essentially any memory, such as a ROM (Read-Only Memory), a PROM (Programmable Read-Only Memory), an EPROM (Erasable PROM), a Flash memory, an EEPROM (Electrically Erasable PROM), or a hard disk drive.

Moreover, it is realized by the skilled person that embodiments of the entity 200 comprises the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing the solution. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units,

DSPs, trellis-coded modulation (TCM) encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution.

Especially, the processor(s) of the entity 200 may comprise, e.g., one or more instances of a Central Processing Unit (CPU), a processing unit, a processing circuit, a processor, an Application Specific Integrated Circuit (ASIC), a microprocessor, or other processing logic that may interpret and execute instructions. The expression “processor” may thus represent a processing circuitry comprising a plurality of processing circuits, such as, e.g., any, some or all of the ones mentioned above. The processing circuitry may further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like.

Claims

1. An entity (200) for a production site (10), the entity (200) being configured to: intercept a plurality of input/output, IOs (201), for writing to a volume (301) of a storage entity (300) at the production site (10); aggregate the plurality of IOs (201); store the aggregated IOs (201) as a first object (401) in an object storage (400) at the production site (10).

2. The entity (200) according to claim 1, configured to: obtain a notification (501), to start intercepting the plurality of IOs in a first time period, from a controller (500) at the production site (10); intercept the plurality of IOs (201) in each first time period; continuously aggregate and store the plurality of IOs (201) in each first time period as an obj ect in the obj ect storage (400); associate each object with a previous object in the object storage (400) and a previous snapshot of the volume (301), wherein the previous snapshot is a snapshot created before the object is stored.

3. The entity (200) according to claim 2, configured to: periodically receive an indication indicating that a snapshot of the volume (301) will be created; hold incoming IOs; write to the volume (301) according to objects associated with a previous snapshot of the snapshot; and create the snapshot of the volume (301) after writing to the volume (301).

4. The entity (200) according to claim 3, configured to: associate a newly stored object with the snapshot, after the snapshot has been created.

5. The entity (200) according to claim 3 or 4, wherein the production site (10) is in a remote site, particularly a cloud.

6. The entity (200) according to claim 5, configured to: create a first snapshot of the volume (301) using an application programming interface, API, of the cloud.

7. The entity (200) according to claim 6, configured to: create a copy of the first snapshot and/or a copy of objects associated with the first snapshot using the API; and replicate the copy to the cloud and/or another production site (20) in a remote site, using a cloud copy mechanism.

8. The entity (200) according to claim 7, configured to: receive a copy of a snapshot and/or a copy of objects associated with the snapshot, the snapshot being of a volume of a storage entity at another production site (20), from the cloud, and/or from the another production site (20) in the cloud through a cloud copy mechanism; and store the copy.

9. The entity (200) according to one of the claims 6 to 8, configured to: receive an indication indicating that a second snapshot of the volume (301) will be created, wherein the first snapshot is the previous snapshot of the second snapshot; hold new incoming IOs; write to the volume (301) according to objects associated with the first snapshot; create the second snapshot of the volume (301) after writing to the volume (301); and associate a newly stored object with the second snapshot, after the second snapshot has been created.

10. The entity (200) according to claim 9, configured to: obtain a request to restore the volume (301) to a given point in time, wherein the given point in time is a point in time after the first snapshot is created and before the second snapshot is created; obtain objects associated with the first snapshot, from the object storage (300); restore the first snapshot into a primary volume; and write to the primary volume according to the objects associated with the first snapshot, until the primary volume is at the given point in time.

11. The entity (200) according to claim 10, wherein the request is from another production site (20) in the cloud.

12. The entity (200) according to one of the claims 1 to 11, wherein an object in the object storage (400) comprises a list of a plurality of IOs, and corresponding timestamps in which the plurality IOs occurred.

13. The entity (200) according to claims 10 and 12, configured to: generate a restored volume, by writing IOs with corresponding timestamps before the given point in time, to the primary volume.

14. The entity (200) according to one of the claims 10 to 13, configured to: restore the first snapshot into the primary volume using the API of the cloud service provider.

15. The entity (200) according to one of the claims 6 to 14, configured to: scan snapshots using the API of the cloud service provider.

16. The entity (200) according to one of the claims 10 to 15 and claim 7, configured to: restore a volume of a storage device at the another production site.

17. A method (500) comprising: intercepting (501) a plurality of input/output, IOs (201), for writing to a volume (301) of a storage entity (300) at a production site (10); aggregating (502) the plurality of IOs (201); storing (503) the aggregated IOs (201) as a first object (401) in an object storage (400) at the production site (10).

18. A computer program product comprising a program code for carrying out, when implemented on a processor, the method according to claim 17.