Abstract: A Disaster Recovery (DR) verification process or system verifies readiness to execute a Disaster Recovery (DR) test. Such DR verification is automatically provided on a regular basis, with minimum impact on both a production and recovery environment. However, DR verification is only enabled at a time when no disaster recovery or DR testing of other sites is already under way. Configuration data needed for DR verification is constantly replicated from production to recovery, by dedicated data movers. DR verification allocates and configures recovery resources in an encapsulated environment, confirms successful their instantiation (such as boot up and network connections), and reports the outcome.

Abstract: An automated testing framework to coordinate functions among code management, build management, automated test, resource reservation, artifact repositories and team communication subsystems. In one embodiment specific to software development, software developers check new code into a code management subsystem, a development project tracking system, or other tools that automatically generate a build. Test suites are then automatically selected and executed based on a scope of the project or code that was built. This scope can include such attributes as what portion of the software was built, the purpose (objective) of the build, the maturity of developing that build, and so forth. In one implementation, label directives may be used to associate build scope to test suites. During or after the automated tests, other actions may then be automatically triggered, to store test results, inform the development team, stored data integrated with test definition and results, or update an artifact repository.

Abstract: A Recovery Maturity Index 1 (RMM) is used to determine whether a particular Information Technology (IT) production environment is relatively mature enough to successfully execute the disaster recovery (DR). The RMI provides a quantitative analysis in terms of a set of categories for elements that characterize the environment and multiple elements for each category. At least some of the elements depend upon the extent to which automation components have been leveraged for disaster recovery. A summation of the scoring elements, which may be a weighted summation, results in an overall quantitative metric. The metric can used to determine whether or not disaster recovery can be expected to be successful.

Abstract: In one example, a system and method for replication and recovery of protected resources may include one or more vendor neutral components that identify a corresponding vendor specific replication and/or recovery tool. The vendor specific tool is then executre to obtain replication data related to the protected logical entity. The replication data is formatted in a vendor neutral format, and forwarded to a target site over a data transport mechanism. The target site can then reformat the replication data into the appropriate vendor specific formats required on the target site (which may not be the same vendor or vendor formats on the source site), and proceed to recover and/or replicate the protected resources.

Abstract: An approach to improving system availability. Availability data for individual resources may be obtained from configuration templates and stored in an Availability Graph. The graph is traversed to calculate availability statistics at a grouped component and at an overall architecture level and grouping components level. Revisions may be made to enhance overall availability levels, and the revised Availability Graph can also be exported as an implementable configuration file. As a result, this solution provides a structured way to detect and resolve availability bottlenecks.

Abstract: An automated testing framework to coordinate functions among code management, build management, automated test, resource reservation, artifact repositories and team communication subsystems. In one embodiment specific to software development, software developers check new code into a code management subsystem, a development project tracking system, or other tools that automatically generate a build. Test suites are then automatically selected and executed based on a scope of the project or code that was built. This scope can include such attributes as what portion of the software was built, the purpose (objective) of the build, the maturity of developing that build, and so forth. In one implementation, label directives may be used to associate build scope to test suites. During or after the automated tests, other actions may then be automatically triggered, to store test results, inform the development team, stored data integrated with test definition and results, or update an artifact respository.

Abstract: A generic framework for testing service interfaces where attributes for service access are abstracted from test execution attributes. An eXtensible Markup Language (XML) Service Attribute (SA) file may be used to define a server tag and one or more services tags. The server tag specifies protocol, address, and other access information for a host machine that provides the service. A service type and configuration parameter defaults may also be included with the server tag. Each service tag defines a name of a corresponding service, and a request-response configuration for the corresponding service. With this information in hand, a test executor can then issue a request message to the corresponding service indicated in the service tag, using the protocol and address information and request configuration, and match the response received against the response configuration.

Abstract: A Recovery as a Service (RaaS) system including a Configuration Management Database (CMDB), a Resource Planning System (RPS), a Recovery Execution System (RES), and an Asset Reservation System (ARS). A scope for a test or recovery is specified as one or more applications. In one implementation, the RPS can request, from the CMDB, identification of which protected resources are within the requested scope and request the ARS to only reserve assets within that scope. At time of test or disaster, the RES programmatically generates a recovery workflow and initiates its orchestration such as provisioning and/or configuring operating systems, file systems, networks, applications, and data, and executing startup processes. If there are exceptions to automated workflow, then operations personnel may perform corresponding manual operations such as through a ticketing system.

Abstract: Programmatic generation of an actionable recovery workflow from data stored inside a Configuration Management Database which may be primarily populated through automated discovery. The programmatic workflow can be sent to an orchestration engine for execution, leveraging underlying automation components.

