Tusk is a Mac app that automatically backs up your project folders to multiple locations and tracks where every file lives — even when your drives aren't connected.
An Ableton Live Set that plays perfectly today can open next year with an orange bar reading "media files are missing." The .als file you saved is not the song. It's a set of instructions pointing at samples, recordings, and presets scattered across your Mac, and any of those references can break when files move, drives change, or a sample pack gets reorganized.
Backing up an Ableton project properly means two things: making the project self-contained (that's what Collect All and Save is for), and then keeping verified copies of the project folder somewhere other than your laptop. Live handles the first part. It does nothing about the second.
TL;DR: Run Collect All and Save to copy every external sample into the project folder, making it self-contained. Live's automatic Backup folder protects you against bad saves, not against drive failure: it lives inside the same project folder. For real safety, back up the whole project folder to at least two destinations you control. A tool like Tusk watches your projects folder, copies changes to an external drive and cloud automatically, and verifies every file with a checksum.
How Ableton Live stores a project
When you save a Live Set for the first time, Live creates a Project folder containing:
- The .als file: the Live Set itself. It's a compressed XML file, usually under a few megabytes. It contains your arrangement, automation, and device settings, but not your audio.
- Samples/: audio that belongs to the project.
Recordedfor audio you tracked in this project,Processedfor files Live rendered (freeze files, consolidated clips),Importedfor samples collected from elsewhere. - Ableton Project Info/: project metadata. Leave it alone.
- Backup/: automatic backups of recent saves (Live 11 and newer; more below).
The catch: samples you dragged in from your sample library, your Downloads folder, or another project are referenced, not copied. The .als points at their original location. Your project folder looks complete and isn't.
What Collect All and Save actually does
File > Collect All and Save copies every external file the Set references into the project's Samples/Imported folder and updates the references to point at the copies. Live asks which categories to collect: files from elsewhere, from other Projects, from your User Library, and from factory Packs. For an archive-ready project, answer yes to all of them. Factory Pack samples feel safe to skip until you open the project on a machine, or in a future, where that Pack isn't installed.
After a Collect All and Save, the project folder is self-contained: copy the folder, and everything Live needs for that Set travels with it.
Three things Collect All and Save does not do:
- It doesn't touch plugins. VST and AU instruments and effects are software installed on your Mac, not files in the project. A collected project still needs Serum installed to play the Serum parts. For long-term archiving, freeze tracks that rely on third-party plugins (right-click the track, Freeze) before your final save; the freeze files land in
Samples/Processedand the music survives even if the plugin doesn't. - It doesn't create a second copy. Everything still lives on one drive, typically the one in your laptop.
- It doesn't verify anything. If a sample was already corrupted, it gets collected corrupted.
Where Ableton's automatic backups live
Since Live 11, every save also writes a timestamped copy of the .als into the project's Backup folder, keeping the last 10. If you break a project with a bad edit, or save over something you shouldn't have, open a backup .als from that folder and you're back to an earlier state. The copies are small because they're only the Set file; they reference the same samples.
Two limits matter. The Backup folder only versions the .als, not your audio: record over a take and the old audio is gone regardless. And it lives inside the project folder on the same drive, so it protects you from yourself, not from drive failure, theft, or a spilled drink. If the drive dies, the backups die with it.
For crashes: Live detects an improper shutdown on the next launch and offers to recover the unsaved work. That recovery covers the gap since your last save, but it's a courtesy, not a system. Save early, save often, and let the Backup folder do its job.
The actual backup: get the project folder off your Mac, twice
Once Collect All and Save has made the project self-contained, the unit of backup is the project folder. The standard worth following is the 3-2-1 rule: three copies, two types of storage, one offsite. For a producer that typically means the working copy on your Mac, a copy on an external drive, and a copy in cloud storage.
You can do this by hand, dragging project folders to a drive after every session. Almost nobody keeps that up through a deadline. The failure mode isn't the session where you forget; it's the month where forgetting became the habit.
This is the part Tusk automates. Point it at the folder where your projects live (say ~/Music/Projects, or one Tusk project per album or client), add two backup destinations, for example an external SSD and a Backblaze B2 bucket, and it handles the rest: every save Live writes, including the Backup folder versions, gets copied to both destinations and verified with a BLAKE3 checksum, so a copy only counts once the bytes are confirmed intact. The file table shows per-file status on every destination, including drives that are unplugged. When a finished album is eating your laptop's SSD, Delete local clears the local copies after physically checking that every file is verified on every destination, and Restore brings the whole project back when the remix request arrives.
Worth adding as their own tracked projects: your User Library (default presets, custom racks, default Set) and any purchased sample packs that would be painful to re-download.
To be clear about fit: Tusk is a backup tool, not version control. Versioning within a project is the Backup folder's job; Tusk's job is making sure the entire project folder, versions included, exists in more than one place. It also can't make a project self-contained; that's Collect All and Save. The two steps do different work, and skipping either leaves a hole.
The five-minute setup that ends the problem
- Keep all projects under one parent folder (
~/Music/Projectsor per-client folders). - Before closing a session that matters, run
File > Collect All and Save, all categories on. - Freeze plugin-heavy tracks before archiving a finished project.
- Back the parent folder up to two destinations, one of them offsite. Automate it so it survives deadline weeks.
- Once copies are verified, you can clear local space with a clean conscience.
The .als you saved tonight is instructions. Make sure the things it points at, and the folder they live in, exist somewhere a single dying drive can't reach.
FAQ
It copies every external file your Live Set references (samples from your library, other projects, your User Library, and optionally factory Packs) into the project's Samples/Imported folder, then updates the Set to reference those copies. The result is a self-contained project folder you can move, archive, or back up as one unit. It does not include plugins, and it doesn't create a backup copy anywhere else.
Open the Backup folder inside your project folder in Finder. Live 11 and newer keep timestamped copies of the last 10 saves of your .als there. Double-click one to open that earlier version, then use Save As if you want to keep it. The backups only cover the Set file, not your audio recordings.
Relaunch Live. It detects the improper shutdown and offers to recover your unsaved changes; accept and immediately save the recovered Set. If the recovery prompt doesn't appear or fails, your fallback is the newest timestamped .als in the project's Backup folder, which reflects your last successful save.
Yes, the .als copies in a project's Backup folder can be deleted safely; they're small and only exist as fallback versions. Deleting them frees little space (the audio lives in Samples, not in Backup) and removes your ability to roll back to earlier saves, so for archived projects it's usually worth keeping them.
Save the Set into its own project folder, and before closing run File > Collect All and Save with all categories enabled so external samples are copied into the project. Freeze tracks that depend on third-party plugins. Then back up the whole project folder to at least one other drive or cloud destination; a self-contained folder on a single drive is still one drive failure from gone.
No. Plugins are applications installed on your Mac, not files inside the project, so no project backup includes them. Keep a list of the plugins each project uses (or freeze those tracks so they're rendered to audio), and keep your plugin installers and license files backed up separately.
It helps, and it's worth running, but it has gaps for project work: it backs up to a single destination, usually sitting next to your Mac, and doesn't give you per-project visibility or an offsite copy. Pair it with a second backup of your projects folder to an external drive and cloud. A tool like Tusk adds per-file verification and shows you which projects are fully backed up where.