Restore
Restore everything
Bring an entire archived project back. Tusk reads from whichever destination is fastest and verifies as it writes.
The Restore everything action pulls every file in a project back into the project's primary folder. Use it when:
- You're reopening a project you offloaded and deleted locally a year ago.
- You're moving a project to a new Mac.
- Your local copy got corrupted or lost and you need to rebuild from backup.
Tusk reads each file from the fastest verified source it has. Local drives beat cloud destinations. Connected drives beat disconnected ones. If both options are local, Tusk picks the one with the higher recent throughput. You don't have to choose; the engine routes per-file automatically.
Where to start it
1
Open the project
From the projects overview, click the project you want to restore.
2
Open the More actions menu
The three-dot menu lives in the project header next to the project name. Click Restore everything.
3
Confirm the destination folder
Tusk shows the project's primary folder as the restore target. You can change it (e.g. restore into a different local drive) or accept the default.
4
Click Restore
Tusk queues every file's restore. The project page shows live progress: file count, bytes copied, current file, transfer speed. The job runs in the background; close the window if you want.
Screenshot
Restore-everything confirmation modal showing the source summary (147 files, 312 GB across 2 destinations), the target folder with a Browse button to override, and the 'Restore everything' button.
alt: The restore-everything confirmation modal
How Tusk picks the source
Per file, Tusk evaluates the available verified copies and picks the best one. The order roughly:
- Connected local drives, fastest first.
- Connected NAS shares.
- Cloud destinations with the lowest cost-per-GB egress (R2 wins on this dimension).
- Anything else available.
For very large restores, consider connecting your fastest local drive that holds a copy of the project before starting. A 4 TB restore from a USB-C SSD takes hours. From a cloud provider on a residential connection, it can take days.
Verification on restore
Every file Tusk restores is verified against the BLAKE3 hash recorded in the project index. If the bytes that arrive don't match, the restore for that file fails and is retried automatically (with a different source if available). If every source has the same wrong hash, Tusk surfaces the file as an error and you can decide what to do.
What if the destination folder isn't empty?
If the target folder already contains files with the same paths as files in the project, Tusk asks before overwriting. Two choices:
- Skip files that already exist: leaves the on-disk copies alone. Useful when you're restoring into a folder that already has some of the files (a partial earlier restore, or an editor that auto-restored some side files).
- Overwrite existing files: replaces the on-disk copies with the verified versions from backup. Tusk warns first.
Pause, resume, cancel
Restore everything supports the same controls as offload. Pause stops new file transfers; resume picks up; cancel ends the job (files already restored stay where they are). The full pause/resume semantics are on the Pause, resume, retry page.
Restoring just part of the project? Use Restore folder instead.
Related