Methods and systems for cross cluster replication are provided. Exemplary methods include: periodically requesting by a follower cluster history from a leader cluster, the history including at least one operation and sequence number pair, the operation having changed data in a primary shard of the leader cluster; receiving history and a first global checkpoint from the leader cluster; when a difference between the first global checkpoint and a second global checkpoint exceeds a user-defined value, concurrently making multiple additional requests for history from the leader cluster; and when a difference between the first global checkpoint and the second global checkpoint is less than a user-defined value, executing the at least one operation, the at least one operation changing data in a primary shard of the follower cluster, such that an index of the follower cluster replicates an index of the leader cluster.

A server system including a first server to execute first role, other server to execute at other role, spare server and management layer server. The management layer server is configured to allocate first group of users to access first server and other group of users to access other server, receive status information sent by first server and status information sent by other server, analyse status information to determine an operational status of first server and operational status of other server, update role of spare server to first role when operational status of first server indicates failed state and reallocate first group of users to the spare server, and update a role of another spare server to the other role when the operational status of the other server indicates a failed state and reallocate the other group of users to the other spare server.

A computer-implemented method for testing failover may include: determining one or more cross-regional dependencies and traffic flow of an application in a first region of a cloud environment, wherein the one or more cross-regional dependencies include a dependency of the application in the first region of the cloud environment to one or more applications in at least one other region of the cloud environment; determining a risk score associated with performing failover of the application to a second region of the cloud environment at least based on the determined one or more cross-regional dependencies and traffic flow of the application; comparing the determined risk score with a predetermined risk score; in response to determining that the determined risk score is lower than the predetermined risk score, performing failover of the application to the second region of the cloud environment; isolating the second region of the cloud environment from the first region of the cloud environment for a predetermined period of time; and monitoring operation of the application in the second region of the cloud environment during the predetermined period of time.

Example implementations relate to application-specific policies for failing over from an edge site to a cloud. When an application becomes operational within an edge site, a discovery phase is performed by a local disaster recovery (DR) agent. I/O associated with a workload of the application is monitored. An I/O rate for data replication that satisfies latency characteristics of the application is predicted based on the incoming I/O. Based on results of tests against multiple clouds indicative of their respective RTO/RPO values, information regarding a selected cloud to serve as a secondary system is stored in an application-specific policy. The application-specific policy is transferred to a remote DR agent running in the selected cloud. Responsive to a failover event, infrastructure within a virtualized environment of the selected cloud is enabled to support a failover workload for the application based on the application-specific policy.

An illustrative method for storing disaster recovery data includes receiving a plurality of copies of data stored by a first memory device. Each of the plurality of copies includes a plurality of blocks of data. The method also includes storing, in a second memory device, the plurality of copies in an object-oriented format, determining, using recovery time objectives, a number of the plurality of copies to be stored in a block-oriented format, and selecting a subset of the plurality of copies having the determined number of the plurality of copies. The method further includes assigning each of the other copies of the plurality of copies to one of a plurality of clusters. Each cluster of the plurality of clusters includes one of the subset of the plurality of copies. The method also includes determining, for each cluster, a copy having a highest number of blocks also present in the other copies of the cluster and storing, in the block-oriented format, the determined copy from each cluster in a third memory device.

Described are examples for deploying workloads in a cloud-computing environment. In an aspect, based on a desired number of workloads of a process to be executed in a cloud-computing environment and based on one or more failure probabilities, an actual number of workloads of the process to execute in the cloud-computing environment to provide a level of service can be determined and deployed. In another aspect, a standby workload can be executed as a second instance of the process without at least a portion of the separate configuration used by the multiple workloads, and based on detecting termination of one of multiple workloads, the standby workload can be configured to execute based on the separate configuration of the separate instance of the process corresponding to the one of the multiple workloads.

Replicated instances in a database environment provide for automatic failover and recovery. A monitoring component can periodically communicate with a primary and a secondary replica for an instance, with each capable of residing in a separate data zone or geographic location to provide a level of reliability and availability. A database running on the primary instance can have information synchronously replicated to the secondary replica at a block level, such that the primary and secondary replicas are in sync. In the event that the monitoring component is not able to communicate with one of the replicas, the monitoring component can attempt to determine whether those replicas can communicate with each other, as well as whether the replicas have the same data generation version. Depending on the state information, the monitoring component can automatically perform a recovery operation, such as to failover to the secondary replica or perform secondary replica recovery.

The present disclosure relates to a method of operating a database system. The database system comprises: a database; a first compute node comprising a first database proxy; and a second compute node comprising a second database proxy. The method comprises receiving and processing, at the first database proxy, a first plurality of access requests to access the database; receiving and processing, at the second database proxy, a second plurality of database access requests to access the database; monitoring for a failure event associated with the first database proxy; and, in response to the monitoring indicating a failure event, initiating a failover procedure between the first database proxy and the second database proxy. The failover procedure comprises: redirecting the first plurality of access requests to the second database proxy; and processing, at the second database proxy, the first plurality of access requests.

Methods and systems for transferring a host image of a first machine to a second machine, such as during disaster recovery or migration, are disclosed. In one example, a first profile of a first machine of a first type is compared to a second profile of a second machine of a second type different from the first type, to which the host image is to be transferred. The first and second profiles each comprise at least one property of the first type of first machine and the second type of second machine, respectively. At least one property of a host image of the first machine is conformed to at least one corresponding property of the second machine. The conformed host image is provided to the second machine, via a network. The second machine is configured with at least one conformed property of the host image.

A “backup services container” comprises “backup toolkits,” which include scripts for accessing containerized applications plus enabling utilities/environments for executing the scripts. The backup services container is added to Kubernetes pods comprising containerized applications without changing other pod containers. For maximum value and advantage, the backup services container is “over-equipped” with toolkits. The backup services container selects and applies a suitable backup toolkit to a containerized application to ready it for a pending backup. Interoperability with a proprietary data storage management system provides features that are not possible with third-party backup systems. Some embodiments include one or more components of the proprietary data storage management within the illustrative backup services container. Some embodiments include one or more components of the proprietary data storage management system in a backup services pod configured in a Kubernetes node. All configurations and embodiments are suitable for cloud and/or non-cloud computing environments.