A six-person edit house does not have an IT department. It has a senior editor who is good with computers, who ended up owning the network because nobody else would, and who thinks about backup roughly twice a year — once when a drive dies and once when a client asks about data handling on a new contract. That person is the hero of this guide.
Most advice about backup is written for one of two audiences. Solo-freelancer guides assume one Mac, one external drive, one credit card on file. Enterprise guides assume a dedicated IT team. The 2-to-10-person studio sits in the middle, and it is where a surprising number of teams quietly drop the ball. Your surface area is too big for Time Machine and a shared Dropbox. Your headcount is too small for a Veeam deployment and a quarterly audit.
The shape of a working small-team backup is not complicated. It is just specific. This is the guide we would hand to the senior editor, the lead designer, or the technical director who has just realised that they are the person who owns this now. It is a companion to our complete guide to Mac backup in 2026, focused on what changes once there is more than one Mac in the room.
What makes small-team backup different
A solo freelancer has one failure domain: their Mac, their drives, their accounts. A small studio has five to fifteen overlapping failure domains. The lead editor’s laptop has the current cut of a client project. The finishing station has the colour-graded master. The shared NAS has the last three years of deliverables. The producer’s MacBook Air has the contract PDFs and the invoicing spreadsheet. All of them are one drive failure away from ruining a week.
The second thing that changes is that work crosses machines. An editor hands a locked cut to a colourist, who hands a graded master to a sound designer. Each handoff produces a new “one copy that matters,” and each copy lives on a different Mac. A strategy that protects one of those Macs perfectly but ignores the others is not protecting the project. It is protecting a slice of it.
The third thing is the person running the tech. A small studio almost never has a dedicated IT lead. It has a creative director who ended up with the admin password, or an editor who set up the NAS and therefore owns the NAS forever. That person is extremely good at their actual job and is fitting backup in around the edges. Any system that requires specialist knowledge to diagnose will fail in a way that nobody catches until they need it.
And finally, there is key-person risk. Small studios under-invest in documentation because everyone already knows how everything works. Right up until they do not.
If the only person who understands how the backup works leaves on a Friday and the drive fails on a Monday, the backup is not really a backup. It is a hostage situation.
Inventory your real surface area
Before you buy or configure anything, write down what you actually have. Not what you think you have — what is physically plugged in and logged into right now. A small studio almost always has more surface area than its owner can recite from memory.
List every Mac by person and role. A Mac mini running as a render node counts. The old iMac in the corner that someone occasionally uses counts. The producer’s personal MacBook that they use for studio work two days a week counts, and is probably the most awkward entry on the list.
List every attached drive. The 8 TB Thunderbolt RAID on the lead editor’s desk. The 4 TB bus-powered SSDs that travel between stations. The archive drive in the fireproof drawer that gets plugged in once a month.
List every shared folder. The NAS volume. The iCloud folder for reference material. The Dropbox Business folder for deliverables. The Google Drive folder that nobody remembers creating but that contains the last year of invoicing.
List every cloud service that holds working data: Frame.io pages, client FTP accounts, Adobe Creative Cloud libraries, a Notion workspace. Each has its own owner, its own sync behaviour, and its own failure modes.
And list every device that leaves the studio. Laptops that go home every night. The producer’s iPad. Each is an extension of your studio’s data perimeter, and each can carry data out — or bring ransomware in.
The finished list is usually uncomfortable. That is the point. You cannot design a backup strategy around a surface area you have not measured.
Who owns what — the account model matters
Half the work of small-studio backup is not backup. It is account hygiene. Who owns the Apple ID on each Mac? Who owns the cloud storage that holds client deliverables? Who owns the password manager seat? If the answer to any of those is “a specific person who is not the studio owner,” you have an offboarding problem waiting for you.
The right model is boring and clear. Each Mac has an Apple ID tied to the employee, but the data that matters to the studio lives in accounts the studio owns. Cloud storage is on a business plan with admin rights held by the studio. Password managers use a team vault for shared credentials. Backup software is seated to the studio, not to an individual’s email address.
The reason this matters is not bureaucratic. The day someone leaves, you need to return their machine, reassign their backup seat, and retain their work without chasing them for a password. macup for business is built around this model: seats are managed by the studio, access is revoked centrally, and a departed employee’s backed-up data stays within the retention window you have configured. Getting the former employee’s iCloud Drive out of your shared folders is the hard part.
The shared-archive problem
Every small creative studio has a shared archive. On a NAS, a Thunderbolt RAID, a stack of hot-swap bays. It holds last year’s projects, reference footage, stock libraries, fonts, LUTs, mastered deliverables that clients might ask for again. It is usually the largest data volume in the studio, and it is almost always the least backed-up.
The trap is that shared archives feel safe. The NAS has RAID. A drive can die and the array keeps running. That is not a backup — that is redundancy. RAID protects against single-disk failure. It does not protect against accidental deletion, ransomware, controller failure, fire, theft, or the common failure mode where the array rebuilds after a bad disk and introduces fresh corruption across the remaining drives. A working archive volume and a backup of that archive volume need to be two different things, in two different failure domains. Read drive failure in 2026 for the forensic detail.
The second trap is that shared archives are often nobody’s job. The lead editor set up the NAS in 2022. No single person owns the backup, and so no single person notices when it stops running. Back up the archive as its own destination, on its own schedule, with an explicit owner — a human name, not a role — who gets a notification if it has not completed in three days. And read the retention policy glossary entry before you set the schedule, because archive retention is a different problem from working-file retention.
Client-work boundaries
Client work has a lifecycle. A project comes in, runs, delivers, and enters a long tail where the client might come back and ask for a re-edit or a ten-second cutdown for social.
The practical question is how long you hold. Most studios we talk to land somewhere between one and three years for project files, and indefinitely for masters and delivered files. The legal answer depends on your contracts. The financial answer depends on how much archive storage costs, which is a smaller number than most studios realise. The operational answer is that you should decide the policy explicitly, write it down, and configure your backup destinations to enforce it.
Keep client deliverables in their own directory structure, separate from working files and internal studio assets. At project close, move the folder to the archive volume and snapshot it as a named milestone. That snapshot is what you restore from when the client calls in eighteen months. A snapshot is a cheap, immutable, point-in-time reference — much more useful than a folder you hope nobody has touched.
A concrete setup we’d recommend
Enough abstraction. Here is what we would actually run for a six-person video studio — four edit suites, two finishing stations, a shared NAS, roughly 8 TB of active project storage and 30 TB of archive. The numbers scale down for a smaller studio and up for a larger one, but the shape is the same.
Each of the six Macs runs continuous backup locally, with a primary destination on an attached SSD sized at roughly 1.5× the machine’s internal drive. That is the fast-restore path — the one you use when an editor trashes a project bin at 11 PM and needs it back before the morning review. Pulling 400 GB over Thunderbolt is a ten-minute job. Pulling it from the cloud is not.
Each of the six Macs also backs up continuously to a managed cloud destination with immutable retention. This is the off-site leg. It protects against fire, theft, a ransomware event that encrypts everything on the network at once, or an employee who deletes a project folder on the way out. We would use macup Cloud here because it ships with Object Lock compliance mode enabled by default — even a compromised admin account cannot delete the backups inside their retention window. Our pricing page has the per-seat numbers for a six-seat team.
The shared NAS gets its own backup, to its own cloud destination, on its own schedule. This is the piece most studios skip, and the piece that matters most when the worst happens. The NAS holds archive, which means it holds the things hardest to re-create. Point it at an immutable cloud destination with a retention window that matches your client-hold policy. Expect the initial seed to take days.
And finally — the part that makes the whole thing real — run a cross-Mac restore drill once a month. Pick a machine, pick a project folder, restore it from cloud to a scratch drive on a different Mac, and open the project. Time it. A drill that takes fifteen minutes tells you the system works. A drill that takes four hours tells you the system does not, and tells you so on a Tuesday when nothing is actually on fire. Cloud versus local backup covers the restore-speed trade-offs.
The admin dashboard moment
Once you have five or more Macs backing up, you need a view that answers one question: is everyone actually backing up? Not every day, not in real time, but weekly — is every machine green, is every destination reachable, is every seat active.
macup’s admin dashboard exists for this five-minute weekly check. You open it, you see a row per machine with last-successful-backup timestamps, and you see any machines that have drifted into yellow or red. If everything is green, close the tab. If something is red, have a conversation with the person whose machine it is before it becomes a recovery scenario. It is boring, which is what you want.
Offboarding and departed team members
Someone leaves. Maybe they leave well — a planned departure, two weeks’ notice, a handover. Maybe they leave badly — a Friday afternoon, an awkward conversation, a locked Mac that you need to reclaim. Either way, the backup system needs to handle it without ceremony.
The sequence is: return the device, reassign the licence, revoke the access, retain the data. macup is designed around that sequence. The departing employee’s seat can be reassigned to an incoming hire without losing the backup history of the device. The device itself can be wiped and issued to a new person, and their backups pick up under a new seat. The departed employee’s backed-up data stays in the studio’s retention window — not theirs — and is recoverable by an admin for as long as your policy says. Our help article on recovering a departed employee’s data walks through the exact steps.
Access revocation is adjacent enough to mention. Remove the departing employee from shared cloud folders, the team password manager, the NAS shares, any third-party services seated to their email. Do it the day they leave. A departed employee with continued access to the shared archive is a quiet risk that does not announce itself.
The failure modes we see in small studios
Three scenarios recur, and all three are preventable.
The first is the studio-wide drive that nobody owned. A 16 TB RAID in the corner, holding four years of work, backed up by — as it turned out — nobody. Every person on the team assumed someone else had configured it. The drive did not fail dramatically. It developed bad sectors slowly over six months, the RAID papered over them, and a later rebuild completed successfully but with thousands of files silently corrupted. The fix is ownership. Every volume has a name next to it.
The second is the lead editor’s laptop that held the one copy of the project file. The studio had cloud backup on the NAS but not the laptops, because the laptops “were just for working on files that lived on the NAS.” Except for the two-week stretch when the lead editor was travelling, during which the project file lived on the laptop, and only the laptop, and the laptop got left in an airport. The fix is treating every machine as a failure domain, regardless of what the official workflow says.
The third is the ransomware event on a shared NAS. A phishing email, a credential harvest, a lateral move, a silent encryption pass overnight. The studio discovered it in the morning when nothing would open. Their backup of the NAS was a second volume inside the same NAS, encrypted along with everything else. The only recovery path was the off-site immutable cloud copy. The fix is that one of your backup copies must be immutable and off-site. There is no substitute.
Closing
The goal is not a perfect backup. It is a good backup that is actually running. A studio that runs continuous backup on every Mac, backs up the shared archive as its own destination, keeps an off-site immutable copy, and does a five-minute weekly check is protected against everything short of a simultaneous fire and meteor strike. It is also maintainable by a creative director with a day job, which is the only test that matters.
The setup we have described is available on a 14-day trial with no credit card. Seat it to the studio, roll it out to each Mac, point it at macup Cloud, run a restore drill in the second week. If it works, renew. If it does not, tell us why. We would rather hear about it before you need it than after.