Abstract: A computer system may be configured to deploy software to multiple target machines. A controller, based on a request, may select a target machine and an installation job. The controller may be configured to determine a machine location of the target machine. Based on the machine location, the installation job may be routed to a run queue. The run queue may comprise a set of dedicated workers that may service the installation job.

Abstract: Services that support recovery of a data center require collecting information concerning the service customer's physical and virtual infrastructure, and specifically the configuration of their operating systems such as UNIX operating systems. Here an automatic discovery tool executes within the context of a secure browser program. Once a user is authenticated, a JavaScript or HTML program seamlessly retrieves a file that is specific to the type and version of the UNIX operating system on the host; the file contains commands and parsing logic for the commands to retrieve configuration data. Once parsed, the program forwards that data to a database so that the replication service provider may then correctly provision recovery systems.

Abstract: A computer system may be configured to invoke drivers to one or more target machines. A controller, based on a request, may select a driver from a set of interface drivers. The controller may be configured to invoke the driver selected from the set of interface drivers. The invoked driver may issue commands to a target machine that was named in the request. The commands may install an operating system, named in the request, on the target machine.

Abstract: A Recovery Maturity Model (RMM) is used to determine whether a particular Information Technology (IT) production environment can be expected, with some level of confidence, to successfully execute a test for disaster recovery (DR). The RMM provides a quantitative analysis in terms of the extent to which best practices are seen to have been implemented as a set of categories for elements of the environment and multiple elements for each category. A summation of the scoring elements, which may be a weighted summation, results in an overall quantitative metric which is then used to control whether or not testing will proceed.

Abstract: Systems, methods and procedures to capture, format and process configuration information needed for a Managed Recovery Program (MRP) solution that supports orderly handling of virtual machines in an information technology production environment. An MRP automation package is portable and contains all of the required configuration data to bring virtual infrastructure on line in a recovery environment as well as associated scripts that can be executed to automatically process the configuration data.

Abstract: Recovering logical domain processes from a virtual production environment to a recovery environment by building recovery automation scripts. The process, partially automated and partially guided by an administrative user, captures logic necessary for orderly recovery, but also permits the user to specify certain configuration information for the recovered logical domains. A first step before building recovery script(s) is to execute a capture script on the production environment to retrieve configuration information for the production logical domains. Based on this captured output, a recovery script builder then starts to build one or more recovery script(s). To account for unavoidable inconsistencies between the production and recovery environments, the user is guided through a deterministic process of providing additional information, such as different resource mappings, so that the script builder may further address such differences.

Abstract: Systems, methods and procedures enabling an incident planner to build and distribute disaster response playbooks to be used by incident responders. Information is excerpted from multiple plan documents (such as disaster recovery, crisis management, business continuity, or emergency response plans) that includes only what are the essential personnel contacts, tasks, and resources needed at time of disaster.

Abstract: A survey tool for use in a Recover to Cloud (R2C) replication service environment that determines configuration information automatically (such as through SNMP messaging or custom APIs) and stores it in a survey database. A Virtual Data Center (VDC) representation is then instantiated from the survey database, with the VDC being a virtual replica of the production environment including dormant Virtual Machine (VM) definition files, applications, storage requirements, VLANs firewalls, and the like. The survey tool determines the order in which the replicas are brought on line to ensure orderly recovery, by determining the order in which each machine makes requests for connections to other machines.

Abstract: Information Technology (IT) system configuration is managed using a set of defined flows with atomic execution properties. The instructions to execute a change to one or more infrastructure elements (a “forward transaction”) are maintained with instructions and/or information needed to execute a corresponding “reverse” transaction that is responsible for returning the element(s) to a pre-transaction action state in the event of a configuration failure or other request originating at a high level flow.

Abstract: Replication and recovery for a protected private cloud infrastructure that may include hosts, virtual machines (VMs) provisioned on the hosts, storage arrays and a management server. Metadata is periodically captured and made accessible to a recovery site. Upon a recovery event, replication of storage arrays is halted, and a number of target machines corresponding to the management server and the hosts to be recovered are assigned. The assigned management server and hosts are then bare provisioned by installing operating systems or hypervisors as specified by the metadata. Only then are recovery target machines connected to the replicated storage arrays so that virtual machines can be activated.

Abstract: A Recovery Maturity Model (RMM) is used to determine whether a particular Information Technology (IT) production environment can be expected, with some level of confidence, to successfully execute a test for disaster recovery (DR). The RMM provides a quantitative analysis in terms of the extent to which best practices are seen to have been implemented as a set of categories for elements of the environment and multiple elements for each category. A summation of the scoring elements, which may be a weighted summation, results in an overall quantitative metric which is then used to control whether or not testing will proceed.