Your Song's Second Life Starts With a Folder: The Case for Restore-Tested Archiving

There's a folder on my studio drive called FINAL_final_REALfinal. It's from a track I finished in 2019, and last month I tried to open it on a fresh laptop. The session loaded. The plugins didn't. Forty minutes later I was staring at a gray dialog box that said something about a missing authorization and a serial number I'd long since thrown away with the email. The song still exists, technically. It's just no longer a song I can touch.

That experience is why I've started thinking about archiving less like backing up a hard drive and more like arranging a piece of music. What you keep, and how you keep it, determines what the track is allowed to do next — get remixed, get licensed for a sync spot, get revisited by a collaborator who wasn't born yet when you tracked it. Preservation is a creative act. It just happens to involve checksums.

The Session File Is Not the Song

The first mental shift is admitting that your DAW project file is not the artwork. It's a set of instructions for reconstructing the artwork, and those instructions depend on a small ecosystem of software that may or may not exist in 2036. A .logicx or .als or .rpp file is a promise made to a specific version of a specific program on a specific operating system. Break any link in that chain and you've got an expensive paperweight with a nice waveform icon.

So the archive needs to answer a different question than the session file does. The session file asks "how do I get back to where I was?" The archive asks "how does anyone get back to where I was, on a machine I've never seen?"

Freeze Stems, But Freeze Them Thoughtfully

Everyone says "print your stems," and everyone is right, but the details matter more than the slogan. My current practice is to print stems at the bus level — drums, bass, keys, vocals, effects returns — not at the individual track level. Bus-level stems preserve the mix decisions that took me hours to make. Track-level stems preserve the raw material for someone to redo those decisions badly. Both have value, so I keep both, but I label them differently: stems_mixprint for the bus prints, stems_raw for anything that might need to be rebuilt from scratch.

Print them at the session's native sample rate and bit depth, not at whatever you're uploading to streaming. The archive is a master, not a distribution copy. And do it in one pass, from bar one to the end, with all the automation live — a stem that starts mid-song because you forgot to select the whole arrangement is a stem you'll be cursing in a decade.

Write Down the Plugins, All of Them

This is the part everyone skips and it's the part that kills sessions. I keep a plain text file in every project folder called plugin_manifest.txt. It lists every third-party plugin used, the version number at the time of the final bounce, and a one-line note about what it was doing. Not a novel — just "ValhallaVintageVerb 2.5.1 — main vocal plate" or "Kontakt 7.6 with Albion ONE — string bed."

The manifest isn't for reopening the session (that ship may have sailed). It's for a future engineer who needs to know what they're approximating. If I know the vocal plate was a Valhalla VintageVerb on the 1970s setting, a good mixer in 2036 can get close with whatever they've got. If I don't tell them, they're guessing.

Pair that manifest with a screenshot of the mixer. Not a fancy export — just a full-screen grab of the session showing track names, fader positions, and plugin slots. It costs ten seconds and it's worth more than any metadata schema I've tried.

Embedded Metadata Beats a Separate Readme

I used to keep a notes.txt next to every project. I stopped, because separate files get separated. Now the essential info lives inside the files themselves where possible. BWF metadata on the stems: session title, date, engineer, sample rate, a short description. The same info in the DAW project's own notes field. If your DAW supports it, embed the plugin manifest as lyrics or comments or whatever text field your format offers.

The point is redundancy by design. If the folder structure survives, great. If someone pulls a single stem out of the folder and drops it in a timeline, the file should still tell them what it is and where it came from.

Checksums Are Boring and That's the Point

A checksum manifest is a text file listing every file in the archive with a cryptographic hash next to it. Run it once when you close the archive, run it again whenever you move the archive to new media, and you'll know instantly whether anything corrupted in transit. It's not glamorous. It's the difference between knowing your archive is intact and hoping it is.

I use a simple shell one-liner to generate mine — shasum -a 256 * > manifest.sha256 on macOS — and I keep the manifest in the root of the archive folder. When I migrate to new drives every three or four years, the first thing I do is verify the manifest on the old drive before copying anything. If a file fails, I know before I've overwritten the only good copy.

The Restore Test Is the Only Test That Counts

Here's the ritual that has saved me twice now: once a year, pull one archive at random and restore it on a machine that has never seen the project. Not your main rig. Not a machine with your plugin library installed. A clean laptop, ideally one that's a few OS versions behind, because that's the machine a future collaborator will actually be using.

Open the project. Can you load the stems? Do they line up? Does the metadata read correctly? Does the plugin manifest tell you enough to reconstruct the mix if you had to? Write down what broke. Then fix the archive so it doesn't break the same way next year.

The first time I did this, I discovered that my "archive" was really just a copy of the project folder, and half the stems were references to files outside it. The restore test caught it. Nothing else would have.

What You Choose to Keep Is an Editorial Decision

All of this is presented as technical hygiene, but it isn't. Every decision about what to freeze, what to document, what to throw away is a decision about what the song can become. A stem archive with the effects returns printed is a song that can be remixed but not re-arranged. A raw multitrack archive is a song that can become anything, at the cost of fidelity to what you actually made. A plugin manifest is an argument about what mattered.

None of this is about hoarding. It's about making the archive legible to someone who wasn't in the room. That someone might be you in 2036, or a licensor, or a collaborator you haven't met. Either way, you're not just saving files. You're deciding what the song is allowed to say next.