Abstract: Techniques regarding adaptive data recovery schemes are provided. For example, one or more embodiments described herein can comprise a system, which can comprise a memory that can store computer executable components. The system can also comprise a processor, operably coupled to the memory, and that can execute the computer executable components stored in the memory. The computer executable components can comprise a data management component that can modify a data recovery scheme based on performance data exhibited by a network of data centers and a data recovery requirement. The data recovery scheme can direct a relocation of data within the network.

Abstract: Techniques regarding adaptive data recovery schemes are provided. For example, one or more embodiments described herein can comprise a system, which can comprise a memory that can store computer executable components. The system can also comprise a processor, operably coupled to the memory, and that can execute the computer executable components stored in the memory. The computer executable components can comprise a data management component that can modify a data recovery scheme based on performance data exhibited by a network of data centers and a data recovery requirement. The data recovery scheme can direct a relocation of data within the network.

Abstract: A method makes container services persistently available. A computing device receives a request for implementation of a user job in a container environment, and assigns the user job to a compute runner agent of a plurality of compute runner agents to execute the user job. Each compute runner agent is associated with a compute container instance having a unique compute container identifier corresponding to the user job. A computing device assigns the user job to a balancer task to monitor progress of the user job, and assigns the user job to a storage agent to store artifacts associated with running the user job. A computing device receives a notification from the balancer task describing whether the runner agent is correctly running the user job. In response to the runner agent incorrectly running the user job, a computing device resurrects the user job in a new compute container instance.

Abstract: In an approach for optimizing resources in a disaster recovery cleanup process, processors are configured for receiving transaction entries represented by transaction identifiers at a source database in communication with target databases via Synchronous-to-Asynchronous Traffic Converters (SATCs).

Abstract: In an approach for optimizing resources in a disaster recovery cleanup process, processors are configured for receiving transaction entries represented by transaction identifiers at a source database in communication with target databases via Synchronous-to-Asynchronous Traffic Converters (SATCs).

Abstract: A method makes container services persistently available. A computing device receives a request for implementation of a user job in a container environment, and assigns the user job to a compute runner agent of a plurality of compute runner agents to execute the user job. Each compute runner agent is associated with a compute container instance having a unique compute container identifier corresponding to the user job. A computing device assigns the user job to a balancer task to monitor progress of the user job, and assigns the user job to a storage agent to store artifacts associated with running the user job. A computing device receives a notification from the balancer task describing whether the runner agent is correctly running the user job. In response to the runner agent incorrectly running the user job, a computing device resurrects the user job in a new compute container instance.

Abstract: A disaster-recovery system contains a networked array of synchronous-to-asynchronous converter (SATC) modules that connect source databases to target backup databases. During backup, the system replicates each source-database transaction through a chain of these SATCs to a corresponding target, storing a local copy of the transaction on each SATC along the way. Each transaction's path between its source-target pair is identified by a set of tracking entries, where each entry identifies one SATC in the path. Every backup transfer between two SATCs in a chain is performed synchronously, such that a successor SATC confirms a successful transfer to a predecessor SATC only after the successor can confirm a successful transfer to the next SATC in the chain. During a subsequent recovery operation, tracking entries are regenerated to locate locally stored transactions that had not time to be fully replicated before a catastrophic failure had occurred.

Abstract: Aspects of the present invention disclose a method for color reconstruction of individual detected objects of an underwater image using a library of reference images. The method includes one or more processors obtaining image data of a computing device that includes an underwater image. The method further includes determining a depth measurement corresponding to the underwater image. The method further includes identifying an object of the underwater image based at least in part on a shape of the object. The method further includes reconstructing one or more colors of the object of the underwater image based at least in part on a reference image.

Abstract: Aspects of the present invention disclose a method for color reconstruction of individual detected objects of an underwater image using a library of reference images. The method includes one or more processors obtaining image data of a computing device that includes an underwater image. The method further includes determining a depth measurement corresponding to the underwater image. The method further includes identifying an object of the underwater image based at least in part on a shape of the object. The method further includes reconstructing one or more colors of the object of the underwater image based at least in part on a reference image.

