Backup EnginebackupEngine
Docs/Desktop Agent/Cleanup on Delete

Cleanup on Delete

When you remove a backup set, the cleanup dialog lets you choose what other artefacts (uploaded data, diagnostic logs, report history) to wipe alongside it.

Why a Dialog?

Pre-1.11.8, deleting a backup set removed only the local set record. The uploaded chunks, the diagnostic-runs log files on the local disk, and the server-side report history were all left in place. That suited some users (“remove the schedule, keep the data”) and frustrated others (“I'm done with this — wipe everything”). v1.11.8 turns deletion into a three-way decision instead of an all-or-nothing one.

The Three Checkboxes

  • •Also delete uploaded backup data — wipes every chunk + manifest at every destination this set is configured for. CANNOT BE UNDONE — restores from this set become impossible. Default OFF (destructive option, must be explicitly checked).
  • •Also delete diagnostic logs on this machine — the per-run text files written under <appdata>/Backup Engine/diagnostic-runs/<setId>-*.log. Cosmetic; deleting them frees a few MB of disk. Default ON.
  • •Also delete report history (server-side) — every entry in the Reports tab for this set. Default OFF (preserves audit history; the Reports tab still shows the rows even after the set is gone).

⚠ Warning

Checking “delete uploaded backup data” turns the action button red and adds an explicit warning panel inside the dialog — there is no undo. If you uncheck it and just want a clean local state, the chunks remain at the destination and a future re-creation of the set will dedup against them automatically.

Walk-through

  • •On the Backup tab (Files) or Server Backup tab, click the Delete button on the set you want to remove.
  • •The "Delete <set name>?" dialog appears with three checkboxes (defaults: data OFF, logs ON, reports OFF).
  • •Tick the boxes for whichever artefacts you want to wipe.
  • •Click "Delete" (or "Delete + wipe data" if you ticked the destructive option).
  • •A snackbar reports what was actually removed: e.g. "Deleted set + 3 logs + 412 reports". From version 1.38, if the server keeps the set (see below), the snackbar says why and nothing was removed.

When the server keeps the set (version 1.38)

From version 1.38 the app deletes the set on the server first and removes nothing on this computer — not the set, not its logs and not its uploaded backup data — unless the server agrees. The snackbar then shows why the set was kept:

  • •Legal hold — "This backup set belongs to a computer on legal hold and can't be deleted." Your company has placed this computer on a legal hold, so none of its backup sets can be deleted from the account: not here, not in the customer portal and not by support. The app also takes the server's copy of the set again at its next sync.
  • •No connection — "Couldn't reach the server to delete this backup set, so nothing was removed. Try again when this computer is online."
  • •Any other refusal — "The server did not delete this backup set, so nothing was removed." followed by the server's reason.

⚠ Warning

Version 1.37 and earlier remove the set and, when ticked, its uploaded data without asking the server; the set then reappears from the server, possibly without its data. Keep computers that are on a legal hold on version 1.38 or later, and ask whoever placed the hold to lift it if a set really must go.

What Each Checkbox Actually Does

In code, removeBackupSetWithCleanup runs roughly this sequence
for each destination configured for the set:
  list keys with prefix users/<userId>/sets/<setId>/
  delete each chunk + manifest key

if delete_diagnostic_logs:
  glob <appdata>/Backup Engine/diagnostic-runs/<setId>-*.log
  unlink each match

if delete_reports:
  DELETE /functions/v1/reports?backup_set_id=<setId>
  (server-side: deletes every backup_reports row for this set)

ALWAYS:
  delete the local backup_sets row + scheduler_lock
  notifyListeners()

ℹ Note

The reports DELETE was extended in v1.11.8 to accept ?backup_set_id= for bulk delete — previously it only deleted single rows by ?id=.

Recovering After You Wipe Data by Mistake

If you ticked “delete uploaded backup data” the chunks at every destination are gone. We do not retain a server-side trash bucket — the destination is the source of truth and a delete is a delete. If you have a copy of the backup at a second destination (the multi-destination feature), you can recreate the set pointing at the surviving destination and restores work normally.

⚠ Warning

This is one of the strongest arguments for multi-destination backup sets. A second destination (cloud + local, or two clouds) means a destructive action against one is recoverable from the other. See Multi-Destination Backup.
Backup SetsScheduling