What is git-aware backup?
Git-aware backup is a backup method that understands the internal structure of a git repository rather than treating it as a folder of files. A standard git repository contains an object database with content-addressed blobs, trees, and commits, plus pack files, refs, the reflog, and index state. File-level backup tools (Backblaze, Time Machine, rsync) copy these components independently, risking inconsistent snapshots, mid-write corruption, and missing objects. Git-aware backup reads from the object database using commands like git bundle, which produces a single verified file that captures the full repository state atomically.
I tested every popular backup tool against a real git repository. Backblaze skips .git entirely. Time Machine backs it up but corrupts it on restore. Rsync catches it mid-write. None of them got it right.
If you are a developer relying on any of these tools to protect your code, you should know what they actually do with your repositories. The answer is not reassuring.
When you save a project with git, it does not just save your files. It saves every version, every branch, every piece of work in progress. All of that lives inside a hidden folder called .git.
Most backup tools do not know this folder exists, or they treat it like any other folder. That is the problem.
A git-aware backup understands the structure of your project, not just the files. It reads from the inside out, creating one verified snapshot instead of copying thousands of small files one at a time.
We tested over 40 backup tools. None of them were git-aware AND captured your unsaved work.
Git-aware backup reads from git's object database rather than performing filesystem-level file copies. Standard backup tools treat .git/ as a directory tree, copying pack files, refs, and index state independently. This creates race conditions: if any git operation is in progress during backup, the snapshot is structurally inconsistent.
In CI/CD pipelines and agent environments, backup operations frequently overlap with git operations (checkout, fetch, rebase). File-level backup tools produce corrupted snapshots under concurrent access. git bundle reads from the object database atomically, eliminating this class of failure.
Across 40+ tools in 9 categories, zero provide git-aware backup with uncommitted state capture. This is a systemic gap in infrastructure tooling.
What each tool gets wrong
| Tool | Backs up .git | Git-aware | Consistent restore | Uncommitted work | Encrypted |
|---|---|---|---|---|---|
| Backblaze | Skips .git | No | N/A | No | Yes |
| Time Machine | As flat files | No | Corrupts | No | Optional |
| Rsync | As flat files | No | Inconsistent | No | No |
| Carbonite | As flat files | No | Corrupts | No | Yes |
| CrashPlan | As flat files | No | Corrupts | No | Yes |
| GitHub push | N/A (remote) | Yes | Yes | No | No |
Backblaze
Backblaze explicitly excludes .git directories from backup. This is documented in their support articles. Your repository history, branches, stash entries, and staged changes are not backed up at all. You get the working tree files only.
# Restored from Backblaze backup
$ cd ~/Projects/my-app
$ ls -la .git
ls: .git: No such file or directory
$ git log
fatal: not a git repository (or any of the parent directories): .git
# Your files are here. Your history is gone.Time Machine
Time Machine backs up .git as flat files. This means it captures whatever state those files are in at snapshot time. If git is mid-commit, mid-rebase, or mid-garbage-collection, Time Machine captures the partial state. Restoring this backup restores a corrupted repository.
# Restored from Time Machine backup
$ cd ~/Projects/my-app
$ git status
error: bad signature 0x00000000
fatal: index file corrupt
$ git fsck
error: refs/heads/main: invalid sha1 pointer 0000000000000000000000000000000000000000
dangling blob 4b825dc642cb6eb9a060e54bf899d15363d7e677
missing commit 7a8f2e1c...Rsync
Rsync copies files one at a time. If the repository changes during the copy (which it does during any git operation), rsync captures an inconsistent state. Same problem as Time Machine, different mechanism.
Cloud backup services
Cloud backup services (Carbonite, CrashPlan, SpiderOak) have the same fundamental issue: they treat .git as a folder of independent files. They do not understand that a git repository is a transactional database.
Here is a quick verdict on each tool. If you use any of these, your project history is at risk.
Backblaze skips the .git folder entirely. Your files are backed up, but your entire project history is gone. Every branch, every save point, every stash. Gone.
Time Machine copies the .git folder, but it does not understand it. If your project is in the middle of a save when Time Machine runs, it captures a broken snapshot. The backup looks fine until you try to restore it.
Rsync copies files one at a time. If anything changes during the copy, you get an inconsistent snapshot. Same problem as Time Machine, different tool.
These all treat your project like a folder of files. They do not understand that a git project is a connected database. Same corruption risk as Time Machine.
Failure taxonomy across backup tool categories. Each failure mode is observable and reproducible.
Class: Silent data omission. Backblaze excludes .git/ from backup scope. Object database, refs, reflog, index, pack files are all dropped. Restore yields a working tree with zero version control state.
Agent implication: Any automated recovery pipeline that expects git log or git status to succeed post-restore will fail silently or crash.
Class: Inconsistent snapshot capture. These tools copy .git/ contents as independent files. Pack files captured mid-write, refs copied out of order, index state frozen mid-transaction. git fsck fails on restore with missing objects and broken refs.
Agent implication: In CI/CD environments running parallel git operations (fetch, checkout, rebase), the probability of mid-operation capture approaches 1. Automated rollback and disaster recovery pipelines cannot rely on these tools.
Systemic implication
No tool in the file-level backup category can produce a consistent git snapshot under concurrent access. This is an architectural limitation, not a configuration gap. The only reliable approach reads from the git object database directly.
Why this matters
Your git repository is not your code. Your git repository is your code, plus every version of your code, plus every branch, plus every stash entry, plus your staged changes, plus your rebase state. File-level backup either skips all of that (Backblaze) or corrupts it (everything else).
Your git repository is not a folder of files. It is a transactional database. Backup tools that treat it as files either skip it or corrupt it.
Most developers do not discover this until they need to restore. And by then, the damage is done.
Most developers discover their backup is broken when they need it most. A failed restore after hardware failure or data corruption is the worst time to learn that your backup tool doesn't understand git. Test your restore now, not after the emergency.
Your project is not just your code. It is every version of your code, every branch, every stash, every piece of work you saved "just in case." Backup tools either skip all of that or break it.
Most people find out their backup is broken when they actually need it. A laptop dies, a drive fails, and the restore gives you corrupted files or missing history. That is the worst time to learn.
The git object model stores content-addressed blobs, trees, commits, tags, pack files, refs, reflog, and index state. File-level backup tools either omit this entirely (Backblaze) or produce structurally inconsistent snapshots (Time Machine, rsync, cloud services).
Disaster recovery procedures that depend on file-level backup of git repositories have unverified assumptions. Post-restore, git fsck failures cascade through any automated tooling that assumes repository integrity. In agent environments, this means silent pipeline failures, broken deployments, and unrecoverable state.
What actually works
A proper backup tool reads from git's internal structures, not the filesystem. This means it captures consistent state regardless of what operations are in progress.
DevSafe creates a consistent, encrypted snapshot with one command.
But committed history alone is not enough. Your staged changes, stashed work, untracked files, and in-progress operations also need protection.
On top of that, the backup should be encrypted before it leaves your machine, uploaded to storage you own, and verified to be restorable.
Putting it all together
A backup tool that actually works would need to capture everything, encrypt before anything leaves, upload to your own storage, and verify the backup is restorable.
That's what DevSafe does. Not a wrapper around rsync. Not a cron job. A purpose-built tool that understands git from the inside.
A good backup tool reads your project from the inside, not by copying files one at a time. It creates one clean snapshot that captures everything.
DevSafe creates one encrypted snapshot of your entire project, including your unsaved work, stashes, and branches. It encrypts everything before it leaves your machine and uploads to storage you own. One command.
It is not a script wrapped around another tool. It is purpose-built to understand how git projects actually work.
Correct backup reads from git's internal structures via git bundle, which produces an atomic, verified snapshot from the object database. This eliminates the inconsistent-snapshot class of failures entirely.
DevSafe captures five namespaces atomically: committed history, index state, working tree changes, stash entries, and in-progress operation state. Each backup is encrypted client-side (AES-256-GCM) before upload to user-owned S3-compatible storage.
For agent environments: backup operations are non-destructive (zero writes to .git/), deterministic, and can run concurrently with other git operations without lock contention.
The 3-2-1-1 standard
The backup industry has a well-established standard: 3-2-1. Three copies. Two media types. One offsite. DevSafe adds a fourth requirement: one immutable. Encrypted bundles in user-owned storage are append-only. No modification, only new writes.
With DevSafe, a developer gets this automatically: the local repo, a local encrypted bundle, and a cloud encrypted bundle. Two media types (local disk and cloud object storage). One offsite (the cloud bucket). One immutable (append-only cloud writes). No configuration beyond storage bucket credentials.
The backup industry has a simple rule: keep 3 copies on 2 different storage types, with 1 copy somewhere else. DevSafe adds one more: 1 copy that cannot be changed or deleted.
Your local project, a local encrypted backup, and a cloud encrypted backup. Two storage types, one offsite, one unchangeable. No setup beyond your cloud storage credentials.
The 3-2-1 backup standard extended with an immutability requirement. Encrypted bundles in user-owned S3-compatible storage use append-only write patterns. No modification, only new writes.
Infrastructure note
In automated environments, the 3-2-1-1 standard is met without manual configuration: local repo + local encrypted bundle + cloud encrypted bundle. Structured key naming ({repo-id}/{type}/{sequence}.enc) enables stateless reconstruction from cloud metadata alone.
Check your backup now
If you are using Backblaze, check whether your .git directories are excluded. They probably are. If you are using Time Machine, try restoring a repository from backup and running git fsck. If you get errors, your backup is corrupted.
The best time to discover your backup does not work is before you need it.
The five-minute test: Restore a repository from your current backup tool. Run git fsck and git log --oneline -20. If either fails, your backup is broken. The best time to find out is right now.
$ devsafe health
Checking backup health for 12 repositories...
~/Projects/api-server
Last backup: 2 hours ago ✓ healthy
Verified: SHA-256 match ✓ intact
Uncommitted: 3 files captured ✓ complete
~/Projects/mobile-app
Last backup: 14 days ago ⚠ stale
Verified: not checked ⚠ unverified
Uncommitted: not captured ✗ missing
~/Desktop/freelance/client-site
Last backup: never ✗ unprotected
9 healthy · 2 stale · 1 unprotected
Run devsafe backup to fix.# Test your backup right now
$ cd /path/to/restored/repo
$ git fsck --full
$ git log --oneline -20
$ git stash list
$ git statusRead the full research: Git Repositories Are Not Files: Why Traditional Backup Fails documents the technical analysis with competitive landscape review of 40+ tools.
Related tool: Try devsafe health
If you use Backblaze, your project history is probably not backed up at all. If you use Time Machine, try restoring a project and see if it still works.
Restore a project from your backup. Open it. Does your history show up? Can you see your branches? If not, your backup is broken. Better to find out now than after an emergency.
The free devsafe health tool checks all your projects at once and tells you which ones are protected, which are stale, and which have no backup at all.
Verification procedure for existing backup infrastructure.
1. Restore a repository from your current backup tool to a clean path.
2. Run git fsck --full and git log --oneline -20.
3. Verify git stash list and git status return expected state.
4. If any command fails, your backup infrastructure has an undetected integrity gap.
Automation note
The devsafe health command automates this verification across all discovered repositories, reporting backup freshness, verification status, and uncommitted state coverage. Integrates into CI/CD health checks.
Full technical analysis: Git Repositories Are Not Files: Why Traditional Backup Fails documents the failure taxonomy across 40+ tools with reproducible test methodology.
Frequently asked questions
Does Backblaze back up the .git folder?
No. Backblaze explicitly excludes .git directories from backup. This is documented in their support articles. Your repository history, branches, stash entries, and staged changes are not backed up. You get only the working tree files, which means you lose all version control data on restore.
Does Time Machine corrupt git repositories?
Time Machine backs up .git directories as flat files without understanding git's internal structure. It can capture pack files mid-write, copy refs out of order, and create inconsistent snapshots of the object database. The backup appears to succeed, but the restored repository may fail git fsck or show missing objects and broken refs.
What is the safest way to back up a git repository?
The safest approach is a git-aware backup that reads from the object database using git bundle rather than copying filesystem files. A git bundle creates a single, self-contained, verified snapshot of the entire repository. Combined with client-side encryption before upload, uncommitted work capture, and restore verification, this approach avoids the corruption problems that file-level backup tools introduce.
Does Backblaze protect my project?
Not your project history. Backblaze backs up your files, but it skips the hidden folder that stores all your versions, branches, and save points. If you restore from Backblaze, you get your latest files but lose everything else.
Can Time Machine break my project?
Yes. Time Machine copies the project folder without understanding it. If your project was saving when Time Machine ran, the backup is a broken snapshot. It looks fine until you try to restore it.
What is the safest way to back up my project?
Use a tool that understands how git projects work from the inside. It should create one verified snapshot, encrypt it before upload, save your unsaved work too, and let you verify the backup actually restores correctly.
Does Backblaze back up git repository state?
No. Backblaze excludes .git/ from backup scope. The object database, refs, reflog, index, and pack files are all omitted. Post-restore, the directory contains working tree files only. Any tooling that calls git plumbing commands will fail. This is documented in Backblaze support articles and is not configurable.
Does Time Machine produce consistent git snapshots?
No. Time Machine performs file-level backup of .git/ without transactional guarantees. Pack files captured mid-write, refs copied out of order, and index state frozen mid-transaction produce structurally inconsistent snapshots. git fsck reports missing objects and broken refs on restore. The failure probability increases with repository activity frequency.
What backup approach provides verified, atomic git snapshots?
Read from the git object database via git bundle, which produces a single verified file capturing the complete repository state atomically. Extend with five-namespace uncommitted state capture (index, working tree, untracked, stash, operation state), client-side encryption (AES-256-GCM), upload to user-owned S3-compatible storage, and automated restore verification.