Abstract: Techniques regarding adaptive data recovery schemes are provided. For example, one or more embodiments described herein can comprise a system, which can comprise a memory that can store computer executable components. The system can also comprise a processor, operably coupled to the memory, and that can execute the computer executable components stored in the memory. The computer executable components can comprise a data management component that can modify a data recovery scheme based on performance data exhibited by a network of data centers and a data recovery requirement. The data recovery scheme can direct a relocation of data within the network.

Abstract: Provided are a computer program product, system, and method for management of transactions from a source node to a target node through intermediary nodes in a replication environment. A first tracking entry represents a transaction to transfer data from the source node to the target node that is received from a predecessor node in a first topology comprising one of the source node and the intermediary nodes to transmit to a first successor node and forwarded to the target node. A second topology is received including indication of a change to the first topology by including a second successor node not in the first topology. A second tracking entry is created for the transaction received from the predecessor node to send to the second successor node in response to data for the transaction having not yet been delivered to the target node.

Abstract: A disaster-recovery system contains a networked array of synchronous-to-asynchronous converter (SATC) modules that connect source databases to target backup databases. During backup, the system replicates each source-database transaction through a chain of these SATCs to a corresponding target, storing a local copy of the transaction on each SATC along the way. Each transaction's path between its source-target pair is identified by a set of tracking entries, where each entry identifies one SATC in the path. Every backup transfer between two SATCs in a chain is performed synchronously, such that a successor SATC confirms a successful transfer to a predecessor SATC only after the successor can confirm a successful transfer to the next SATC in the chain. During a subsequent recovery operation, tracking entries are regenerated to locate locally stored transactions that had not time to be fully replicated before a catastrophic failure had occurred.

Abstract: A disaster-recovery system contains a networked array of synchronous-to-asynchronous converter (SATC) modules that connect source databases to target backup databases. During backup, the system replicates each source-database transaction through a chain of these SATCs to a corresponding target, storing a local copy of the transaction on each SATC along the way. Each transaction's path between its source-target pair is identified by a set of tracking entries, where each entry identifies one SATC in the path. Every backup transfer between two SATCs in a chain is performed synchronously, such that a successor SATC confirms a successful transfer to a predecessor SATC only after the successor can confirm a successful transfer to the next SATC in the chain. During a subsequent recovery operation, tracking entries are regenerated to locate locally stored transactions that had not time to be fully replicated before a catastrophic failure had occurred.

Abstract: A disaster-recovery system contains a networked array of synchronous-to-asynchronous converter (SATC) modules that connect source databases to target backup databases. During backup, the system replicates each source-database transaction through a chain of these SATCs to a corresponding target, storing a local copy of the transaction on each SATC along the way. Each transaction's path between its source-target pair is identified by a set of tracking entries, where each entry identifies one SATC in the path. Before initiating a recovery operation, the system regenerates the tracking entries in order to reconstruct paths to source databases. The system then synchronously searches SATCs along each path for local copies of lost transactions that had not time to be fully replicated before the occurrence of a catastrophic failure. The full-blown recovery is started only after all lost transactions have been properly replicated to target databases.

Abstract: A disaster-recovery system contains a networked array of synchronous-to-asynchronous converter (SATC) modules that connect source databases to target backup databases. During backup, the system replicates each source-database transaction through a chain of these SATCs to a corresponding target, storing a local copy of the transaction on each SATC along the way. Each transaction's path between its source-target pair is identified by a set of tracking entries, where each entry identifies one SATC in the path. Every backup transfer between two SATCs in a chain is performed synchronously, such that a successor SATC confirms a successful transfer to a predecessor SATC only after the successor can confirm a successful transfer to the next SATC in the chain. During a subsequent recovery operation, tracking entries are regenerated to locate locally stored transactions that had not time to be fully replicated before a catastrophic failure had occurred.

Abstract: A disaster-recovery system contains a networked array of synchronous-to-asynchronous converter (SATC) modules that connect source databases to target backup databases. During backup, the system replicates each source-database transaction through a chain of these SATCs to a corresponding target, storing a local copy of the transaction on each SATC along the way. Each transaction's path between its source-target pair is identified by a set of tracking entries, where each entry identifies one SATC in the path. Before initiating a recovery operation, the system regenerates the tracking entries in order to reconstruct paths to source databases. The system then synchronously searches SATCs along each path for local copies of lost transactions that had not time to be fully replicated before the occurrence of a catastrophic failure. The full-blown recovery is started only after all lost transactions have been properly replicated to target databases.