Back up the folder, and you've backed up the whole library

The question "how do I back up my reference library" usually assumes the library is something separate from the files it contains — an app-managed store somewhere in a Library folder, invisible to a normal file browser, needing its own export step before a backup tool can see it. That's a reasonable assumption, because a lot of creative software works exactly that way. It's also not how this one is built, and the difference is worth understanding before setting up a backup routine, because it changes what "proper" actually means here.

That assumption is worth naming because it usually comes from real experience with a different kind of tool — one where "the library" lives in a package file, a proprietary database format, or a folder buried three levels inside ~/Library/Application Support, invisible unless you go looking with Finder's "Go to Folder" and the exact path memorised. Backing up that kind of tool properly means finding that hidden location first, which is itself a step people forget, discover too late, or get wrong by backing up an old cached copy instead of the live one. None of that applies here, precisely because none of it exists to find.

None of what follows requires learning a new tool, either. The advice below is mostly a description of what's already true — which folder actually holds everything, and what to check about the backup you probably already run — rather than a new routine layered on top of an existing one.

What actually lives where

Everything a workspace needs — the index database, the thumbnails, the proxies rendered for canvases — is written inside the same folder you pointed the app at when you registered it. Nothing is written to a hidden system folder, an application-support directory, or anywhere outside the root you chose.

That's the entire workspace. A backup tool that copies ~/Pictures/Reference copies the client folders, the source images, the database, the thumbnails and every canvas file in one pass — because none of those things live anywhere else.

Step 1: Confirm what your current backup already covers

Before changing anything, check whether whatever already backs up your Mac — Time Machine, a cloud backup service, a manual copy to an external drive — already includes the folder a workspace is registered against. For most people the answer is yes, because reference folders usually live under ~/Pictures or ~/Documents, which general-purpose backup tools cover by default.

If the reference folder sits somewhere a backup tool explicitly excludes — a folder marked to skip, or a drive that isn't included in the backup set at all — that's the one thing actually worth fixing, and it's a setting in the backup tool rather than anything specific to this app.

It's worth actually checking this rather than assuming it, since backup tools accumulate exclusion rules over time for reasons that made sense once and are easy to forget — a rule added years ago to skip a large cache folder that no longer exists, or a scratch-disk exclusion that happens to overlap with where reference material got added later. A five-minute look at the backup tool's include and exclude list, specifically checking the exact folder a workspace is registered against, is worth doing once rather than discovering a gap the day it matters.

Step 2: Don't back up the app separately from the folder

There's no separate application-level export to remember, and no settings file living outside the workspace that a folder backup would miss. The temptation to look for an "export my library" button doesn't apply here because there's nothing held back from the folder to export in the first place — a habit worth unlearning if it's carried over from a different tool.

Step 3: Treat an external drive the same way as an internal folder

If a workspace is registered against a folder on an external drive, backing it up follows the same rule — the folder is the whole workspace regardless of which physical drive it sits on. What's worth adding for an external drive specifically is a second copy: an external drive is itself a single point of failure, so a workspace living entirely on one unbacked-up external disk is one drive failure away from being gone.

Step 4: Verify the restore, not just the backup

A backup that's never been restored is a plan, not a guarantee. Periodically restoring a folder to a scratch location and pointing the app at it — even just once, to confirm the workspace opens and the canvases render — catches a corrupted backup or a folder that was silently excluded long before an actual emergency forces the question.

This step is the one people skip most often, because a backup that's running on schedule feels finished — the indicator light is green, the last run completed without an error, and there's a natural assumption that "it ran" and "it would actually restore" are the same claim. They aren't always. A restore test doesn't need to be elaborate: copying the backed-up folder to a new location, registering it as a temporary workspace, and confirming the file count and a couple of ratings look right is enough to catch the two most common failures — a backup that silently stopped running weeks ago, and one that's been quietly excluding part of the folder the whole time.

Step 5: Know what re-indexing recovers if a database is ever lost

If the database file specifically were ever lost or corrupted while the image files themselves survived, re-registering the same root and letting it re-index recovers the searchable facts — dimensions, format, dates — because those are read straight off the files again. What a re-index can't recover on its own is anything you typed by hand: tags, ratings and notes. That's the actual argument for backing up the whole folder rather than treating the image files and the database as separable in importance — the database is where the manual work lives, and it's exactly as replaceable as any other file in the folder, which is to say: not automatically, only from a backup.

