Abstract: Systems and methods are disclosed for implementing an event based retention schedule for a read only file. When a regular file is to be converted to an event based retention read only file, an “event-retain” property may be enabled on the file allowing the feature to be implemented. Then, that file may have its permissions changed to read only. This will allow the file to be changed to a read only file without using a default retention time. Then, once the event is triggered, the retention time may be set so the file can be scheduled for automatic deletion.

Abstract: A file system cloning method and apparatus is provided. In the method, a destination storage system first receives first information from a source storage system in which a file system runs. The first information is used to indicate a data layout of the file system. Then, the destination storage system creates a cloned file system of the file system based on the first information.

Abstract: Systems and methods which provide for managing multiple mirror resources in a storage distribution network are provided. In some embodiments, a system provides for both high availability and disaster recovery functionality at different mirroring locations. Other embodiments may provide for multiple high availability and/or multiple disaster recovery mirror resources. These mirror resources are operated in a heterogeneous manner in the sense that each have its own transport, protocol, and the like, but are configured function cooperatively or as a single mirror with respect to mirroring a primary node. Embodiments may provide for the mirroring and resynchronization of mirrored resources in the event of a communication loss with a particular resource without ceasing the mirroring operations to other resources.

Abstract: Systems and methods are disclosed for implementing an event based retention schedule for a read only file. When a regular file is to be converted to an event based retention read only file, an “event-retain” property may be enabled on the file allowing the feature to be implemented. Then, that file may have its permissions changed to read only. This will allow the file to be changed to a read only file without using a default retention time. Then, once the event is triggered, the retention time may be set so the file can be scheduled for automatic deletion.

Abstract: Systems and methods are disclosed for implementing an event based retention schedule for a read only file. When a regular file is to be converted to an event based retention read only file, an “event-retain” property may be enabled on the file allowing the feature to be implemented. Then, that file may have its permissions changed to read only. This will allow the file to be changed to a read only file without using a default retention time. Then, once the event is triggered, the retention time may be set so the file can be scheduled for automatic deletion.

Abstract: One or more techniques and/or computing devices are provided for data object retention. For example, a data retention policy may specify that files of a volume are to be locked down for a lockdown retention period (e.g., locked into a read only state for 4 months) when such files are not changed within an auto commit time period (e.g., files not changed within 13 hours). Waiting for a data scanner to evaluate files for lockdown may result in files violating the data retention policy until the data scanner evaluates such files. Accordingly, a file may be considered to be in the locked down state (e.g., instantaneous lockdown), such that commands to modify or delete the file are blocked, based upon a difference between a current time of an internal compliance clock and a current value of a data object change field exceeding the auto commit time period.

Abstract: A system and method for handling multi-node failures in a disaster recovery cluster is provided. In the event of an error condition, a switchover operation occurs from the failed nodes to one or more surviving nodes. Data stored in non-volatile random access memory is recovered by the surviving nodes to bring storage objects, e.g., disks, aggregates and/or volumes into a consistent state.

Abstract: One or more techniques and/or systems are provided for dynamic mirroring. A first storage node and the second storage node within a first storage cluster may locally mirror data between one another based upon a local failover partnership. The first storage node and a third storage node within a second storage cluster may remotely mirror data between one another based upon a primary disaster recovery partnership. If the third storage node fails, then the first storage node may remotely mirror data to a fourth storage node within the second storage cluster based upon an auxiliary disaster recovery partnership. In this way, data loss protection for the first storage node may be improved, such that the fourth storage node provide clients with access to mirrored data from the first storage node in the event the second storage node and/or the third storage node are unavailable when the first storage node fails.

Abstract: A technique efficiently configures a peered cluster storage environment. The configuration technique illustratively includes three phases: a discovery phase, a node setup phase and a cluster setup phase. The discovery phase may be employed to initiate discovery of nodes of a disaster recovery (DR) group through transmission of multicast advertisement packets by the nodes over interconnects, including a Fiber Channel (FC) fabric, to each other node of the group. In the node setup phase, each node of a cluster assigns its relationships to the nodes discovered and present in the FC fabric; illustratively, the assigned relationships include high availability (HA) partner, DR primary partner and DR auxiliary partner. In the cluster setup phase, the discovered nodes of the FC fabric are organized as the peered cluster storage environment (DR group) configured to service data in a highly reliable and available manner.

Abstract: Systems and methods which provide for managing multiple mirror resources in a storage distribution network are provided. In some embodiments, a system provides for both high availability and disaster recovery functionality at different mirroring locations. Other embodiments may provide for multiple high availability and/or multiple disaster recovery mirror resources. These mirror resources are operated in a heterogeneous manner in the sense that each have its own transport, protocol, and the like, but are configured function cooperatively or as a single mirror with respect to mirroring a primary node. Embodiments may provide for the mirroring and resynchronization of mirrored resources in the event of a communication loss with a particular resource without ceasing the mirroring operations to other resources.

Abstract: A system and method for handling multi-node failures in a disaster recovery cluster is provided. In the event of an error condition, a switchover operation occurs from the failed nodes to one or more surviving nodes. Data stored in non-volatile random access memory is recovered by the surviving nodes to bring storage objects, e.g., disks, aggregates and/or volumes into a consistent state.

