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.

The present invention has been made in view of the above problems, and an object of the present invention is to, when an abnormality is detected in an electronic control apparatus that controls a plurality of functions, continue an operation without affecting the other function and secure safety of a control target device corresponding to the function in which the abnormality is detected. In the vehicle mounted electronic control apparatus according to the present invention, each of a first computing portion and a second computing portion outputs an operation check signal, and a driver control unit sets a driver corresponding to the computing portion in which an abnormality is indicated by the operation check signal among the first computing portion and the second computing portion, to a degenerated state.

Methods, apparatus, and computer-accessible storage media for providing redundant storage gateways. A client may create a storage gateway group and add storage gateways to the group. The client may assign one or more volumes on a remote data store to each the storage gateways in the group. Volume data for each storage gateway in the group may be replicated to at least one other storage gateway in the group. If one of the gateways in the group becomes unavailable, one or more other gateways in the group may take over volumes previously assigned to the unavailable gateway, using the replicated data in the group to seamlessly resume gateway operations for the respective volumes. Client processes that previously communicated with the unavailable gateway may be manually or automatically directed to the gateway(s) that are taking over the unavailable gateway's volumes.

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.

Methods, apparatus, systems, and articles of manufacture are disclosed to manage a self-adaptive heterogeneous emergency network. An example apparatus to establish recovery nodes includes failure detection circuitry to determine a node initiated a reset procedure, override circuitry to suppress a native recovery procedure of the node, formation circuitry to initiate a heterogeneous recovery procedure, and trust circuitry to measure a root of trust of the node. Further, the example apparatus instantiates the formation circuitry further to broadcast heterogeneous recovery packets, and activate listener ports for responses to the heterogeneous recovery packets.

Herein are resource-constrained techniques that plan ahead for resiliently moving pluggable databases between container databases after a failure in a high-availability database cluster. In an embodiment that has a database cluster that hierarchically contains many pluggable databases in many container databases in many virtual machines, a computer identifies many alternative placements that respectively assign each pluggable database instance (PDB) to a respective container database management system (CDBMS). For each alternative placement, a respective placement score is calculated based on the PDBs and the CDBMSs. Based on the placement scores of the alternative placements, a particular placement is selected with a best placement score that indicates optimal resilience for accommodating adversity such as failover and overcrowding.

Examples of systems are described herein which may dynamically allocate compute resources to recovery clusters. Accordingly, a recovery site may utilize fewer compute resources in maintaining recovery clusters for multiple associate clusters, while ensuring that, during use, compute resources are allocated to a particular cluster. This may reduce and/or avoid vulnerabilities arising from a use of shared resources in a virtualized and/or cloud environment.

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.

Embodiments described herein are generally directed to intelligent management of microservices failover. In an example, responsive to an uncorrectable hardware error associated with a processing resource of a platform on which a task of a service is being performed by a primary microservice, a failover trigger is received by a failover service. A secondary microservice is identified by the failover service that is operating in lockstep mode with the primary microservice. The secondary microservice is caused by the failover service to takeover performance of the task in non-lockstep mode based on failover metadata persisted by the primary microservice. The primary microservice is caused by the failover service to be taken offline.

A first forwarding VM may execute in a first availability zone and have a first IP address. Similarly, a second forwarding VM may execute in a second availability zone and have a second IP address. The first and second IP addresses may be recorded with a cloud DNS web service of a cloud provider such that both receive requests from applications directed to a particular DNS name acting as a single endpoint. A service cluster may include a master VM node and a standby VM node. An IPtable in each forwarding VM may forward a request having a port value to a cluster port value associated with the master VM node. Upon a failure of the master VM node, the current standby VM node may be promoted to execute in master mode and the IPtables may be updated to now forward requests having the port value to a cluster port value associated with the newly promoted master VM node (which was previously the standby VM node).