Techniques for managing a file system involve in response to receiving, at a first backup device of the file system, a request for replicating data of the file system from the first backup device to a second backup device of the file system, determining a synchronization state between the first backup device and the file system, the second backup device being a backup device located downstream of the first backup device; creating, based on the synchronization state, a target snapshot associated with the file system; and causing the data to be replicated from the first backup device to the second backup device based on the target snapshot. Therefore, the data backup flexibility and accuracy of a file system can be significantly improved and therefore the reliability of the whole system may be enhanced.

Methods and systems for managing sets of transactions for replication are provided. A system includes a number of origination nodes forming a source array. A sequence number generator generates sequence numbers based, at least in part, on a time interval during which a transaction is received. A subset manager groups transactions into subsets based, at least in part, on the sequence number.

Methods and systems for managing manifests for replication are provided. A system includes a number of origination nodes forming a source array. A remote copy ticket dispenser provides a replication ticket for a transaction to be grouped with other transactions and to be replicated to a destination array. A transaction communicator sends transactions to the destination array.

Methods and systems for a networked storage system are provided. One method includes: receiving, by a first storage node, a request to modify data stored using a logical storage object presented by the first storage node, the first storage node communicating with a second storage node configured as a failover partner of the first storage node; transmitting, by the first storage node, an invalidation request to the second storage node to invalidate an entry in a storage location cache of the second storage node, the entry indicating a storage location where data is stored by the first storage node, before modification; and responding, by the first storage node, to the request after modifying the data and upon receiving a response from the second storage node indicating successful invalidation of the entry.

Examples of the present disclosure describe implementing bitmap-based data replication when a primary form of data replication between a source device and a target device cannot be used. According to one example, a temporal identifier may be received from the target device. If the source device determines that the primary replication method is unable to be used to replicate data associated with the temporal identifier, a secondary replication method may be initiated. The secondary replication method may utilize a recovery bitmap identifying data blocks that have changed on the source device since a previous event.

A method of operating a storage device includes sensing a standby current flowing through the storage device, determining based on the sensed standby current and at least one reference value whether a product abnormality has occurred within the storage device, and when it is determined the product abnormality has occurred, performing a step-wise control operation in which two or more control processes associated with an operation of the storage device are sequentially executed.

Providing continuous data protection includes maintaining a database having substantially all data modifications made to a primary volume over a recovery interval. The database is maintained in conjunction with a copying operation where the data of the primary volume are mirrored to a remote volume to permit recovery of mirrored data in the event of loss of primary volume data. The contents of the remote volume generally lag behind the contents of the primary volume by substantially the recovery interval. Providing continuous data protection also includes providing data roll-back to a precise point in time within the recovery interval by applying, to the contents of the remote volume, all data modifications in the database that occurred between the latest data modification to the remote volume and the precise point in time within the recovery interval. A time stamp mechanism of sufficient precision and granularity may be used.

The present disclosure generally relates to creating virtualized block storage devices whose data is replicated across isolated computing systems to lower risk of data loss even in wide-scale events, such as natural disasters. The virtualized device can include at least two volumes, each of which is implemented in a distinct computing system. Each volume can be implemented by at least two computing devices, a first of which is configured as a primary device to which reads from and writes to the volume are directed. Of the two volumes, one can be indicated as primary, indicating authority to accept reads to and writes from the virtualized device. A primary device of the primary volume, on obtaining a write to the volume, can replicate the write to both a secondary device of a primary volume and to the secondary volume.

A technique replicates an index of an operations log (oplog) from a primary node to a secondary node of a cluster in the event of failure. The oplog functions as a staging area to coalesce random write operations directed to a virtual disk (vdisk) stored on a backend storage tier. The oplog temporarily caches write data as well as metadata describing the write data. The metadata includes descriptors to the write data corresponding to offset ranges of the vdisk and are used to identify ranges of write data for the vdisk that are cached in the oplog. To facilitate fast lookup operations of whether write data is cached in the oplog, an oplog index provides a state of the latest data for offset ranges of the vdisk that enables fast failover of metadata used to construct the oplog index in memory without downtime or significant metadata replay.

A remote data replication method and a storage system, where a production array sends a data replication request to a disaster recovery array. The data replication request includes an identifier of a source object and a data block corresponding to the source object. The data block is stored in physical space of a hard disk of the production array. The disaster recovery array receives the data replication request. The disaster recovery array creates a target object when the disaster recovery array does not include an object having a same identifier as the source object. An identifier of the target object is the same as the identifier of the source object, the disaster recovery array writes the data block into the physical space.