Lesson 3 of 9 · BEFORE AN INCIDENT · 3 min read

Dependency capture: what a tool must record to rebuild an application

Short answer

A recovery tool can only rebuild what it knows an application depends on: the network it runs in, the roles it assumes, the records that point at it. Dependency capture is the record of those links, taken before the incident. Firefly, Arpio and Cohesity each describe a way of capturing dependencies, and they differ in where the record comes from.

What is a dependency in cloud recovery?

A dependency is anything a resource needs in order to work. A virtual machine needs a subnet, the subnet needs a VPC, the machine needs an instance profile and the profile needs an IAM role. A database needs its subnet group and its security group. Bring any of them back without the others, or in the wrong order, and the rebuild fails or produces something that starts but cannot serve traffic.

Where can the dependency record come from?

There are three common sources, and the tools on this site use different ones.

  • Discovery from the live environment. The tool reads the cloud account and records which resources refer to which. Firefly's docs describe backup policies that capture the dependencies an application needs, such as the VPC, subnet and IAM instance profile.
  • Continuous mapping during replication. Arpio describes dependency mapping across services and resources as part of continuous replication.
  • Existing infrastructure-as-code definitions. Cohesity's Cloud Rebuild uses validated IaC definitions to discover dependencies, which means the record is only as complete as your templates.

Commvault Cloud Rewind describes capturing whole application stacks, across compute, storage, networking, databases and security, which implies the same record; it does not describe the mechanism on the pages we reviewed.

Why does the source matter?

Discovery from the live environment catches resources nobody wrote down, including those created by hand. Relying on existing IaC is clean when everything is in code, and blind to whatever is not. Ask each vendor what happens to a resource that exists in the account but not in any template.

How does capture relate to recovery speed?

A tool that already holds the dependency graph can order the rebuild for you. Without it, someone works out the order during the incident, which is the slowest part of a manual recovery. That is why recovery orchestration carries 15% of the weight in our scores.

What happens to resources outside the record?

Every method misses something. Discovery can miss resources in accounts the tool cannot read. Replication can miss services the vendor does not support. IaC-based rebuilds miss whatever was never written down. The safest plan states, per application, which method holds its dependency record and how the gaps are found, for example by comparing the record with a fresh inventory before each recovery test.

What should you take from this lesson?

Pick one critical application and list its dependencies by hand. Then ask each shortlisted vendor to show its own record for the same application, and compare the two lists.

Sources