Tusk Logo

Tusk

Backup integrity

Live deletion detection

What happens when something else removes a file from one of your backup destinations.

Tusk doesn't assume nobody else touches your destinations. People accidentally drag-delete folders in Finder. Cloud admins set up lifecycle rules that purge old objects. A drive comes back from the shop and half the files are missing. Tusk catches all of these the next time it verifies and surfaces them clearly.

How Tusk detects it

Verification (covered in detail on the How verification works page) compares Tusk's recorded state for each file against what the destination actually has. When a file Tusk expects to find on a destination is missing, the verification flips the status for that destination to Missing.

For external drives, this happens on every connection (Tusk runs a fresh stat pass when the drive mounts). For cloud destinations, this happens on the periodic re-verification (every 3 hours for the active project) and on every project open.

Screenshot

File table row with one destination cell showing a Missing badge (dashed outline, warning icon) and a tooltip saying 'File missing on Backblaze B2 since 2026-05-07 14:23'. Other destination cells on the same row show Synced badges.

alt: A row in the file table showing one destination as Missing

What the file table shows

The affected file's row gets a Partial overall status (some destinations have it, this one doesn't) and the per-destination cell shows Missing. The tooltip on the cell shows when Tusk last saw the file there and when it discovered it was gone.

A Missing destination cell auto-surfaces the Redistribute row action. One click pushes a verified copy from another destination to fill the gap.

What gets reported in notifications

When Tusk detects deletions during a verification pass, it posts a single notification per project per pass with a summary: how many files went missing, on which destination, and a deep link to the file table filtered to show just those rows. This keeps the notification panel quiet during a one-off cleanup (you get one notification for “47 files missing on B2”, not 47 separate notifications).

What it doesn't do

Tusk doesn't auto-redistribute when it detects a deletion. The decision to push a file back to a destination that lost it is yours. Reasons we don't auto-fix:

  • You may have intentionally removed the file from that destination (e.g. moved cold archive to a different cloud).
  • The destination may be in a bad state and writing to it might compound the problem.
  • Quietly fixing things behind your back makes it impossible to debug systematic issues later.

Click Redistribute when you want the fix. Tusk does the rest.

The case where everything went missing

If a destination shows nearly every file as Missing in a single verification pass, something bigger went wrong: the destination drive was reformatted, a cloud bucket was wiped, you connected the wrong drive that happens to share a label, etc. Tusk doesn't pretend this is normal. The Drives or destinations panel surfaces a banner asking you to confirm what you want to do:

  • Re-create from other backups: redistribute everything missing from the other destinations. Use this when the destination is now empty and you want it back to a full mirror.
  • Stop syncing to this destination: pause sync to this destination so you can investigate. The file index keeps the historical state for reference until you resume or remove the destination.
  • Forget this destination from the project: removes the destination from the project entirely. Doesn't touch any remaining files on it.

Connect drives via cable; trust your tools

The most common cause of false-positive Missing reports is a drive connected over a flaky cable or hub. If you see Missing reports on a drive that should be intact, try a different cable or port before assuming data loss. Re-check once the drive is freshly mounted.