Why canvases specifically don't need special handling

A .coii-canvas file is pretty-printed JSON, saved inside your own folder rather than inside the database. That means a canvas gets backed up, version-controlled or diffed by exactly the same tools that already handle every other file in the folder — there's no separate canvas-export feature to remember, because a canvas was never something the app was holding onto outside of ordinary files in the first place.

That also means a canvas is readable in ten years regardless of whether this app is still the one being used to open it — cat-able JSON doesn't stop being JSON when a backup ages.

Step 6: Treat a canvas file backup as evidence, not just insurance

Because a .coii-canvas file is plain text, a version-controlled backup — something like a periodic commit to a private repository, rather than only a blind copy — gives you something a binary backup can't: an actual diff of what changed on a board between two dates. That's a stronger guarantee than most creative software can offer about its own project files, and it costs nothing extra to get, since the file was already going to be backed up as part of the folder either way.

A worked example: a two-tier backup for an active workspace

A reasonable setup for someone actively adding to a library: Time Machine or an equivalent running continuously on the internal drive, covering the workspace automatically without a separate step, plus a manual or scheduled copy of the same folder to a second physical location — a NAS, an external drive kept off-site, or a cloud backup service — for the case where the whole machine, not just one file, is lost.

Neither tier requires anything from the app beyond the folder itself being reachable, which is the whole point of not having a separate export step to forget.

Registering a workspace and turning on whatever backup routine already protects the rest of the Mac are really the same decision made twice, once for the app and once for the operating system, and the second one is usually already done before the first ever happens.

Why a folder-based workspace makes this simpler, not just different

It would be easy to read all of this as "backup works the same as any other folder, so there's nothing to say" — but the simplicity is itself the point worth naming. A tool that stores its database somewhere outside your folders creates a second thing to remember, a second location to check, a second failure mode where the images are backed up but the tags and ratings describing them are not, silently, because nobody thought to check both locations were covered by the same backup plan. Collapsing that down to one folder removes an entire category of backup mistake, not just the inconvenience of remembering where the second location was.

It also means the backup routine doesn't need to change as the library grows or moves. A workspace that starts on an internal drive and later migrates to an external one, or a folder that gets renamed as a project matures, doesn't require updating a second backup rule somewhere else to match — there's only ever the one folder, wherever it currently is, and whatever backs up your Mac already knows how to follow a folder that's been renamed or relocated within the same backup set.

Common mistakes worth avoiding

Waiting until a library "feels important enough" to back up properly — the files worth searching by rating and tag on day one are, by definition, already worth not losing, and the backup routine doesn't need to wait for a library to reach some threshold of size or seriousness before it starts mattering. Assuming there's a hidden app-support folder somewhere that also needs backing up — there isn't, everything is inside the root you registered. Backing up the images but excluding hidden or unfamiliar-looking files inside the folder, on the assumption they're temporary — the three files a workspace writes are the database, thumbnails and proxies, and skipping them means a restore comes back with the images but not the tags, ratings or notes attached to them. And treating an external-drive workspace as implicitly backed up because it "feels" more permanent than an internal folder — a drive is a drive, and one copy of anything is still one copy.

What to do when the library gets large

Backup time scales with the size of the folder, not with anything specific to how the app organises it, so a forty-thousand-file library takes longer to back up than a four-thousand-file one for the same reason any large folder does. Thumbnails and proxies add real size on top of the source files — worth accounting for when estimating how much backup storage a workspace actually needs, since they're not negligible at video-heavy scale.

What a proxy file actually is covers what's in that added size and why it's there. What happens to a library if the app itself stops being maintained is worth reading alongside this page — it's the same underlying argument, that everything staying in your own folder is what makes both backup and long-term survival straightforward. Building a library from folders you already have and organizing what's already indexed cover the steps that come before backup is worth thinking about at all, and the fuller feature set this workflow assumes is worth reading for the rest of what a folder-based workspace looks like day to day. The one-time-purchase shape of the app itself is worth reading if durability and cost are both part of the same decision. Or try it against your own folders — thirty days, every feature, no card and no account — long enough to register a workspace and confirm your existing backup routine already reaches it.