Delete backups, snapshots and sites

Deleting is the step with the least room for error, so each delete below says what it removes, how to confirm a usable backup exists first, and whether it can be undone. Which copies a delete reaches depends on where they live: the node’s disk, the FTP / SFTP target, or S3. Deleting from the panel never touches S3.

Before you start

• You hold the Run backups permission to delete backups, snapshots and off-site copies, and Delete hostings to delete a site. The built-in Owner, Administrator, Operator and Customer roles have both. Only an Administrator or Owner holds Manage trash (restore / purge), which the trash needs.
• Open the site’s Backups tab and confirm there is another usable backup before you delete one. A usable one shows state ok, a plausible Size, and off-site ✓ if you rely on an off-site copy. How to check is in Back up a site and set a schedule.

Steps

Delete one backup

1. Open Hostings, open the site and open the Backups tab.
2. In Archives, click Delete on the row. A running backup cannot be deleted.
3. Read the dialog. It depends on where the backup lives:

Before you delete a backup

Local copy only (no FTP copy). The archive, its database dump and its manifest are removed from the node’s disk and the row disappears. A copy on S3 is not touched. This cannot be undone.

Local copy and an FTP copy. The default button Delete local copy removes the local files and leaves the FTP copy, which stays restorable. Tick Also delete it from the off-site FTP target and the button becomes Delete everywhere: the FTP archive and its dump go too. This cannot be undone.

FTP copy only (the row shows no local archive). The default button Remove the row only leaves the archive on the FTP server, still listed under Off-site copies. The box Delete it from the off-site FTP target is ticked by default, and the button then reads Delete from the FTP target: this is the last copy unless an S3 copy exists, and it cannot be restored afterwards.

If the FTP copy cannot be deleted, nothing is deleted and the panel says nothing was deleted — the copy on the off-site FTP target could not be: ….

4. Confirm. The panel answers Backup deleted. or Backup deleted, including its copy on the off-site FTP target.

Delete several backups

1. In Archives, tick the rows (or the box in the header).
2. Click Delete selected. The label under it counts the rows.
3. Confirm Delete local copies. If any row has an FTP copy, the dialog offers Also delete them from the off-site FTP target and the button becomes Delete everywhere.

A request deletes at most 100 backups. Rows that cannot be deleted are skipped and the message counts them: for example 3 backups deleted · 1 skipped (…).

Delete the local copy after it is off-site

Off-site & drop on a row (or Off-site & delete local for the ticked rows) uploads the backup if it is not off-site yet, re-checks that the off-site copy exists, and only then deletes the local archive and dump. A copy that cannot be confirmed is kept and the job ends red. The off-site copy stays restorable. Rollback copies that must stay on the node never show this button. See Set how long backups are kept.

Delete an off-site copy

1. Open Off-site copies at the bottom of the Backups tab.
2. Click Delete on the row and confirm Delete from the server.

The archive and its database dump are deleted from the FTP / SFTP server. If the row shows only off-site, this is the last copy there and it cannot be restored afterwards. An S3 copy is not touched.

Delete snapshots

Use Delete on a snapshot row, or Delete all snapshots (type the domain to confirm). See Take and restore snapshots. Neither can be undone.

Delete a site

Before you delete a site

What is removed. The nginx vhost, certificate, database (unless you keep it), PHP-FPM pool, extra FTP logins, the whole site directory under /home/<system user>/<domain>/, the Linux user (unless you keep it, and only when no other site uses it), DKIM keys, the site’s snapshots, git deploy secrets and the panel’s stored notes for the site. The site’s backup rows disappear from the panel.

What stays. Local archives remain on the node’s disk, where the panel can no longer list, download or restore them (see below), unless you tick Also delete this site’s backups on this node. FTP and S3 copies stay unless you tick the FTP option. DNS records at your provider are not touched.

Verify first. Open the site’s Backups tab. Check that the newest archive is ok with a .sql beside it, and that an off-site copy shows off-site ✓. Or run Back up now first.

Undo. With the trash on and no keep box ticked, restore it from Trash while it waits. Otherwise this cannot be undone; recovery is only from a backup.

