Applications & Dependencies
You recover an application, not a volume. Everything else in DRM — required targets, recovery plans, predicted RTO and RPO, baselines — hangs off the applications you approve and the dependencies between their parts. This page explains where both come from.
Where the resources come from
DRM does not run its own scan. It reads the Onam platform's cloud inventory — the same discovery Onam Estate reads — so your accounts are connected once and every product sees the same list of resources.
Each resource is placed where the provider says it lives: its availability zone where the provider gives one, its region otherwise. DRM does not guess a placement the provider does not state.
How applications are proposed
Applications are proposed from your tags — for example an application tag, a CloudFormation stack, a Helm release or a Kubernetes cluster. Every proposed application shows:
- the tag it came from, so you can see why these resources were grouped together;
- a confidence in what that tag means.
An infrastructure grouping such as a Kubernetes cluster is labelled as one, rather than presented as a business application. Resources that could not be grouped are shown as plainly as those that could — an ungrouped resource is a gap to look at, not something to hide.
Within an application, resources are organised into components — the parts of the application that recover together. The application is the unit that carries your required RTO and RPO and gets a recovery plan.
Grouping reads tags. An estate where only compute is tagged will produce applications that contain only compute, and databases or storage left ungrouped. Tagging what an application uses is the most direct way to improve what DRM proposes.
How dependencies are classified
Dependencies come from a catalogue of how cloud resources relate to each other. Every edge says what kind of dependency it is, because the kinds mean different things for recovery:
| Kind | What it means | Sets recovery order? |
|---|---|---|
| Recovery order | This must be recovered before that | Yes |
| Protection | This proves a copy of that exists (a replica, a snapshot) | No |
| Placement | These share a failure domain, so they can fail together | No |
Only recovery-order edges decide the order of a recovery plan. An edge DRM could not resolve is kept visible as unresolved rather than dropped, so a missing link shows up as a question instead of disappearing.
Where to see them
| View | What it shows |
|---|---|
| Applications | Applications, their components and resources, with the tag and confidence behind every grouping |
| Dependencies | The dependency graph, by edge kind, with unresolved edges kept visible |
| Topology | Where each application's resources sit — by region and availability zone |
Nothing counts until a person approves it
Every proposed application and dependency arrives in the Approval Center as a proposal. Nothing enters a recovery plan or a baseline until someone with approval rights accepts it. A rejected proposal is recorded and is not proposed again. See Approvals, Baselines & Drift.
Next
- Protection — what the configuration says is backed up or replicated.
- Recovery Plans & Readiness — how approved applications become an ordered plan.