Applications
The Data Resiliency Service introduces the concept of applications, which represents an application consisting of multiple interconnected components within the storage environment. It also introduces the concept of application dependency mapping , which provides a visual representation of multiple applications and their interconnections within an enterprise environment.
In enterprise environments, applications typically consist of multiple interconnected components such as databases, application servers, web servers, and other infrastructure elements, that collectively support critical business functions. These components form complex dependency hierarchies, and their proper orchestration is essential to maintain operational resilience.
Concepts
The Data Resiliency Service helps organizations model, orchestrate, and govern applications effectively, streamlining recovery operations and improving overall system resilience.
The Data Resiliency Service introduces applications as a logical construct that groups multiple interconnected components within the storage environment. These components such as databases, virtual machines, web servers, and application services, collectively support critical business functions and form complex dependency hierarchies. In enterprise environments, ensuring application resilience is essential to maintain business continuity.
An application in the Data Resiliency Service includes one or more recovery groups, each representing a specific component or resource type. These recovery groups are organized into phases that define the recovery order, which is critical for successful restoration during a disaster.
- Data Layer (Database): This layer contains all critical application data.
- Application Layer (Middleware): This layer hosts core business logic. It processes user requests and interacts with the database.
- Web or Frontend Layer (Internet or Mobile Banking applications): This layer provides end‑user access to banking services.
Within the Data Resiliency Service, each of these layers is represented by a dedicated recovery group. During any recovery operation planned, unplanned, cyber‑related, or disaster‑driven, these recovery groups are restored in a specific sequence to ensure application integrity and functional consistency.
- RG_DB: The recovery group for Data Layer (Database), and must be restored first so that dependent services have a consistent and available data foundation.
- RG_APP: The recovery group for the Application Layer (Middleware), and must be recovered after the data layer and before any frontend services.
- RG_WEB: The recovery group for the Web/Frontend Layer (Internet/Mobile Banking applications), and should be restored only after the database and middleware layers are fully operational to ensure a seamless user experience.
By following this structured recovery sequence, the Data Resiliency Service brings all components of the banking application online in a stable and logically consistent way. This approach reduces downtime and prevents cascading failures across dependent services.
- Model complex dependencies between components.
- Define and enforce recovery sequences.
- Simplify identification of available recovery points such as snapshots and backups.
- Validate and test recovery points for each recovery group.
During recovery, administrators can easily locate and assess recovery points for all components referenced within the application, reducing complexity and minimizing downtime.
- Aggregates alerts and monitoring data across recovery groups.
- Offers a unified interface for visibility and control.
- Enables administrators to make informed decisions during recovery and planning.
- Streamline recovery operations.
- Ensure accurate sequencing of component restoration.
- Minimize downtime and operational disruption.
- Improve Recovery Time Objectives (RTOs).
- Enhance overall resilience against system failures.
This structured methodology enables IT teams to administer and orchestrate complex application environments with enhanced precision and assurance, thereby fortifying the enterprise’s operational resilience and ensuring continuity in the event of unanticipated disruptions.
Further, in large enterprise ecosystems, many applications work together to support different business functions. These applications are often interdependent and complement each other to deliver essential services.
To illustrate and manage these interdependencies, the Data Resiliency Service introduces the concept of application dependency mapping. This mapping is a visual representation of applications and their connections within an enterprise environment. It shows how applications work together, helps identify relationships, assess potential risks, and determine which applications to restore first during recovery. By restoring critical functions in the correct order, downtime is reduced.
- App1: This application has no dependency on any other application.
- App2: This application depends on App1.
- App3, App4: These applications depend on App2.
In an application dependency map, App1 acts as the root application, while App2 is the branch application connected to App1. Further App3 and App4 are the branch applications connected to App2. When recovering any application in the map, the root application is recovered first, followed by its branch applications in a linear sequence. A branch application is recovered after its root application and all preceding branch applications in the dependency chain have been recovered.
In enterprise environments, effective recovery requires comprehensive planning and clear documentation. Organizations must quickly identify the optimal recovery points for their applications by evaluating criteria such as recency, validation status, scan results, and immutability.
Data Resiliency Service provides the Recovery Plan feature to address this challenge.
A recovery plan is a structured recovery reference that helps restore customer applications in an event-driven and evidence-based order. The order determines the recovery priority for the recovery groups within applications. Recovery plans help users prepare for both planned and unplanned events that can affect their applications and support the safe recovery of those applications.
- Complete application configuration and metadata
- A list of all available recovery points for each recovery group
- Intelligent recommendations for optimal recovery points based on user-defined criteria
- Detailed recovery point attributes, including type, validation status and scan results.
A recovery plan is informational and does not perform or automate any recovery actions. Users must manually initiate and execute restore operations for each recovery group by using the appropriate mechanism, such as Data Resiliency Service or their backup or storage system. The recovery plan does not execute restores, track completion status, or show ongoing changes. Instead, it provides a static, point in time representation of the application’s recovery configuration and the recommended sequence of actions.
The plan supplies the detailed and sequential information needed to perform recovery. Users can view the plan directly in the Data Resiliency Service user interface or download it in PDF format. This feature helps organizations make informed recovery operations by providing clear visibility into available recovery options and automated recommendations based on configurable selection criteria.
Guide to use this feature
An application in Data Resiliency Service consists of one or more recovery groups, each representing a specific component or resource type.
To create an application, complete the following steps in the Data Resiliency Service user interface:
- Navigate to , and then click Create application.
- Adding application details
Enter the application's basic details, such as its name and description. Add one or more people as contacts for the application.
- Adding phases
After adding the application details, you will see a list of recovery groups you can include in the application, along with the option to add recovery phases. These phases allow you to specify a preferred order for restoring recovery groups within the application. First, specify how many phases you need, then add recovery groups to each phase as required.
- Adding recovery groups to phases
Recovery groups within an application often depend on one another, making the order of recovery important. Phases allow you to organize recovery groups according to their dependencies, ensuring they are restored in the correct sequence. Recovery groups in Phase 1 are restored first, followed by Phase 2, and so on.Note: Recovery groups typically include infrastructure components such as web servers, application servers, and databases. Your infrastructure environment might consist of components that do not fit into these categories. In such scenarios, a placeholder recovery group allows you to create an empty recovery group first and then add infrastructure components to it.
- Removing recovery groups or phases
You can remove a recovery group or a phase from the application.For more information, see Creating an application and Deleting an application.
- Removing a recovery group
Click the overflow menu in the recovery group, then click Delete. To remove all recovery groups from a phase, click the count displayed next to the phase name.
- Removing a phase
Hover over the top-right corner of the phase and click the bin icon.
- Removing a recovery group
All applications appear at . From this view, you can see each application's status, priority, recovery groups, resources, dependency chains, tags, point of contact, and last updated time. For more information, see Applications.
- Overview tab, which contains tiles for:
- Actions
- Recovery group status
- Source status: total, failed, and success
- Recovery groups distribution: by resource types and workload types
- Application details
- Recovery groups tab, which contains a table that lists all recovery groups that are associated with the application.
- Resources tab, which contains a table that lists the current data resources in the application's recovery groups. It also includes data resources and current volumes in the application.
- Connected sources tab, which contains a table that lists the sources that are associated with the application.
- Recovery plan tab, which contains tiles for the current recovery plan and the recovery groups that belong to the application.
- History tab, which contains a table that lists updates that were made to the application.
For more information, see Application details.
The application dependency mapping is the process of identifying and understanding how different applications relate to each other.
A dependency map must include at least one root application and one branch application.
- Navigate to , and then click Map dependencies.
- Add a root application:
Drag and drop an application card from the list on the left into the root applications column.
- Add branch applications and creating dependencies:
Adding a dependency means adding a branch application to an existing root application in a dependency map. Simply, drag and drop an application card from the list on the left onto the application to which you want to add a dependency. You can also click the overflow menu in the application, click Add dependency, and then select the application that you want to add as a dependent.
- Add an additional root application:
In some cases, one branch application in a dependency map is also uniquely related to another application, which is not part of the dependency map. You can include that application in the existing dependency map, by just adding it to the root applications column and then linking this new root application to the specific branch application. You can add multiple additional root applications. This is useful in visualizing the additional complexities within a dependency map.
- Remove applications dependencies:
You can remove branch applications from the dependency map. To remove branch application, click the overflow menu in the application, then click Remove.For more information, see Creating and managing dependencies.Note: Only applications with no dependent applications can be removed from the dependency map.
To view existing applications and their dependencies mapping, navigate to the .
On the Applications page, you can use two view types; Applications view and Map dependencies view to manage and understand applications. For more information, see Applications.
A recovery plan in an application includes sets of recovery points for each underlying recovery group, based on predefined user preferences and recovery requirements. The plan indicates the most suitable recovery point for each recovery group that users can use to recover to a specific point in time.
- Navigate to Data Resiliency > Groupings > Applications, and choose the application of interest.
- In the Application details view, under the Recovery plan tab, select Create.
- Add the recovery plan attributes by specifying the time range and setting the preferences for generating recovery point suggestions.
- Add the point of contacts.
For more information, see Creating recovery plan.
To view an existing recovery plan for an application, navigate to Data Resiliency > Groupings > Applications and choose the application of interest.
- A tile with general information about the recovery plan, the application details, the recovery group status, and the recovery groups distribution.
- Tiles for each recovery group, which show general information and the preferred recovery point. You can edit the preferred recovery point. For more information, see Editing preferred recovery point.
- Download the recovery plan. For more information, see Downloading a recovery plan.
- Edit a recovery plan. For more information, see Editing a recovery plan.
- Delete the current recovery plan. For more information, see Deleting a recovery plan.