Abstract: One or more techniques and/or systems are provided for dynamic mirroring. A first storage node and the second storage node within a first storage cluster may locally mirror data between one another based upon a local failover partnership. The first storage node and a third storage node within a second storage cluster may remotely mirror data between one another based upon a primary disaster recovery partnership. If the third storage node fails, then the first storage node may remotely mirror data to a fourth storage node within the second storage cluster based upon an auxiliary disaster recovery partnership. In this way, data loss protection for the first storage node may be improved, such that the fourth storage node provide clients with access to mirrored data from the first storage node in the event the second storage node and/or the third storage node are unavailable when the first storage node fails.

Abstract: One or more techniques and/or computing devices are provided for implementing resynchronization operations. For example, a disaster recovery relationship may be established between a source storage volume, hosted by a source storage node, and a destination storage volume hosted by a destination storage node, such that data is replicated from the source storage volume to the destination storage volume for disaster recovery purposes. If the disaster recovery relationship breaks, then new compliance data, locked down into a write once read many state, may be created at the destination storage volume. A resynchronization operation may be performed to reestablish the disaster recovery relationship, while preserving the new compliance data so that a compliance policy is not violated.

Abstract: Systems and methods which provide for managing multiple mirror resources in a storage distribution network are provided. In some embodiments, a system provides for both high availability and disaster recovery functionality at different mirroring locations. Other embodiments may provide for multiple high availability and/or multiple disaster recovery mirror resources. These mirror resources are operated in a heterogeneous manner in the sense that each have its own transport, protocol, and the like, but are configured function cooperatively or as a single mirror with respect to mirroring a primary node. Embodiments may provide for the mirroring and resynchronization of mirrored resources in the event of a communication loss with a particular resource without ceasing the mirroring operations to other resources.

Abstract: A system and method for handling multi-node failures in a disaster recovery cluster is provided. In the event of an error condition, a switchover operation occurs from the failed nodes to one or more surviving nodes. Data stored in non-volatile random access memory is recovered by the surviving nodes to bring storage objects, e.g., disks, aggregates and/or volumes into a consistent state.

Abstract: One or more techniques and/or systems are provided for dynamic mirroring. A first storage node and the second storage node within a first storage cluster may locally mirror data between one another based upon a local failover partnership. The first storage node and a third storage node within a second storage cluster may remotely mirror data between one another based upon a primary disaster recovery partnership. If the third storage node fails, then the first storage node may remotely mirror data to a fourth storage node within the second storage cluster based upon an auxiliary disaster recovery partnership. In this way, data loss protection for the first storage node may be improved, such that the fourth storage node provide clients with access to mirrored data from the first storage node in the event the second storage node and/or the third storage node are unavailable when the first storage node fails.

Abstract: One or more techniques and/or systems are provided for interconnect failover between a primary storage controller and a secondary storage controller. The secondary storage controller may be configured as a backup or failover storage controller for the primary storage controller in the event the primary storage controller fails. Data and/or metadata describing the data (e.g., data and/or metadata stored within a write cache) may be mirrored from the primary storage controller to the secondary storage controller over one or more interconnect paths. Responsive to identifying a failover trigger for a failed interconnect path, the secondary storage controller is instructed to fence (e.g., block) I/O operations from the failed interconnect path. Streams of data and/or metadata that were affected by the failure may be instructed to transmit such data and/or metadata over one or more non-failed interconnect paths to the secondary storage controller during failover of the failed interconnect path.

Abstract: One or more techniques and/or computing devices are provided for implementing resynchronization operations. For example, a disaster recovery relationship may be established between a source storage volume, hosted by a source storage node, and a destination storage volume hosted by a destination storage node, such that data is replicated from the source storage volume to the destination storage volume for disaster recovery purposes. If the disaster recovery relationship breaks, then new compliance data, locked down into a write once read many state, may be created at the destination storage volume. A resynchronization operation may be performed to reestablish the disaster recovery relationship, while preserving the new compliance data so that a compliance policy is not violated.

Abstract: One or more techniques and/or computing devices are provided for data object retention. For example, a data retention policy may specify that files of a volume are to be locked down for a lockdown retention period (e.g., locked into a read only state for 4 months) when such files are not changed within an auto commit time period (e.g., files not changed within 13 hours). Waiting for a data scanner to evaluate files for lockdown may result in files violating the data retention policy until the data scanner evaluates such files. Accordingly, a file may be considered to be in the locked down state (e.g., instantaneous lockdown), such that commands to modify or delete the file are blocked, based upon a difference between a current time of an internal compliance clock and a current value of a data object change field exceeding the auto commit time period.

Abstract: Systems and methods are disclosed for implementing an event based retention schedule for a read only file. When a regular file is to be converted to an event based retention read only file, an “event-retain” property may be enabled on the file allowing the feature to be implemented. Then, that file may have its permissions changed to read only. This will allow the file to be changed to a read only file without using a default retention time. Then, once the event is triggered, the retention time may be set so the file can be scheduled for automatic deletion.