> For the complete documentation index, see [llms.txt](https://docs.firefly.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.firefly.ai/key-features/backup-and-dr.md).

# 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.firefly.ai/key-features/backup-and-dr.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.