1. Open the site and open the Danger zone tab. (In the Hostings list, Delete on a row opens a shorter dialog.)
2. Optionally tick Keep the Linux user or Keep the database. Either one makes the delete happen now even when the trash is on.
3. If you may run backups, you can tick Also delete this site’s backups on this node. Every archive, database dump and manifest of the site on this node goes with it, including files no backup record names. This cannot be undone. Without the tick, backups stay on the node. If a backup is running or an archive is being read, or a file cannot be removed, the site is left in place. The hctl command and the API do not offer this option.
4. Click Delete hosting.
5. If the site has a copy on the FTP target and you may run backups, the dialog offers Also delete this site’s backups from the off-site FTP target. Ticked, the button reads Delete with FTP backups: every archive and dump of the site on the FTP server goes too. If they cannot be deleted, the site is left in place. S3 and local copies are not touched.
6. Type the domain to confirm and click Delete permanently.

The delete runs as a Delete hosting job. With the trash on, the site is not removed but moved to the trash, and a backup choice (FTP or this node) is carried out when it leaves the trash. A restore from the trash forgets the choice.

Use the trash

The trash is off by default. Turn it on under Settings → Backups → Trash (Set how long backups are kept). Then Delete hosting sends the site to Trash in the sidebar instead:

• The site is offline: nginx answers 503 with a notice, the PHP-FPM pool is removed, the database user and the site’s logins are locked and its processes are stopped.
• Files, database, certificates and the Linux user are kept.
• After the retention time (default 30 days) the scheduler deletes it for good.

To bring a site back:

1. Open Trash in the sidebar. The table shows Domain, Node, Deleted and Auto-purge in.
2. Click Restore on the row. The site goes back to active. Expiry actions that fell due during its stay are cancelled, so set a new expiry if the site should still expire.

To delete it before the time is up, click Delete permanently, type the domain and confirm. This removes files, database, system user, snapshots and certificates now and cannot be undone. If FTP backups are deleted with it is shown under the domain, the FTP copies are deleted too, and if that fails the site stays in the trash. Backups on this node are deleted with it means the local backups go too.

Clean up files a deleted site left behind

1. Open Stats in the sidebar and find Backups by site.
2. A deleted site appears as <domain> · no such site on this server, with an orange untracked line under On server. These are archive files that no backup record names. Retention never removes them.
3. Click Delete untracked on the row and confirm Delete files. You need to see all hostings, have the View monitoring & stats permission and Run backups.

This cannot be undone. Recorded backups and running backups are not touched.

For leftover files on the FTP or SFTP target, see Delete backups left by deleted sites.

Bring back a deleted site from its leftover archive

1. Create the site again with the same domain, and a database if it had one.
2. Restore the leftover archive with From an archive already on the server, using the path /var/lib/hyperion/backups/local/<system-user>/<domain>-<timestamp>.tar.gz. See Restore a site from a backup.
3. Check the database name and credentials in the restored wp-config.php against the new site’s Database card, because the new database has its own credentials.

From the command line

sudo hctl backup delete example.com 42
sudo hctl hosting delete old.example.com
sudo hctl trash list
sudo hctl trash restore old.example.com
sudo hctl trash purge old.example.com --yes

hctl hosting delete accepts --keep-user and --keep-db, which delete now even with the trash on.

Check that it worked

• A deleted backup is gone from Archives. Check the disk:

  sudo ls /var/lib/hyperion/backups/local/<system-user>/

  Expected: no file with that timestamp.

• A deleted FTP copy is gone from Off-site copies, which lists the server itself.

• A trashed site is listed under Trash and answers 503. A deleted site is gone from Hostings, and the Delete hosting job on Background jobs shows Done.

If it fails

• refusing to delete a backup that is still running. Wait for it to finish (or fail) first.: wait for the job to end, then delete.
• no FTP/SFTP off-site target is configured on this node: you asked to delete FTP backups but no FTP target exists on the node. Delete without the option, or configure the target.
• could not delete the site's backups from the off-site target, so the site was left in place: …: the FTP delete failed and the site was not touched. Fix the FTP account’s delete permission and try again.
• hosting is already in trash — restore or purge it instead: use the Trash page.
• hosting must be in trash to restore: the site is not trashed, so there is nothing to restore.