> ## Documentation Index
> Fetch the complete documentation index at: https://clumio.reclear.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Protection model

> How policies, protection groups and rules compose, and why the separation lets protection scale.

Clumio separates *what a policy does* from *what it applies to*. Three objects carry that
separation, and understanding how they compose is the mental model behind almost every protection
task in this documentation.

```mermaid theme={null}
flowchart LR
  P["Policy<br/>frequency, retention, tier"] --> PG["Protection group<br/>the resources it applies to"]
  R["Protection rule<br/>matches by tag or name"] --> PG
  PG --> RES["Protected resources"]
  RES --> B["Backups"]
```

## The three objects

**A policy is the unit of intent.** It answers *how* something is protected: how often a backup
runs, how long it is kept, and which storage tier it lands in. A policy knows nothing about which
resources it covers.

**A protection group is the binding.** It connects one policy to a set of resources, either named
explicitly or matched by rule. A group is where "this policy" meets "these resources".

**A protection rule matches for you.** Instead of listing resources, a rule describes the
resources that should be enrolled — by AWS account, region, tag, or name — and the group picks up
everything that matches, including resources that appear later.

## Why the separation matters

Because matching is declarative, protection scales without per-resource work. An account that
gains a hundred new buckets tomorrow needs no new configuration: if the buckets match a rule, they
are protected, and if they stop matching, they leave the group.

This is also why the model has two failure modes worth knowing. A rule that is too broad protects
things you did not intend; a rule that is too narrow silently misses things you did. Both are
configuration questions, not product limitations — which is why the *pattern* of a rule matters
more than its individual conditions.

## Matching by tag or name

Rules match on tags and on names. Name conditions come in three forms: an exact match, a list of
accepted names, and a case-insensitive substring match. For EC2 instances and EBS volumes the name
is taken from the AWS `Name` tag, so resources without that tag have no name to match.

Names are useful where tags are inconsistent — teams that follow a naming convention, or resource
types where the name is already the natural identifier. Tags remain the better choice where
ownership or environment is what you are actually describing.

## Precedence

When more than one thing applies to a resource, the more specific wins: a policy assigned directly
to a resource overrides the policy that a matching rule would have applied. That gives you a way to
carve out an exception without dismantling the rule that covers everything else.

## Where the model has edges

Membership can change without you asking it to. Moving a protection group to a different
organisational unit deletes that group's rule, because the rule was written against the previous
scope and would otherwise re-evaluate against a wider one. Resources you added by hand stay in the
group; resources the rule had added automatically leave it. Existing backups are unaffected and
remain restorable until their retention expires.

That is a deliberate trade: a stale rule that suddenly matches more than intended is worse than a
rule that disappears and must be re-created knowingly.

## Where to go next

* [Backup policies](/protect/policies) — define the frequency, retention and tier.
* [Protection groups](/protect/protection-groups) — bind a policy to resources.
* [Protection rules](/protect/protection-rules) — enrol resources automatically.
* [Storage tiers](/protect/tiers) — choose where backups are kept.
* [Protect a resource](/api-reference/protect-resource) — the same model through the API.