How verification works

A backup is only as good as its last verification. Files rot, drives die, cloud objects get corrupted, the wrong file ends up in the right place. Tusk treats verification as a first-class part of the system, not a bolted-on check-box.

BLAKE3 hashes

Tusk uses BLAKE3 to fingerprint every file in every project. BLAKE3 was picked because it's fast (much faster than SHA-256, which matters when you're hashing terabytes of footage), well-vetted cryptographically, and produces fixed-size 32-byte digests that are cheap to store and compare.

The hash gets computed once during the first transfer of a file, recorded in Tusk's index, and used as the source of truth for every future verification.

End-to-end verification on transfer

Every transfer Tusk runs (offload, sync, restore) computes the source hash and the destination hash and compares them. If they match, the destination copy is recorded as verified with a timestamp. If they don't match, the transfer fails and is retried.

For local-to-local transfers, Tusk reads the source bytes and writes to the destination, hashing both ends. For cloud uploads, Tusk uses the provider's ETag / checksum header where possible (S3 returns a hash you can compare against the multipart-upload pieces; B2 and R2 handle this similarly), with a HEAD-then-stat fallback for providers that don't expose a usable checksum directly.

What gets re-verified, and when

Tusk re-verifies on three cadences:

• On project open: when you click into a project, Tusk runs a fresh verification pass over the project's files in the background. The file table shows live progress per row. Most projects finish verification in a few seconds; very large projects take longer because cloud destinations take more round trips.
• On a heartbeat for the active project: the project page you're looking at gets re-verified against its destinations every 3 minutes for local drives and every 3 hours for cloud destinations. Background projects (other projects you're not actively viewing) don't pay this cost.
• On manual re-check: clicking Re-check on a row, or the refresh icon on a cloud column header, runs a fresh stat (drive) or HEAD (cloud) pass for that specific scope right now.

What “verified” actually means

When Tusk shows a file as Synced on a destination, three things have all been true at some point:

• The bytes Tusk wrote to the destination match the source bytes.
• The destination's response (or stat call) confirms the file is there at the expected size.
• A re-verification within a recency threshold returned the expected hash or stat.

The last one matters: a file Tusk hasn't verified in three months still shows Synced, but the row's tooltip shows the staleness. If you're about to do something destructive (bulk delete local), you should run a fresh re-check first.

What happens when verification fails

If a re-verification finds that a file's hash on a destination has changed (bit rot, accidental edit, partial deletion), Tusk:

• Flips the destination's status for that file from Synced to Error.
• Logs the discrepancy with both the expected hash and what was found.
• Sends a notification surfacing the file and the destination.
• Offers a Redistribute action to overwrite the corrupted destination copy with a verified one from another destination.

The file is never auto-overwritten. You decide whether to redistribute, restore, or investigate further.

What's outside Tusk's reach

Tusk verifies what it wrote. It can't verify what it didn't write. If you have files in a backup destination's folder that Tusk didn't put there (you copied them manually before adding the destination, or another tool wrote them), Tusk doesn't see them. The empty-folder requirement when adding a destination is designed to prevent this exact mixup.