About Cloud Workload Backup Policies

With a cloud workload backup policy, you choose which of your cloud resources Eon backs up, how often Eon takes snapshots, how long it retains them, and where it stores them.

This article explains the options for backing up cloud workloads:

Resource selection: Which resources the policy applies to, set with dynamic selection and manual overrides.
Backup schedules: How often Eon takes snapshots and, for PiTR policies, how often it takes point-in-time backups.
Scan schedule: A policy with classification conditions can also have a scan schedule, where its type supports one. It sets how often Eon scans resources again to keep the policy’s resources current.

Backup policy types

This table shows the different types of backup policies for cloud workloads and the resources they support.

Type	Description	Supported resources
Standard	The most common type of backup policy. Use when you don’t need a high frequency or point-in-time recovery backup policy.	All resources*
High frequency	Backs up supported resources as often as every 15 minutes. Use when you need to back up some resources more frequently than the standard backup policy supports.	EC2, S3, DynamoDB, Google Cloud Storage, RDS and Aurora PostgreSQL (after change data capture setup)
Point-in-time recovery	Backs up databases hosted on a VM, or leverages cloud-native point-in-time capabilities.	RDS and Aurora, SQL database on Azure VM, BigQuery

*For most resources, standard backup policies store snapshots in Eon vaults. Some resources support storing snapshots in cloud-provider-managed vaults in the source accounts instead. See Storage options below.

Storage options

Standard backup policies typically store snapshots in Eon vaults across AWS, Azure, and GCP. However, some resources support alternative storage options, including the cold tier and cloud-provider-managed vaults in your source accounts.

When you create a standard backup policy, you can choose where to store snapshots:

Vault: Backs up assigned resources to your Eon vault. Resources backed up with this method are processed through your scanning account and, if applicable, are available through the file explorer and database explorer.
Vault cold tier: Backs up assigned S3 buckets to the cold tier of an Eon vault in AWS, a lower-cost tier for data that has few deletions or overwrites and is rarely restored. Supported resources: S3. For when to use it, costs, and retention, see Cold tier.
AWS source account: Backs up assigned resources to an AWS Backup Vault in the source account. Resources backed up with this method aren’t scanned and aren’t available through the file explorer or database explorer. Supported resources: FSx, EFS, and RDS.
Azure source subscription: Backs up assigned resources to an Azure Recovery Services vault in the Azure source subscription. Resources backed up with this method aren’t scanned and aren’t available through the file explorer or database explorer. Supported resources: Azure file shares (classic).

Resource selection

Resources can be assigned to a backup policy using a combination of dynamic resource selection and manual overrides. Dynamic resource selection sets the baseline for which resources are included in the policy by default. Manual overrides allow you to include or exclude resources by ID, regardless of whether they’re included in the dynamic selection.

The options for dynamic selection are:

Include all: All resources are included in the backup policy by default. If the policy type doesn’t support all resources, only the supported resources are included.
Use conditions: Only the resources that match the conditions you set are included in the backup policy by default. If new resources that meet the conditions are discovered, they’re also included in the backup policy. With classification conditions, a resource can also join or leave the policy after a recurring scan updates its classification.
Exclude all: No resources are included in the backup policy by default. Using this option means that, unless you include resources with manual overrides, no resources are backed up by the policy.

With Include all or Use conditions, the list of resources assigned to the policy can change over time. As Eon discovers new resources that match the policy’s selection criteria, those resources are automatically included in the policy and backed up on the next scheduled run.

Conditions

Conditions are the logic that determines which resources the backup policy applies to. You can set conditions against specific resource properties, like environment, data classes, or tags. You can set a simple AND or OR list of conditions, or you can group conditions for fine-tuned targeting of resources.

This image shows a set of conditions with groups and individual conditions:

A condition is a single, atomic logical unit that’s made up of a property, an operator, and a value.
A group is a collection of conditions that are evaluated together as a logical unit. Groups can contain any combination of conditions and nested groups.
The logical operator applies to all the component conditions or groups on a single level. Every group has an AND or OR logical operator.

Manual overrides

Manual overrides allow you to include or exclude resources from a backup policy by resource ID, overriding the dynamic selection.

You can provide IDs for resources that aren’t in your inventory yet, but that you anticipate will be discovered at some point in the future. For example, you might have a resource in a source account you haven’t connected yet, but you want to back it up anyway. When the resource with the provided ID is discovered, your manual override will take effect.

You can also provide IDs for resources that are already in your inventory.

When to use classification conditions

A classification condition lets a policy pick up and drop resources as your data changes.

Compliance-driven protection: Back up everything that contains PII daily and keep it for seven years.
New or changed data catches up: A resource that gains PII is assigned to the policy after the next scan, with no manual list.

Classification conditions

A classification condition is a condition on the Data classes, Sensitivity level, or Apps property. A classification condition belongs to a backup policy. It’s unrelated to a classification policy, which is a separate policy type that schedules classification scans without creating snapshots.

A scan updates a resource’s classification, so a policy with a classification condition needs a recurring scan, a classification scan that Eon runs on a schedule, where the policy type supports one, to keep its assigned resources current.

