The offload concept

Most days, you save files into your project folder and Tusk syncs them to your destinations from there. Offload is for the other case: you have a pile of files on an SD card or external source that need to land on your backup destinations, and ideally without sitting on your Mac on the way.

When you offload, Tusk reads the source once and writes to every destination in parallel. One read, N simultaneous writes. Local-to-local plus cloud uploads happen at the same time, gated only by your slowest destination. The card isn't read multiple times. Your Mac doesn't need enough free space for a full local copy.

What problem this solves

You come back from a shoot with three SD cards full of footage. Total size: 800 GB. Your Mac has 200 GB of free space. Without an offload tool, the path looks like:

1. Card to Mac (700 GB doesn't fit, you're stuck before you start).
2. Mac to drive 1.
3. Mac to drive 2.
4. Mac to cloud.
5. Delete from Mac to make room.
6. Repeat.

With Tusk's offload, the same job looks like:

1. Card straight to drive 1, drive 2, and cloud at the same time.
2. Done. Card is verified. Eject and reformat.

The card is read once. Your Mac is barely involved. The data gets verified with BLAKE3 checksums during the stream, so by the time the offload finishes, you know every byte landed correctly.

Where to start an offload

Two entry points, depending on whether the project exists:

• From project creation: enable the offload toggle in the new-project wizard to create a project around footage that's still on a card. Covered on the From project creation page.
• Into an existing project: click Ingest on a project to add files from a card or external source into a project that already exists. Covered on the Into an existing project page.

The copyLocally toggle

The single most important option in the offload flow.

• Off (the offload default): files don't land on your Mac. They go straight from the source to your destinations. Each file appears in the project file table as Remote only: a row that exists in the index, with verified backup status, but no local copy.
• On: files also land in your project's primary folder during the offload. Use this when you want to edit immediately without restoring first.

The default is off because the whole point of offload is to spare your Mac's storage. Turn it on when the project is small enough that a local copy makes sense or when you need to start editing right away.

What gets verified

During the stream, Tusk computes a BLAKE3 hash of the source bytes once and compares it against what it wrote to each destination. The verification happens during the transfer, not as a second pass. When the offload reports a file as done, you know:

• The bytes Tusk wrote to each destination match the bytes that came off the card.
• Every destination got a complete copy.
• The hash is recorded in Tusk's index for future re-checks.

What happens if something goes wrong mid-offload

The offload is fully resumable. The session state lives in Tusk's SQLite database, persisted to disk, so it survives:

• The source drive (or SD card) being unplugged accidentally.
• A destination drive being unplugged.
• Your internet dropping while a cloud destination is mid-write.
• Tusk being quit.
• Your Mac restarting.

When the missing piece comes back (you replug the card, the internet recovers), the session auto-resumes from where it stopped. No re-reading from the start, no redoing finished files. The Pause, resume, retry page covers the details.