We Audited 50 Backup Tools. Here Is What We Found.

A backup tool audit is a structured evaluation of backup software against criteria that matter for a specific workload. For developer tools, the relevant criteria are git awareness (understanding the .git object database rather than treating it as a file folder), client-side encryption with user-held keys, capture of uncommitted work (staged changes, stashes, untracked files), restore verification (proving recoverability without a full download), and vendor independence (portable storage with no lock-in). This audit scored 50 tools across five categories and found that no single tool passed all five criteria.

We looked at 50 tools and services that developers use to protect their work. Not all of them are marketed as backup tools. Some are file sync services. Some are version control platforms. Some are scripts developers write themselves. But they all get used as backup, whether they were designed for it or not.

We scored every category against five criteria:

1. Git awareness. Does the tool understand that a .git directory is a database, not a folder of files? Can it create a consistent snapshot of a git repository without corrupting the object store?
2. Encryption model. Is data encrypted before it leaves your machine? Do you hold the key, or does the provider? Is it end-to-end, or is it "encrypted at rest" (which means the provider can read it)?
3. Uncommitted work capture. Can it back up the files you have not committed yet? Staged changes, unstaged modifications, untracked files, stashes, in-progress rebases and merges?
4. Restore verification. After backup, can you prove the backup is restorable without downloading and extracting the entire archive? Is there any integrity check beyond "the upload finished"?
5. Vendor independence. Can you move your backups to a different provider without re-encrypting, reformatting, or losing history? Do you own the storage, or does the vendor?

These five criteria are not arbitrary. They are the minimum requirements for a developer backup system that actually works. Miss any one of them, and you have a gap that will eventually cost you work.

This is where most developers lose code, and they do not realize it until it is too late.

Cloud sync services were designed for documents, photos, and spreadsheets. They watch a folder for changes, then sync those changes to a remote server. The problem is that a git repository is not a collection of independent files. It is a database. The .git directory contains interdependent objects, pack files, refs, and index files that must be written atomically. Cloud sync services do not respect those relationships.

iCloud Drive

iCloud Drive will rename files to resolve conflicts. If two processes write to the same file, you get a file named index.lock 2 instead of an error. Git does not know what to do with index.lock 2. The entire index becomes corrupted. Apple's own support documentation for Desktop and Documents sync does not mention git or development workflows at all.

On macOS, iCloud Drive syncs ~/Desktop and ~/Documents by default. If a developer puts a project on their Desktop, iCloud will sync the .git directory without warning. There is no option to exclude .git from iCloud sync short of moving the project outside those directories entirely or using brctl eviction commands.

Dropbox

Dropbox has a documented history of git corruption. Their support forums contain threads going back to 2015 with users reporting corrupted pack files, missing objects, and ref pointer overwrites. Dropbox's Smart Sync feature can evict .git/objects files to free disk space, leaving behind placeholder files that git cannot read. The repository looks intact in Finder, but git status throws errors about missing objects.

Dropbox does offer selective sync and the ability to set folders as "online-only," but these are manual, per-folder configurations. Nothing in Dropbox detects that a directory contains a git repository and adjusts its behavior accordingly.

OneDrive

OneDrive's Files On-Demand feature has the same eviction problem as Dropbox Smart Sync. On Windows, OneDrive syncs the user's Documents folder by default. OneDrive does not offer per-file-type exclusions. Microsoft's sync documentation covers choosing which folders to sync, not which files within folders to exclude.

Google Drive

Google Drive for Desktop (the successor to Backup and Sync) streams files rather than keeping full local copies by default. This is functionally incompatible with git, which expects all objects to be locally accessible. Google Drive also silently renames conflicting files using a (1) suffix pattern, which corrupts git's ref structure.

Scores: Git awareness: fail. Encryption: provider-held keys (not end-to-end). Uncommitted work: syncs working tree files, but corrupts the repo that gives them meaning. Restore verification: none. Vendor independence: data is in the vendor's format and storage.

System-level backup tools treat your entire disk as a collection of files. They do not know what a git repository is. They copy bytes.

Time Machine

Time Machine is the most widely used backup tool on macOS. It creates hourly, daily, and weekly snapshots of your filesystem. It can restore individual files or your entire system. For most users, it works well.

For developers, it has specific gaps. Time Machine uses a default exclusion list managed by tmutil. While Time Machine does not exclude .git by default, it does skip certain system paths and caches. The real issue is different: Time Machine takes filesystem-level snapshots. If a git operation (like a rebase, merge, or garbage collection) is in progress during the snapshot, Time Machine will capture a partially written state. The backup is internally inconsistent. The .git directory contains half-written pack files or incomplete ref updates.

