Set how long backups are kept

Five settings on one page decide what stays on disk. All of them live in Settings → Backups, apply to every node (they are copied to every node) and can be changed only by an Owner. Administrators can read them and can manage the S3 targets on the same page.

Before you start

• You are signed in as an Owner. For anyone else the page says You can see these settings; only an Owner can change them.
• Nothing is deleted by switching a setting off. A setting stops new copies; it never removes what is already kept.

Steps

Choose what is kept

1. Open Settings in the sidebar, then Backups, and find What is kept.
2. Under Keep, choose one:
   • Both — archives for disaster recovery, snapshots for undo. This is the default.
   • Backup archives only — no snapshots are taken.
   • Snapshots only — no scheduled archives, and no off-site copy.
3. Click Save.

With snapshots only, nothing is copied off-site, because snapshots never leave the node. A site whose care package sells backups still gets scheduled archives. Backups Hyperion takes internally to undo a move, a copy or a staging push, and the backup before automatic updates, run in every mode.

Delete local copies once they are verified off-site

1. Find Local copies.
2. Tick Delete the local copy once it is verified off-site. It is off by default, because a local copy gives a faster restore and a second copy at the cost of disk.
3. Set Keep the newest anyway (0 to 1000 per site, default 0, 0 keeps none).
4. Click Save.

Before you turn on local-copy deletion

What is lost. After each backup of a site, the local archive and database dump of that backup and of every older backup already off-site are deleted, except the newest ones set here. A restore of such a backup then comes from the off-site copy and needs a download.

Verify first. Run a backup, then open the site’s Backups tab and check that its Off-site column shows off-site ✓ for the FTP target, or that you have listed the S3 object. A local copy is deleted only after Hyperion re-checks that each off-site copy exists, never on a finished upload alone. The check compares size for FTP and unencrypted S3, and existence for age-encrypted S3 combined with a fully successful push. A copy that cannot be confirmed is kept and the row says why (local kept: not confirmed off-site). A node with no off-site destination deletes nothing.

Undo. A deleted local copy cannot be brought back from the panel except by restoring it from the off-site copy.

Turning this on frees a site’s existing copies after its next archive backup. To free them now use Copy off-site & delete local under Maintenance (all sites), or Off-site & drop on a row of the site’s Backups tab. Both upload first when a copy is not off-site yet, and keep any copy they cannot confirm.

Set archive retention

1. Find Archive retention.
2. Set Delete archives older than in days (1 to 3650, default 30).
3. Set Always keep the newest (1 to 1000 per site, default 5).
4. Click Save.

When a backup of a site completes, its archives older than the age are deleted from the node. Its newest successful archives are always kept, however old, so a site nobody touches still has its last few. Failed and running rows do not count towards the newest ones. A profile or care plan can set a longer history for one site, which overrides these two numbers for that site. Off-site copies follow their own rule: each target keeps the newest copies per site set on it.

The full backup before automatic WordPress updates has its own rule and is not counted among the newest ones. After a clean batch it is deleted 24 hours later; after a failed batch it stays until the next one replaces it.

Set snapshot retention

1. Find Snapshot retention.
2. Set Delete snapshots older than in days (0 to 3650, 0 means never by age) and Always keep the newest (0 to 1000 per site).
3. Click Save.

Until this card has been saved once, snapshots follow Archive retention. Age is counted from today. Old snapshots are deleted once a day on every node and straight after each new snapshot.

Turn the trash on

1. Find Trash under Deleted sites.
2. Tick Move deleted sites to Trash first. It is off by default.
3. Set Keep them for in days (1 to 365, default 30).
4. Click Save.

What the trash keeps and how to restore from it is in Delete backups, snapshots and sites. A delete runs on the node that owns the site and reads that node’s copy of this setting.

Check that it worked

• After Save, the page returns to the same card with the new values and a status pill (for example the Local copies pill).
• Retention shows up on the site’s Backups tab: after the next backup, rows older than the age and beyond the newest N disappear. Snapshots show expiring when the next sweep will delete them.

If it fails

• The agent's settings could not be read (…). These are defaults, not what is set, so saving is off until it answers.: the node’s agent is not answering. Wait for it, reload, and check Service health.
• No local copy was deleted: [backup] keep_local_latest in this node's agent.toml is not a whole number (in the job log of a Copy off-site & delete local run): correct Keep the newest anyway and run it again.
• local kept: not confirmed off-site under a backup’s Off-site cell: the copy could not be confirmed, so it was kept. Hover for the reason, fix the target and run the next backup.