How a resource joins and leaves a policy

After a scan, a resource whose classification matches the condition becomes assigned to the policy. When the resource stops matching, Eon removes it from the policy, and the policy no longer schedules backups for it.

Existing backups stay until their retention expires.

The scan also includes resources already assigned to the policy, so their classification stays current. A resource can be assigned to several policies at once, and no policy takes priority over another.

Scan schedule

A recurring scan creates no snapshot, so its schedule has no retention period and no vault.

When a policy has classification conditions, the Schedules step of the policy wizard shows a Recurring classification schedule control below the backup schedules. The Schedule type you choose for backup schedules, basic or advanced, also applies to the recurring scan. In advanced mode, the Schedules are in setting applies to the recurring scan as well.

The frequency can be daily, weekly, monthly, or annually.

By default, Eon scans daily at 00:00 and sets the start time range automatically. For the steps, see Create Cloud Workload Backup Policies.

A scheduled scan can be skipped when it overlaps a backup or another scan. When the overlap is with a backup, the backup classifies the resource instead.

You can set a recurring scan on standard policies that store snapshots in a vault, on high frequency policies, and on PiTR policies for SQL Server and SAP HANA databases on VMs.

The Store snapshots in option limits which resource types a policy supports. The Available for line shows them. A recurring scan is available only for policies that store snapshots in a vault, and it covers only resources of a type Eon can scan. Resources backed up at the block level are scanned but have no file data, so only Apps conditions can match them.

Examples

These rules decide what each recurring scan includes:

Eon ignores classification conditions and scans the resources that match the rest of your conditions.
An OR that includes a classification condition removes the limit from the whole group it’s in, which at the top level means no limit at all.
Eon ignores a negated classification condition, such as Data classes contains none of PII, when it chooses what to scan, and still applies negations of other properties, such as Resource name does not start with tmp-.

Back up only the production resources that contain PII

You set Environment is one of Production AND Data classes contains any of PII. The recurring scan includes resources that match Environment is one of Production. Eon ignores the classification condition and scans what’s left, so the scan stays within production.

Back up everything that contains PII

You set Data classes contains any of PII. The recurring scan includes every resource of a type Eon can scan. Any of them could gain PII later, so none can be left out. Use this when the rule is “all data with PII, wherever the data is stored”.

Back up production, plus PII anywhere else

You set Environment is one of Production OR Data classes contains any of PII. The recurring scan includes every resource of a type Eon can scan, because a resource outside production could still gain PII and join the policy. This scans the same set as the previous example.

Drop only part of a limit with a group

You set Environment is one of Production AND (Resource name starts with db- OR Data classes contains any of PII). The recurring scan includes resources that match Environment is one of Production. The OR inside the group removes only that group’s limit, so the db- name limit goes and the production limit stays.

Backup schedules

Schedules control the frequency of how often Eon takes a snapshot of your resources, as well as the retention period and vault where the snapshot is saved. A policy with classification conditions can also have a separate scan schedule.

This section covers:

Basic schedules
Advanced schedules
PiTR schedules (for point-in-time recovery policies)

Basic schedules

With basic schedules, you’ll choose the frequency, and Eon automatically sets the start time for backups.

Basic schedules use this pattern:

Frequency	Start time
Daily	00:00 every day
Weekly	00:00 every Sunday
Monthly	00:00 every first day of the month
Annually	00:00 every first day of the year

Advanced schedules

Advanced schedules offer more flexibility and control than basic schedules, but they require more upfront configuration. With advanced schedules, you’ll set the desired start time and an acceptable start time range between 4 and 22 hours.

The available schedule options depend on the frequency you choose. For frequencies smaller than a day, Eon sets the start times at regular intervals beginning at 00:00 and calculates the start time range.

PiTR schedules

For point-in-time recovery policies, you’ll set PiTR schedules to control the frequency of PiTR backups. PiTR schedule frequency can be every hour, 30 minutes, or 15 minutes.

PiTR schedules must conform to these requirements:

A vault can be used by one PiTR schedule.
The vault in a PiTR schedule must be used by a backup schedule whose frequency is daily or more frequent, and whose retention period is longer than the PiTR retention period.

BigQuery PiTR backup policies don’t use PiTR schedules or vaults. Instead, they leverage BigQuery’s native time travel feature with a fixed 7-day retention window. For more information, see GCP: BigQuery Support.

Source account storage configuration

When storing snapshots in the source accounts, additional configuration options are available during policy creation:

Vault protection (AWS source account): Enhances security for AWS Backup Vaults by applying vault locks or creating logically air-gapped vaults. Vault protection modes include None, VaultLockGovernance, VaultLockCompliance, and AirGapped. See Create Cloud Workload Backup Policies for details on configuring vault protection.
Backup storage redundancy (Azure source subscription): Determines how Azure replicates data in the Recovery Services vault (LRS, ZRS, or GRS). This setting is immutable after the vault is created. For details on redundancy options, see Azure: File Share (Classic) Support. For configuration steps, see Create Cloud Workload Backup Policies.