B
acking up a Mac in 2026 is a different problem than backing up a Mac in 2016. The machine sitting on your desk almost certainly has a soldered SSD. The drive you plug into it is four times faster and twice as likely to die without warning. The ransomware families that used to ignore macOS now target it by name. The sync service you rely on — iCloud Drive, Dropbox, Google Drive — will faithfully replicate a deletion across every device you own in under sixty seconds.None of the old instincts quite work anymore. “Time Machine to an external drive” is still sound advice, but it is one leg of a three-legged stool. “Your files are in the cloud” is the single most dangerous assumption a working creator can make. And the backup schedule that made sense when you shot two weddings a month makes no sense when your working project is a 900 GB DaVinci database being edited at 2 AM.
This guide is the one we’d hand to a photographer, a video editor, a musician, or a designer who has just realised that the thing protecting their last five years of work is a Time Machine drive they haven’t unplugged since 2022. It is practical, it is opinionated, and it assumes you already know what a file is.
What actually counts as a backup
A backup is a copy of your data that lives on a separate device, in a separate failure domain, in a versioned form, that you have tested. All four conditions matter. Drop any one of them and you have a copy, but you do not have a backup.
Separate device means the backup is not on the same SSD as the original. If lightning takes out your MacBook, it must not also take out the backup. An APFS snapshot on the same disk is a wonderful thing — it is not a backup.
Separate failure domain means the backup is not vulnerable to the same event as the original. A second drive plugged into the same machine shares a failure domain with the first: a bad power supply, a spilled coffee, or a single ransomware process will take both. Geographic separation, or at minimum an off-site copy, removes that correlation.
Versioned means you can roll back to yesterday, to last week, to three months ago. A mirror — a one-to-one copy that updates continuously — is not versioned. If a corrupt file overwrites the original at 9 AM and your mirror syncs at 9:01, the mirror is now corrupt too. Versioning requires snapshots, which preserve point-in-time state even as new data is written. Every serious backup system is built on them.
Tested means you have actually restored from the backup, recently, and confirmed that the restored files open in the applications you use. A backup you have never restored from is a hypothesis.
This definition is why iCloud Drive, Dropbox, Google Drive, and OneDrive are not backups. They are sync services. Sync replicates state across devices — that is not what you want when the state you are replicating is a deleted folder or an encrypted one. Sync and backup solve different problems. You need both.
The snapshots-versus-mirrors distinction
A mirror says: “make destination look exactly like source, right now.” A snapshot says: “preserve the state of source as it was at this moment, forever, or until I tell you to forget it.” Carbon Copy Cloner and SuperDuper in their classic cloning modes are mirrors. Time Machine and any serious incremental backup system are snapshot-based. When we say “backup” in the rest of this guide, we mean snapshot-based, versioned backup — the kind that lets you recover a file from three weeks ago, not just from now.
What to back up
The correct answer for most working Macs is “everything in the home folder, plus the contents of any external drives you treat as part of your working set.” The granular answer is more interesting.
Creative application libraries
A 40 GB Lightroom catalog is not the same as 40 GB of JPEGs. The catalog is a single SQLite-backed bundle that changes every time you rate a photo, and the referenced raw files may be scattered across three external drives. Back up the catalog and the referenced originals. The same logic applies to a Logic session package — the project file is tiny, the audio files inside it are enormous, and losing either half is losing both. DaVinci Resolve project databases live in ~/Library/Application Support/Blackmagic Design/DaVinci Resolve/. Xcode projects live wherever you put them, but their DerivedData directory does not need to be backed up — it is cache.
The home folder, carefully
~/Documents, ~/Desktop, ~/Pictures, ~/Movies, ~/Music — obvious. ~/Library is the interesting one. It contains your application preferences, your mail database, your Messages history, your keychain, your Safari bookmarks. It also contains gigabytes of caches that change every minute and are worthless to back up. A good backup system lets you include ~/Library while excluding predictable junk: ~/Library/Caches, ~/Library/Application Support/*/Cache, browser Service Worker directories, and so on.
External drives that move with you
If you are a photographer with a 4 TB SSD of raw files that never lives on your internal disk, the external drive is your primary working storage. Treat it that way. Back it up with the same discipline you apply to the internal SSD — continuous, versioned, off-site.
Password managers and keychains
1Password, Bitwarden, and the macOS keychain all handle their own sync. You should still back up their local data files, because a sync-propagated corruption — rare, but non-zero — is the kind of thing that takes a vault with it. For 1Password, the file is at ~/Library/Group Containers/. For the macOS keychain, it is in ~/Library/Keychains/.
What to exclude
Back up less, well, rather than more, badly. Exclude DerivedData, node_modules, Python virtual environments, .venv, target/ directories from Rust projects, Docker images, Homebrew caches, and anything in ~/Library/Caches. These directories change constantly, occupy tens of gigabytes, and are trivially reproducible. A modern backup system uses content-defined chunking to deduplicate what does get included, so your effective storage cost is much lower than the naive sum — but chunking is not magic, and ten gigabytes of churning cache files is still wasted bandwidth.
Where to keep it — the destination calculus
The old 3-2-1 rule — three copies, two media types, one off-site — is a useful heuristic that gets sharper when you think about it carefully. We have a companion piece on 3-2-1 reconsidered; the short version is that the rule is right in spirit and slightly wrong in detail. What you actually want is at least two copies, in at least two failure domains, at least one of which is immutable and off-site.
A local backup destination — an external SSD, a NAS on your home network — is fast. Restoring a 40 GB Lightroom catalog from a USB-C SSD takes a minute. Restoring it from the cloud takes thirty, on a good residential connection. Local backup is how you recover from the common failure modes: accidental deletion, a corrupted export, a drive that’s starting to report SMART errors.
A cloud destination is slow but indestructible in ways a local drive cannot be. Your house can burn down. A local drive can be stolen, dropped, or encrypted by the same ransomware that got your Mac. Off-site, immutable cloud storage is how you recover from the rare failure modes that take out everything local at once. Our deep-dive on cloud versus local walks through the trade-offs in detail.
The right answer for most working creators is both. Continuous backup to a local drive for speed, plus continuous backup to a cloud destination for durability. If you are comfortable managing an S3 bucket, you can bring your own storage and pay the storage provider directly. If you are not, macup Cloud is the managed option — the storage is immutable by default, encrypted end-to-end, and costs less than you probably think. Our cost calculator will do the arithmetic for whatever configuration you land on.
A backup you have not restored from is a hypothesis, not a backup.
How often — the schedule question
Backup schedules come in two flavours: scheduled and continuous. Scheduled backups run on a clock — nightly at 2 AM, say, or hourly during working hours. Continuous backups watch the filesystem for changes and capture them as they happen, typically within seconds.
For most working creators, continuous wins. The reason is the concept of Recovery Point Objective, or RPO — the maximum acceptable amount of data loss measured in time. If your backup runs every 24 hours, your RPO is 24 hours: in the worst case, you lose a full day’s work. If it runs every hour, your RPO is an hour. If it is continuous, your RPO is measured in seconds.
An hour of lost Lightroom edits is an afternoon of frustration. An hour of a Logic session on a tight deadline is a crisis. Continuous backup collapses the window.
The objection to continuous backup is performance — will it slow my Mac down? The honest answer for a 2024 MacBook Pro with an Apple Silicon chip is: no, you will not notice it. The backup engine runs at low priority, chunks files into small deduplicated pieces, and uses filesystem event notifications rather than brute-force scanning. The old-fashioned “backup is running, stop using the computer” days are over, and have been for some time.
Encryption, and who holds the keys
Every serious backup system encrypts data at rest. The question worth asking is who holds the key.
In a provider-held-key model, the service encrypts your data with a key the service controls. This is convenient — you can reset your password, recover your account, and the service does the work. It is also a liability. If the service is compromised, your data is compromised. If the service is legally compelled to decrypt, your data is decrypted. If an employee goes rogue, your data is readable.
In a zero-knowledge model — sometimes called end-to-end encrypted — the key is derived from a passphrase you hold, never transmitted to the service, and never stored in a form the service can decrypt. The service sees ciphertext. The cost of that property is that if you lose the passphrase, you lose the data. There is no “forgot password” link that can save you.
macup, like any serious backup system worth considering in 2026, is zero-knowledge by default. Data is encrypted on your Mac with AES-256 before it leaves the machine. The passphrase never reaches our servers. This means we cannot decrypt your data even if compelled to. It also means we rely on you — or the escrow mechanisms we provide — to hold the passphrase safely. We take that seriously. We ship a recovery-code path, an optional iCloud Keychain escrow, and on business tiers an organisational escrow; the goal is that lost hardware never means lost data, while keeping the property that nobody but you can read what you’ve backed up.
Testing your restore
This is the section that most backup guides skip, so we are going to spend time on it.
A backup you have not tested is not a backup. Not because backups usually fail silently — though they sometimes do — but because the restore process itself is where mistakes show up. The backup is written fine. The chunks are all there. But the index was last written three weeks ago, or the passphrase you wrote down is almost-right-but-not-quite, or the destination drive formatted itself when you plugged it in last Tuesday and nobody noticed. You find these problems when you try to restore, not when you try to back up.
The test is simple. Pick a non-trivial file — a Lightroom catalog, a Logic project, the folder containing your most recent finished job. Restore it to a different location on disk, not overwriting the original. Open it in the application that created it. Confirm it opens, confirm it is complete, confirm it is the version you expected. Then delete the restored copy.
Do this the week you set up a new backup, so you catch configuration errors early. Do it again when you change anything about the setup — new destination, new passphrase, new machine. And then do it on a calendar: monthly is generous, quarterly is acceptable, annually is the minimum. Put it in your calendar. Actually do it.
We build restore testing into the product — there is a “restore drill” feature that restores a random sample to a scratch directory, verifies the files, and reports the result, without you having to think about it — but the discipline is the point. The restore is the only part of a backup system whose output you actually care about.
The failure modes we see most
We track what actually goes wrong, and the distribution is boringly consistent.
Drive failure is the most common. Consumer SSDs have finite program-erase cycles; the controllers fail before the flash does more often than the reverse. Mechanical drives fail in more predictable ways — Backblaze’s published Drive Stats, which have been running since 2013, put annualised failure rates for consumer SATA drives between 1% and 3% per year, rising sharply after year five. We wrote up the whole picture in the science of drive death if you want the detail.
Laptop loss and theft is the second. A MacBook Pro in a coffee shop is a target, and a MacBook Pro on the backseat of a rental car is a lost MacBook Pro. FileVault makes the data unreadable to the thief; it does not make it readable to you.
Ransomware on macOS used to be rare. It is no longer rare. The families targeting Mac in 2025 and 2026 are increasingly sophisticated, and they specifically target backup destinations. A backup on a mounted external drive is encryptable by the same process that encrypted your Desktop. This is why immutability — the guarantee that once a backup is written, it cannot be altered or deleted for a defined retention window, even by an attacker with valid credentials — matters. macup Cloud is immutable by default; we consider it non-negotiable.
User deletion and sync-propagated deletion is the mundane one. You delete a folder you thought was redundant, empty the trash, and two weeks later realise it contained the only copy of something. Or you delete a file on your Mac, iCloud Drive dutifully propagates the deletion to your iPad and your iMac, and the only copy of it that still exists is on whatever backup system has not yet run its retention policy. Versioned backup is how you recover.
A concrete setup we’d recommend
Imagine a photographer: a 2024 MacBook Pro, 2 TB internal SSD, a 4 TB external SSD that lives on the desk and holds the photo archive. Their working set is a Lightroom catalog of about 60,000 images, growing at 800 a week. They shoot RAW, edit in Lightroom and occasionally Photoshop, deliver through a private gallery. Here is what we would run.
A continuous backup of the internal SSD, excluding caches, DerivedData, and the ~/Library/Caches tree. A continuous backup of the external SSD, including the entire Lightroom archive and catalog. Both backup sets go to two destinations: a second 8 TB external SSD that stays at home, and a cloud destination with immutability enabled. Retention is set to keep hourly snapshots for 48 hours, daily for 30 days, weekly for 52 weeks, and monthly indefinitely. The encryption passphrase is 24 characters of Diceware, stored in 1Password and written on paper in a fireproof safe. A recovery code is stored separately.
A weekly restore drill, automated: pick a random file, restore it to a scratch directory, verify, report. Monthly, the photographer manually restores their most recent Lightroom catalog to a test location and confirms it opens. Quarterly, they do a full dry-run restore of a week’s worth of shoots.
Total time commitment after setup: about ten minutes a month, plus whatever time the quarterly drill takes — typically an hour. Total monthly cost for the cloud destination, at the working set size, is roughly what a decent lunch costs. For a working photographer whose last five years of archive is on that external SSD, this is the cheapest insurance they will buy this year. If they work primarily with raw video or audio rather than photos, our guide on backup strategy for photographers has a corresponding worked example — the architecture is the same, the numbers shift.
The one thing to take away
Set up backup today. Not next week. Today.
The specific software matters less than the fact of having it. Time Machine to an external drive plus any reputable continuous cloud backup is a perfectly adequate setup, and it is a hundred times better than nothing. If you want the opinionated version — continuous, versioned, zero-knowledge, immutable, multi-destination, with restore testing built in — that is what we build. We offer a 14-day trial, no card required. Install the app, let it run for an afternoon, and then try restoring a file. That last step is the one that will change how you feel about this whole category.
Your data is worth protecting. The machine it lives on is not what protects it. A backup is.