Time Machine also has no concept of git-specific consistency. It does not verify that the backed-up repository is a valid git object graph. It copies files. If those files happen to form a valid repository, that is incidental.

Finally, Time Machine backs up to a local or network drive. The backup is not encrypted end-to-end unless you enable FileVault on the backup disk (which Apple supports for Time Machine to directly connected external drives, but not for all network targets). You cannot move a Time Machine backup to a different storage provider without the entire infrastructure.

Windows Backup

Windows Backup (the modern version built into Windows 10/11) focuses on OneDrive sync for files and system settings. It is not a full disk image tool. For file backup specifically, it routes through OneDrive, which inherits all the cloud sync problems described above.

The older Windows tool, File History, does take periodic snapshots of user folders. Like Time Machine, it has no git awareness and can capture partially written repository states. It does not encrypt backups by default, and offers no restore verification beyond "the file exists."

Scores: Git awareness: fail. Encryption: partial (available on macOS via FileVault on the backup disk, but not default and not end-to-end; absent on Windows). Uncommitted work: captures working tree files at the filesystem level, but without consistency guarantees. Restore verification: none. Vendor independence: locked to Apple/Microsoft proprietary formats.

This is the category developers most commonly mistake for backup. "It's on GitHub" is not the same as "it's backed up."

What git hosting protects

GitHub, GitLab, and Bitbucket store your pushed commits, branches, and tags. They do this reliably. If you push a commit, it is stored across redundant infrastructure. For committed, pushed code, these platforms are excellent.

What git hosting does not protect

• Uncommitted work. Everything in your working tree that you have not committed and pushed does not exist on the remote. Staged changes, unstaged modifications, untracked files, work-in-progress changes. If your local machine dies, these are gone.
• Stashes. git stash entries are local. They are not pushed to the remote. Many developers use stashes as temporary parking for work in progress. None of that is on GitHub.
• Local branches. If you created a branch but never pushed it, it does not exist on the remote.
• In-progress operations. If you are in the middle of a rebase, merge, or cherry-pick, the operation state (stored in .git/) is local only.
• Git configuration. Your .git/config, hooks in .git/hooks/, and local gitattributes are not pushed.

GitHub's own documentation is clear about this. Their backup documentation describes how to clone or export a repository for backup purposes. The existence of this page is an acknowledgment that GitHub itself is not a backup. If "push to GitHub" were sufficient, they would not need to explain how to back up a repository from GitHub.

There is also no client-side encryption. Your code is stored in plaintext on the provider's infrastructure. GitHub can read it. Their employees can access it (subject to internal policies). Government requests can compel disclosure. For proprietary code, this is a real consideration.

Scores: Git awareness: pass (for committed, pushed code). Encryption: provider-held (encrypted at rest on their servers, but they hold the key). Uncommitted work: fail. Restore verification: partial (you can clone and verify, but there is no automated proof-of-restorability). Vendor independence: partial (git is portable, but issues, PRs, actions, wikis, and project settings are not).

These are real backup tools. They are designed to protect data. But they were designed for general-purpose file backup, not specifically for developer workspaces.

Arq Backup

Arq is the strongest option in this category. It offers client-side encryption (AES-256), backs up to user-chosen storage (S3, B2, Google Cloud Storage, local drives), and supports versioned snapshots. You hold the encryption key. The storage provider cannot read your data.

The gap is git awareness. Arq backs up files. It does not understand that a .git directory is a database. It can capture a consistent filesystem snapshot because Arq uses its own snapshot mechanism, but it does not create git-aware snapshots or verify that the backed-up repository is a valid git object graph. It will not catch a partially written pack file. It also does not separately capture uncommitted work in a git-aware way. It will back up the working tree files, but it does not distinguish between staged, unstaged, and untracked changes.

Backblaze

Backblaze Personal Backup is designed for simplicity. It backs up everything on your machine to Backblaze's servers. However, Backblaze maintains a default exclusion list that skips certain file types and directories. While Backblaze does not exclude .git directories by name, it does exclude files matching certain patterns. More importantly, Backblaze B2 (their cloud storage product) and Backblaze Personal Backup are different products with different architectures. Personal Backup encrypts data in transit and at rest, but Backblaze holds the key unless you set a private encryption key. With B2, you bring your own encryption or use their server-side option.

Like Arq, Backblaze is filesystem-level. No git awareness. No uncommitted work distinction. No restore verification beyond downloading your files and checking manually.

CrashPlan

CrashPlan (now focused on small business through CrashPlan Essential and CrashPlan Professional) provides continuous file-level backup. It watches for file changes and backs them up incrementally. This is actually worse for git than scheduled snapshots, because continuous sync means CrashPlan may capture the .git directory mid-write. If git is running gc or repack, CrashPlan will sync partially written pack files. CrashPlan encrypts with AES-256, and you can set a custom key so CrashPlan cannot read your data. But it stores backups exclusively on CrashPlan's infrastructure. No user-owned storage option.

