For the complete documentation index, see llms.txt. This page is also available as Markdown.

Applications Backup & DR

The Applications Backup & DR feature enables you to back up, monitor the backup process for, and restore your applications and the infrastructure they depend on using an Infrastructure‑as‑Code (IaC)–first approach.

This feature integrates application resilience directly into day‑to‑day cloud operations, enabling teams to define application backup policies, monitor the backup process, and restore applications using Infrastructure as Code (IaC).

Overview

Applications Backup & DR helps teams:

  • Define application‑level backup policies across cloud providers

  • Gain clear visibility into snapshots, coverage, and backup health

  • Recover predictably by restoring infrastructure as Terraform

  • Keep environments consistent under pressure with IaC‑first disaster recovery

This approach ensures consistent, repeatable recovery workflows during incidents.

Application Policies

Application policies define which applications are backed up and when backups are executed. Applications are identified using tags, which represent logical groupings of cloud resources.

Creating an Application Policy

To create a new application backup policy:

  1. Go to Applications Backup & DR → Policies

  2. Click Create Policy

  3. Configure the policy fields:

    • Policy Name (required, unique)

    • Data Source (AWS, Azure, GCP, OCI etc.)

    • Region

    • Tags (required key-value pairs that define the application scope)

    • Schedule Frequency (On-Demand, Daily, Weekly, Monthly)

Once created, the policy becomes active and generates application snapshots based on the selected schedule.

Policy Scope and Application Relationships

When a policy targets an application component (for example, an EC2 instance), Firefly automatically captures all required relationships and dependencies needed to restore the application correctly, such as:

  • VPC

  • Subnet

  • IAM instance profile

Resources that are implicitly created as part of these relationships and dependencies are not backed up separately, as they are recreated during restoration.

The following assets are not eligible for backup:

  • Deleted assets

  • Assets in an undetermined state

Comparing Snapshots

Every snapshot is automatically compared to the snapshot taken immediately before it. The result is stored with the snapshot and appears in the Changes column of the Snapshots tab as a delta bar showing how many resources were added, removed, and changed. The first snapshot of an application has nothing to compare against and is labelled Baseline.

To compare two snapshots directly:

  1. Open the Snapshots tab of the application

  2. Select the checkboxes of the two snapshots you want to compare

  3. Click Compare

The comparison opens in a modal grouped into Added, Removed, and Configuration Change, with the asset type tagged per resource and a line-level view of the configuration JSON for changed resources. Comparison is available only between snapshots of the same application.

AI Analysis

Select AI Analysis in the comparison modal header to generate a plain-language summary of the comparison — for example, whether the changes are configuration-only or potentially destructive. The summary is generated only when you select it; it does not run automatically.

Deleting a Snapshot

Deleting a snapshot removes its configuration data and its own comparison result. The comparison that belongs to the next snapshot is kept — Firefly never recalculates it against a different snapshot and never removes it in the background.

When you open a comparison whose earlier snapshot has been deleted:

  • The modal title shows that snapshot's timestamp dimmed, followed by a Deleted tag

  • The line Stored comparison — cannot be recomputed. appears below the title

  • Hovering the Deleted tag shows when the snapshot was deleted and by whom

The comparison itself still works in full, including AI Analysis, because the result was stored when the snapshot was created. In the Snapshots tab the Changes column is unchanged; hovering the delta bar notes that the comparison was made against a snapshot that has been deleted.

Deleting the oldest snapshot does not promote the next one to Baseline — the next snapshot keeps its stored comparison.

Before deleting, the confirmation dialog states how many comparison results will be removed and how many later snapshots will keep theirs marked as compared against a deleted snapshot. Deletion cannot be undone.

Restoring Applications

Applications are restored by generating Terraform code, rather than performing direct cloud mutations.

Restoring from a Snapshot

To restore resources:

  1. Open a snapshot

  2. Select one or more resources

  3. Click Restore Selected

  4. Preview the generated Terraform code

  5. Continue with Firefly's IaC orchestration flow

This ensures restored resources remain:

  • Fully codified

  • Auditable

  • Aligned with existing IaC standards

Common Use Cases

  • Recover infrastructure after accidental deletion

  • Restore a subset of resources without impacting the entire environment

  • Recreate infrastructure in a different region using Terraform

  • Validate backup coverage and compliance across teams

Notes & Limitations

  • Restoration availability depends on Terraform provider support

  • Large snapshots may take longer to load resource inventories

  • Snapshot comparison is available only between snapshots of the same application

  • A stored comparison cannot be recomputed after either snapshot is deleted

  • Deleting a snapshot is permanent; snapshots and their own comparison results cannot be restored


Applications Backup & DR provides a safety net for your cloud infrastructure by ensuring you can quickly recover from incidents while maintaining consistency with your Infrastructure as Code practices. By treating disaster recovery as code, teams can test, version, and automate their recovery procedures just like any other infrastructure component.

Last updated

Was this helpful?