A file server manager disclosed herein accesses information regarding a selected share of a source distributed file server for replication, where the selected share stores at least a portion of a namespace of storage items and is hosted by a first file server virtual machine of the source distributed file server. The file server manager accesses a mapping between virtual machines of the source distributed file server and virtual machines of the destination distributed file server and replicates the selected share to a second file server virtual machine of the destination distributed file server based on the mapping. The file server manager directs a request to read a first storage item to the destination distributed file server and directs a request to write to a second storage item to the source distributed file server while the destination distributed file server services the request to read the first storage item.

A scale-out storage system includes a plurality of computer nodes each of which has a memory and a processor, and a storage apparatus. The computer nodes have one or more redundancy groups each of which is a group for metadata protection. Each of the one or more redundancy groups includes two or more of the computer nodes including a primary node being a primary computer node and a secondary node being a secondary computer node, and a failover is performed from the primary node to the secondary node. The memory of the primary node has stored therein metadata related to the redundancy group and to be accessed for control. The metadata is redundantly stored in the memory of the primary node and the memory of the secondary node.

Examples provided herein describe a method for reducing recovery time for an application. For example, a first physical processor of a computing device may monitor, based on a first application instance of the application running in a first mode, for failure detection of the first application instance running on a first computing device. The first physical processor may determine that the first application instance is to be changed from the first mode to a second mode. Based on the determination, the first physical processor may validate that a second application instance can run in the first mode by performing a data integrity compliance check. Responsive to validating that the second application instance can run in the first mode, the first physical processor may facilitate running of the second application instance in the first mode.

Ensuring resiliency to storage device failures in a storage system, including: determining a number of storage device failures within a particular write group that are to be tolerated by the storage system; for a plurality of datasets stored within the storage system, writing each dataset to at least a predetermined number of storage devices within the particular write group, wherein the predetermined number of storage devices is greater than the number of storage device failures within the particular write group that are to be tolerated by the storage system; and responsive to recovering from a system interruption: determining a number of readable storage devices that contain a copy of the dataset; and if the number of readable storage devices that contain a copy of the dataset is not greater than the number of failures that are to be tolerated, writing the dataset to one or more additional storage devices.

An aspect of the present disclosure facilitates validating metering of a disaster recovery service used in clouds. In one embodiment, a system receives a request to validate metering of usage of a disaster recovery service (DRS) in a first cloud. The system collects from a metering service of the DRS, measured values representing the actual usage of the DRS in a second cloud and then compares the measured values with corresponding expected values representing expected usage of the DRS in the second cloud. The system sends a response to the request based on a result of the comparing. In one embodiment, the request is received from a tenant (customer/owner) owning the first cloud.

Techniques can be implemented to adjust a level of data protection for a device based on predictions of the weather. A physical location of the device can be determined. A first weather prediction from a first weather source for the physical location for a first time period, and a second weather prediction from a second weather source for the physical location for a second time period can be determined. The first weather prediction and the second weather prediction can be combined to produce a combined weather prediction for a third time period. The combined weather prediction can be analyzed to determine a weather categorization. Based on the weather categorization, a level of data protection of the device can be increased for the third time period.

Managed drives of a storage node with different size drives in a fixed arithmetic relationship are organized into clusters of same size drives. Every drive is configured to have M*G same-size partitions, where M is a positive integer variable defined by the arithmetic relationship and G is the RAID group size. The storage capacity of all drives can be viewed as matrices of G+1 rows and M*G columns, and each matrix is composed of submatrices of G+1 rows and G columns. Diagonal spare partitions are allocated and distributed in the same pattern over groups of G columns of all matrices, for increasing partition index values. Members of RAID groups are vertically distributed such that the members of a given RAID group reside in a single partition index of a single cluster. When a drive fails, protection group members of the failed drive are rebuilt in order on spare partitions characterized by lowest partition indices for increasing drive numbers across multiple clusters. Consequently, drive access for rebuild is parallelized and latency is reduced.

The invention discloses a container Dockerfile and container mirror image quick generation methods and systems. The container Dockerfile quick generation method includes the steps of for a to-be-packaged target application, running and performing tracking execution on the target application, and recording operation system dependencies of the target application in the running process; organizing and constructing a file list required for packaging the target application to a container mirror image; and according to the file list required for packaging the target application to the container mirror image, generating a Dockerfile and container mirror image file creation directory used for packaging the target application to the container mirror image. Any target application can be automatically packaged by the invention to a container; the construction of an executable minimal environmental closure of the target application is finished; the packaged container is smaller than a manually made container.

A storage node that maintains a replica of a logical volume for use in response to a failover trigger includes a data node with volatile memory in which a filesystem and its metadata and a VDM and its metadata associated with the replica are maintained prior to the failover trigger. The storage node also includes a SAN node in which data associated with the replica is maintained. The data is maintained in a RW (read-write) state by the SAN node prior to the failover trigger. However, the replica is presented in a RO (read-only) state by the storage node prior to the failover trigger. The storage node changes the in-memory state of the filesystem and VDM to RW responsive to the failover trigger. Because the filesystem and its metadata and VDM and its metadata are already in memory and the data is in a RW state in block storage the failover is completed relatively quickly.

A data storage management system comprises features for initiating failover orchestration jobs that invoke recovery resources on demand in a cloud computing environment. Backed up data that is stored persistently in the cloud computing environment may be rapidly restored within the cloud computing environment for use in disaster recovery and/or in test and verification scenarios. This approach may be contrasted to systems where a failover system is “always on” at the failover destination, such as having failover resources always up and running in the cloud computing environment. Such resources typically include a failover virtual machine (VM), a virtual machine datastore for the restored data, and one or more computing resources for restoring an auxiliary copy to the VM’s datastore. The cloud-based failover resources are deactivated or taken down once the failover event ends.