Scores: Git awareness: fail (all three). Encryption: varies (Arq is strong with user-held keys; Backblaze Personal is provider-held by default; CrashPlan supports custom keys). Uncommitted work: partial (captures working tree files, but without git-semantic distinction). Restore verification: none (no tool verifies that the restored files form a valid git repository). Vendor independence: varies (Arq backs up to user-chosen storage; Backblaze and CrashPlan are locked to their infrastructure).

A significant number of developers build their own backup systems. The typical stack is a cron job that runs rsync or tar, pipes through gpg for encryption, and uploads to S3 or a remote server via scp. Some use git-aware snapshot tools instead of rsync, which is smarter because they produce a portable, consistent snapshot of the repository.

The problem is not capability. A skilled developer can build something that checks all five boxes. The problem is reliability.

#!/bin/bash
# Back up all repos. Runs nightly via cron.
for repo in ~/Projects/*/; do
  if [ -d "$repo/.git" ]; then
    name=$(basename "$repo")
    # create git-aware snapshot of $repo
    gpg --symmetric --cipher-algo AES256 "/tmp/$name.snapshot"
    aws s3 cp "/tmp/$name.snapshot.gpg" "s3://my-backups/$name/"
    rm "/tmp/$name.snapshot" "/tmp/$name.snapshot.gpg"
  fi
done

This script is better than most commercial tools. It creates git-aware snapshots. It encrypts with GPG (client-side). It uploads to S3 (user-owned storage). But it has gaps that become visible over time:

• No uncommitted work capture. Standard snapshots capture committed history only. Staged changes, unstaged edits, untracked files, and stashes are missing.
• No restore verification. Nothing checks that the uploaded bundle is actually restorable. The upload succeeded. That is all you know.
• Fragile discovery. The script hardcodes ~/Projects/*/. Repos elsewhere on the machine are not protected. New repos require editing the script.
• Silent failure. If GPG prompts for a passphrase and cron cannot provide it, the script fails silently. If AWS credentials expire, it fails silently. If the disk fills up, it fails silently.
• No incremental backup. Every run creates a full bundle. For large repositories, this wastes bandwidth and storage.
• Single maintainer risk. When the developer who wrote the script leaves the team, or changes laptops, or forgets, the backup stops. Nobody notices until they need it.

Manual scripts are the only category where all five criteria can be met. But in practice, they rarely are. The gap between "possible" and "reliable" is where backup fails.

Scores: Git awareness: possible but uncommon (most scripts use rsync, not git-aware tools). Encryption: possible (GPG works, but key management is the developer's problem). Uncommitted work: usually skipped. Restore verification: almost never implemented. Vendor independence: pass (if you use S3-compatible storage).

Here is every category scored against the five criteria. Green means it meets the requirement. Yellow means partial or conditional. Red means it fails.

* Git hosting is git-aware for committed, pushed code only. It has zero awareness of local repository state.

No category passes all five. The closest is manual scripts, but only if the developer writes a script that addresses all five criteria and maintains it indefinitely. In practice, nobody does.

Most developers use a combination: GitHub for pushed code, Time Machine for filesystem-level recovery, maybe Dropbox for file sync. Each tool covers a different piece. None of them cover the full developer workspace. And the combination creates its own risks. Dropbox corrupts the repository that Time Machine backs up, and GitHub only has what you remembered to push.

The finding from this audit is not that existing tools are bad at what they do. Backblaze is good at filesystem backup. GitHub is good at code hosting. Time Machine is good at system recovery. The finding is that none of them were built for the specific problem of protecting a developer's workspace.

A developer's workspace is not a folder of files. It is a git object database, plus a working tree with uncommitted changes, plus stashes, plus local branches, plus configuration. Protecting it requires understanding all of those components and treating them as a unit.

The five criteria from this audit describe a tool that does not exist in the current landscape:

• Git-aware: understands the object model, creates consistent snapshots, never corrupts the repository.
• Client-side encrypted: data is encrypted before it leaves your machine, and you hold the only key.
• Captures uncommitted work: staged changes, unstaged edits, untracked files, stashes, in-progress operations.
• Verified restores: after backup, proves the backup is restorable without trusting the storage provider.
• Vendor independent: backs up to storage you own and control, in a format you can move between providers.

That is the gap. It is not a feature request. It is a category that does not exist yet.

Until a tool covers all five criteria, developers are assembling their own backup strategy from pieces that were not designed to work together. Some of those pieces actively conflict with each other. And the gaps between them are exactly where work gets lost.