Skip to main content
Retention policies let you automatically expire old snapshots while preserving a defined history. This guide explains how to use the forget command with policy flags to implement backup rotation strategies.

How Retention Policies Work

Cloudstic’s retention system uses an OR-based approach:
  • Snapshots are evaluated against all active policies (-keep-last, -keep-daily, etc.)
  • A snapshot matching any policy rule is kept
  • Snapshots matching no rules are removed
  • Multiple policies can apply to the same snapshot (e.g., a snapshot can be both “daily” and “weekly”)
Running forget only removes snapshot metadata. To reclaim storage space, run prune afterward (or use -prune to do both in one step).

Available Retention Flags

Basic Examples

Keep Only the Latest Snapshots

Keep the 7 most recent backups, remove everything older:
Always preview with -dry-run first:

Keep 30 Days of Daily Backups

Keep one snapshot per day for the last 30 days:
How it works:
  • Snapshots are grouped by date (YYYY-MM-DD)
  • The most recent snapshot from each day is kept
  • Days with no snapshots are skipped

Keep Weekly Backups

Keep one snapshot per week for the last 8 weeks:
Weeks are defined by ISO 8601 (Monday is the first day of the week).

Common Retention Strategies

Strategy 1: Simple Daily Rotation

Keep 7 days of backups:
Use case: Personal backups with daily snapshots, minimal history.

Strategy 2: Grandfather-Father-Son (GFS)

Keep recent, daily, weekly, and monthly backups:
Use case: Production systems requiring multiple recovery points. Breakdown:
  • Last 7 snapshots (any time of day)
  • One per day for 30 days
  • One per week for 8 weeks (~2 months)
  • One per month for 12 months (1 year)

Strategy 3: Long-Term Archival

Keep recent backups plus yearly archives:
Use case: Compliance requirements, historical records. Breakdown:
  • Last 14 snapshots
  • One per day for 90 days (~3 months)
  • One per week for 52 weeks (1 year)
  • One per month for 24 months (2 years)
  • One per year for 5 years

Strategy 4: Frequent Recent, Sparse Historical

Many recent backups, fewer old ones:
Use case: Development environments, active projects.

Understanding Policy Evaluation

Grouping

By default, snapshots are grouped by source, account, and path before policies are applied. This means each backup source is managed independently. For portable drives with a detected volume UUID, snapshots are automatically grouped by volume UUID instead of account and path. This means all backups of the same drive, from any machine, share one retention group.
Change grouping behavior with -group-by:

Filtering

Apply policies to specific snapshots only:

Multiple Policies Example

Combine multiple retention rules:
How this works:
  1. keep-last 5: The 5 most recent snapshots are kept (regardless of age)
  2. keep-daily 7: One snapshot per day for 7 days is kept
  3. keep-weekly 4: One snapshot per week for 4 weeks is kept
  4. Any snapshot matching any of these rules is kept
  5. All other snapshots are removed
If a snapshot matches multiple rules, it’s still only kept once (but labeled with all matching reasons).

Previewing Changes with Dry Run

Always preview before removing snapshots:
Output:
Once satisfied, run without -dry-run:

Running Forget Without Prune

You can separate snapshot removal from storage reclamation:
Prune is a safe operation. It only deletes chunks that are not referenced by any remaining snapshot.

Automating Retention Policies

Combine backup and retention management in scripts:
backup.sh
Schedule with cron:
See the Automation guide for more details.

Advanced Filtering

Per-Source Policies

Apply different retention rules to different backup sources:

Tag-Based Policies

Use tags to control retention:

Best Practices

1

Always use -dry-run first

Preview changes before committing:
2

Combine forget and prune

Use -prune to reclaim storage immediately:
3

Run retention after every backup

Keep your repository tidy by automatically removing old snapshots:
4

Document your retention policy

Keep a record of your policy for disaster recovery planning.
5

Test restoration periodically

Verify you can recover files from kept snapshots:

Troubleshooting

”No snapshots to remove”

All snapshots match at least one keep rule. Either adjust your policies or this is expected behavior.

Prune Removes No Data

Chunks may still be referenced by other snapshots, or packfiles may need time to compact. Run prune again after removing more snapshots.

Unexpected Snapshot Removal

Check grouping behavior with -group-by. By default, snapshots are grouped by source, account, and path.

Next Steps

Restoring Files

Recover files from retained snapshots

Automation

Automate retention policies with cron

Check Command

Verify repository integrity after pruning

Forget Command

Full reference for the forget command