What is an encrypted backup tool?
An encrypted backup tool is software that creates copies of your data and protects those copies with cryptographic encryption so that no one without the decryption key can read them. For developers, an encrypted backup tool specifically designed for source code should understand git's internal structure, encrypt data on the local machine before any network transfer, store backups in the developer's own cloud storage account, and capture not just committed history but also uncommitted working changes. The distinction between client-side encryption (where only you hold the key) and server-side encryption (where the vendor holds the key) determines whether the tool protects your data from everyone, or just from external attackers while leaving the vendor with full access.
An encrypted backup tool makes a safe copy of your project and scrambles it so that only you can read it. Think of it like putting your work in a locked safe before storing it somewhere. Even if someone breaks into the storage room, they cannot open the safe without your key.
For people who build things with code, a good backup tool should automatically find your projects, protect them before sending them anywhere, and store them in an account you control. It should also save work you have not finished yet (the stuff between saves).
An encrypted backup tool creates cryptographically protected snapshots of source repositories, ensuring data confidentiality at rest and in transit. For AI engineering teams, the critical properties are: client-side encryption (keys never leave the local machine), git-semantic awareness (reading from the object database, not the filesystem), user-owned storage (no vendor custody of data), and uncommitted state capture (index, working tree, untracked files, stash, in-progress operations).
Why this guide exists
Every backup tool says it protects your data. Most of them are telling the truth in a narrow, legal sense: yes, the data is encrypted at some point, by someone, using something. That sentence contains three variables, and each one matters.
Ask specific questions before you hand over access to your repositories. The wrong choice does not just leave you unprotected. It creates a false sense of safety that is worse than having no backup at all.
This guide covers the eight things that separate a backup tool that actually works from one that just checks a compliance box. These are the questions we asked ourselves when building DevSafe, and the questions you should ask any tool you are considering.
Every backup tool claims to keep your work safe. Most of them are technically telling the truth. Your data is encrypted at some point, by someone, using some method. But those details matter.
Know what questions to ask before picking a backup tool. Choosing the wrong tool does not just leave you unprotected. It gives you a false sense of security, which is worse than knowing you have no backup at all.
This guide walks through eight things that separate a backup tool that truly protects your work from one that just looks good on paper. These are the same questions we asked ourselves while building DevSafe.
Every backup vendor markets encryption as a feature. Most are technically accurate in a narrow sense: data is encrypted at some layer, by some entity, using some primitive. That statement contains three unbound variables, and each one defines a distinct threat model.
For AI engineering teams managing model weights, training data, agent configurations, and CI/CD secrets, the wrong backup architecture creates a false positive on your security posture. You believe your data is protected. It is not.
This guide specifies eight architectural properties that separate a backup system with real security guarantees from one that satisfies a compliance checkbox. These are the criteria we applied when building DevSafe, and they map directly to the threat landscape of modern AI development infrastructure.
Client-side encryption
The first question to ask any backup tool is: who holds the encryption keys?
There are two models. In server-side encryption, the vendor encrypts your data after receiving it. The vendor holds the key. The vendor can read your data. The vendor's employees can read your data. A breach of the vendor's infrastructure exposes your data in plaintext. A subpoena served to the vendor can compel them to decrypt your data and hand it over.
In client-side encryption, the encryption happens on your machine before the data leaves. The key never leaves your machine. The vendor never sees it. A breach of the vendor's infrastructure exposes only ciphertext, which is useless without the key. A subpoena served to the vendor gets them encrypted blobs they cannot decrypt.
Watch for the phrase "encrypted at rest." This usually means the vendor encrypts your data on their servers, using their keys. It protects against someone stealing the vendor's hard drives. It does not protect against the vendor reading your data, getting breached, or being compelled by a court order.
The question is not "is my data encrypted?" The question is "can anyone other than me decrypt it?" If the answer is yes, the encryption exists to protect the vendor, not you.
A good backup tool should make it impossible for anyone without your key to read your backups. Not difficult. Not against company policy. Impossible.
The first question to ask any backup tool is: who holds the key to unlock your data?
There are two ways backup tools handle encryption. In the first way, you send your project files to the backup company, and then they scramble the data on their end. The problem? They have the key. Their employees can look at your files. If someone hacks the company, your files are exposed. If a court sends a legal order (called a subpoena) forcing the company to hand over your data, they can unlock it and hand it right over.
In the second way (called client-side encryption) your files are scrambled on your own computer before they ever leave. The key stays on your machine. The backup company never sees it. Even if they get hacked, the attackers only get scrambled data that is useless without your key.
A good backup tool makes it impossible (not just difficult, not just against company policy) for anyone without your key to read your backups.
The first evaluation criterion for any backup system: where does key custody reside?
Server-side encryption means the vendor performs encryption after ingesting your plaintext. The vendor holds the key material. This model protects against storage-layer breaches but leaves the data fully accessible to vendor employees, insider threats, and legal compulsion. For AI teams, this means your model weights, training data manifests, and agent configurations are readable by a third party.
Client-side encryption means encryption occurs on the local machine before any network transfer. The key never crosses the trust boundary. A vendor infrastructure breach yields only ciphertext. A subpoena yields ciphertext the vendor cannot decrypt.
What "encrypted" actually means
Not all encryption is the same. "We use encryption" is not a specification. Here is what you need to know.
The cipher
AES-256-GCM is the current standard for authenticated encryption. The "256" is the key length in bits. The "GCM" (Galois/Counter Mode) is the mode of operation, and it matters because GCM provides both confidentiality and authentication. That means it not only hides your data, it also detects if anyone has tampered with the ciphertext. If a single bit has been flipped, decryption fails.
Some tools use older modes like AES-CBC, which provides confidentiality but not authentication. That means someone could modify your encrypted backup and you would not know until you tried to use the corrupted data. For backup integrity, authenticated encryption is not optional.
Nonce handling
AES-256-GCM requires a unique nonce (number used once) for every encryption operation. If two different pieces of data are encrypted with the same key and the same nonce, the encryption breaks. This is not a theoretical risk. It is a well-known attack.
A good tool uses random 96-bit nonces generated from a cryptographically secure source for every single operation. Ask the vendor: how do you ensure nonce uniqueness? If they cannot answer this question, they have not thought about it enough.
Key derivation
A master password or key should never be used directly for encryption. Good tools derive per-operation keys from the master key using a standard key derivation function. This limits the damage if any single derived key is compromised and ensures that different types of data are encrypted with different keys, even from the same master secret.
The red flag: If a vendor cannot name their cipher, mode, and key derivation function on their documentation site, treat that as a warning. Cryptographic transparency is a signal of engineering maturity, not a security risk.
Not all encryption is created equal. When a tool says "we use encryption," that is like a restaurant saying "we use heat." The details matter.
The scrambling method: The current gold standard is called AES-256-GCM. The important part is the "GCM": it means the encryption does two jobs at once. It hides your data, and it also detects if anyone has tampered with the scrambled version. If even one tiny piece gets changed, the whole thing refuses to unlock. This is called "authenticated encryption" and it is essential for backups.
Some tools use older methods that hide your data but cannot detect tampering. That means someone could modify your backup and you would not know until you tried to use it. By then it would be too late.
Unique numbers: Every time the tool encrypts something, it needs to use a fresh random number (called a nonce). If it ever reuses the same number with the same key, the protection breaks. This is not a theoretical concern. It is a known, well-documented weakness.
Key management: A good tool never uses your main password directly to encrypt files. Instead, it creates separate keys for each backup from your main password using a mathematical process. This way, even if one backup key is somehow exposed, the rest stay safe.
The phrase "we use encryption" is not a specification. Here is the evaluation framework for cryptographic implementation quality.
Cipher and mode: AES-256-GCM is the baseline for authenticated encryption. GCM (Galois/Counter Mode) provides both confidentiality and ciphertext authentication in a single pass. A tampered ciphertext fails authentication before any plaintext is produced. Tools using AES-CBC lack authentication. An attacker can modify encrypted backups without detection until restore time, which may be months later.
Nonce management: GCM requires nonce uniqueness per key. Nonce reuse under the same key is a catastrophic failure: it leaks the XOR of two plaintexts and breaks authentication. For backup systems processing thousands of operations, random 96-bit nonces from a CSPRNG are the standard approach. Counter-based nonces introduce statefulness and crash-recovery complexity that most backup tools handle poorly.
Key derivation: Direct use of a master key is an anti-pattern. The correct architecture derives per-operation keys via HKDF or similar KDF, creating a key hierarchy: master -> per-repository -> per-bundle. This limits blast radius on key compromise and provides domain separation across different data types.
User-owned storage
Where do your encrypted backups go after they leave your machine? There are two models, and they have different risk profiles.
Vendor-controlled storage
The vendor stores your backups on their infrastructure. Your data lives on their servers, governed by their terms of service. If the vendor raises prices, you pay or lose access. If the vendor gets acquired, your data transfers to the acquiring company. If the vendor shuts down, you have a window to export before everything is gone.
Even with client-side encryption, vendor-controlled storage creates a dependency. You own the key, but someone else owns the lock and the building it is in.
User-owned storage
Your backups go to storage you own and control. Your Cloudflare R2 bucket. Your AWS S3 bucket. Your MinIO instance. Your Backblaze B2 account. The backup tool writes to your storage and reads from it. The vendor never touches the data.
This model means your backups survive the vendor. If the backup tool company disappears tomorrow, your encrypted data is still sitting in your bucket, under your account, paying your storage bill. You are not dependent on anyone else's continued existence.
The cost trap: Some vendors offer "free storage" as a feature. This sounds generous until you realize it means they control where your data lives. Free storage is vendor-controlled storage with a marketing budget. The cheapest storage is always the storage you own.
Ask the vendor: if you cancel the subscription, where are the backups? If the answer is "on our servers, and you have 30 days to export," you do not own your backups. You are renting access to them.
After your project is encrypted, where does the backup actually go? This matters more than most people realize.
Option 1: The company stores it for you. Your data lives on their servers. If they raise prices, you pay more or lose access. If they get bought by another company, your data goes with the deal. If they shut down, you have a limited window to download everything before it disappears.
Even if the encryption is solid, storing your data on someone else's servers creates a dependency. You have the key, but someone else controls the building where the safe is kept.
Option 2: You store it yourself. Your backups go to a storage account you own: Cloudflare R2, AWS S3, or Backblaze B2. The backup tool writes to your account and reads from it. The backup company never holds your data.
This means your backups survive even if the backup company disappears. Your files are still in your account, under your control.
Ask the vendor: if you cancel, where are the backups? If the answer involves a deadline to export, you do not own your backups. You are renting access to them.
Where encrypted backups are stored determines the operational dependency graph and the blast radius of vendor failure.
Vendor-controlled storage: Data resides on vendor infrastructure under vendor ToS. Price increases, acquisitions, and shutdowns all create exfiltration risk or data loss windows. For AI teams, this means model checkpoints, fine-tuning datasets, and pipeline configurations are subject to a third party's business continuity.
User-owned storage: Backups write to S3-compatible storage under your AWS/R2/MinIO/B2 account. The backup tool is a client, not a custodian. Vendor disappearance has zero impact on data availability.
Open backup format
Even with client-side encryption and user-owned storage, there is one more lock-in vector: the backup format itself.
If the vendor uses a proprietary format, you need their software to restore your backups. If the vendor disappears, stops supporting your OS, or changes their pricing, you are stuck with encrypted files in a format only their tool can read. That is lock-in through file format.
An open backup format means the structure of the backup is documented and uses standard components. For git repositories, the ideal backup format is a standard, open format that any git installation can verify and restore. A single file that contains a complete or incremental snapshot of a repository. No vendor tool required.
The encryption layer should wrap a standard backup format, not replace it. When you decrypt a backup, the result should be a standard file that standard tools can read. Not a proprietary archive. Not a custom database. A file format you can open with tools that already exist on every developer's machine.
Ask the vendor: if I decrypt a backup file, what format is the result in? Can I restore it using standard tools, without your software installed?
Even if your backups are encrypted with your own key and stored in your own account, there is one more way you can get locked in: the file format.
If the backup tool saves your data in its own custom format, you need that tool to open it. If the company disappears, stops updating, or changes their pricing, you are stuck with files that nothing else can read. That is lock-in hiding inside the file itself.
An open backup format means the backup file uses a standard structure that other tools already understand. When you unlock (decrypt) a backup, you get a file that standard, freely available tools can open. No special software required.
Ask the vendor: if I decrypt a backup, what do I get? Can I open it with tools I already have, without installing anything from you?
Client-side encryption and user-owned storage eliminate two dependency vectors. The third is the backup format itself.
A proprietary format creates a restore-time dependency on the vendor's software. If the vendor ceases operation, the encrypted files in your bucket become opaque. You can decrypt them (you hold the key), but you cannot interpret the result without the vendor's deserializer. This is format lock-in, and it defeats the purpose of user-owned storage.
The correct architecture: encryption wraps a standard, documented format. For git repositories, decryption should yield a standard git-native artifact that any git installation can verify and restore. No vendor tooling in the restore path.
Git-aware vs. filesystem copy
This is where most general-purpose backup tools fail for developers, and why you need a tool designed specifically for git repositories.
The filesystem copy problem
A filesystem backup tool copies files. It walks your directory tree and copies everything it finds. For most data, this is fine. For a git repository, it is dangerous.
A .git directory is not a collection of files. It is a transactional database. Git maintains internal consistency through lockfiles, pack indexes, and checksums. If a backup tool copies the .git directory while git is in the middle of a write operation, the backup contains a corrupted database. A garbage collection pass, a rebase, a merge: any of these can leave the object store in a temporary state that a filesystem copy will faithfully capture and permanently preserve.
This is the same class of problem that makes cloud sync services (iCloud Drive, Dropbox, OneDrive) dangerous for git repositories. They copy individual files. Git expects atomic operations across multiple files. The mismatch causes corruption.
What git-aware means
A git-aware backup tool reads from git's internal structures to create a consistent snapshot. Not a file-by-file copy of the .git directory. The snapshot is always internally consistent because git itself produces it.
A git-aware tool also understands what a repository is. It can auto-discover repositories on your machine. It can handle bare repos, worktrees, and submodules. It knows to skip a repository that is mid-garbage-collection or has a locked pack file.
The test: Ask the vendor what happens if their tool runs a backup while git gc is running in the repository. If they do not have an answer, their tool is a filesystem copier with a git logo.
This is where most general-purpose backup tools break down for anyone working with code projects, and it is something most people never think about.
The problem with simple file copying: A regular backup tool copies files one by one. For documents and photos, that works fine. But a code project managed by git is not just a folder of files. It is more like a small database. Git keeps track of every change through a system of internal files that all need to stay in sync with each other.
If a backup tool copies those internal files while git is in the middle of updating them, the backup captures a half-finished state. That backup looks fine sitting in storage, but when you try to restore it, the project is corrupted. This is the exact same problem that causes iCloud, Dropbox, and OneDrive to break code projects. They copy individual files without understanding that git needs them to change together.
What "git-aware" means: A git-aware backup tool does not copy files one by one. Instead, it asks git itself to produce a clean, complete snapshot. The result is always internally consistent because git created it as a single unit.
A git-aware tool also understands what a code project looks like. It can automatically find projects on your machine, and it knows when to wait if a project is in the middle of an operation that should not be interrupted.
This is the failure mode that separates backup tools designed for source repositories from filesystem-level backup utilities rebranded for developers.
Filesystem copy failure mode: A filesystem backup walks the directory tree and copies files individually. A .git directory is a transactional object store. Packfiles, indexes, refs, and lockfiles maintain internal consistency through atomic multi-file operations. A filesystem copy during git gc, rebase, or merge captures a partially-written object store. The backup appears valid at the storage layer but contains a structurally corrupted repository. This is the same corruption vector that makes cloud sync services (iCloud Drive, Dropbox, OneDrive) incompatible with git repositories.
Git-aware architecture: A git-aware tool reads from git's object database via plumbing commands, producing a consistent snapshot as an atomic artifact. The snapshot is structurally valid by construction. The tool also handles bare repos, worktrees, submodules, and detects in-progress operations (locked packfiles, active GC) to avoid capturing transient state.
Uncommitted work capture
Your git history is the work you have already committed. But what about the work you have not committed yet?
Right now, on your machine, there is probably uncommitted work. Staged changes in the index. Modified files in your working tree. Untracked files you have not added yet. Stashed work you saved for later. Maybe an in-progress rebase or merge.
A backup tool that only captures committed history misses all of this. If your machine dies between commits, your backup restores you to your last commit, not to where you actually were. That gap can be minutes or hours of work, depending on your commit habits.
A complete backup tool should capture five categories of uncommitted state:
- The index (staging area): files you have staged but not committed
- Working tree changes: files you have modified but not staged
- Untracked files: new files you have not added to git yet
- Stash entries: work you explicitly saved for later
- In-progress operations: rebase state, merge state, cherry-pick state
This capture should happen without creating a commit in your repository. The backup tool should read your uncommitted state without modifying it. No temporary commits. No advancing HEAD. No entries in your reflog that you did not put there.
Ask the vendor: does your tool back up uncommitted work? All five categories? Without creating commits in my repo?
Your project history only includes work you have saved (committed). But what about everything you are working on right now that has not been saved yet?
Think about your current project. You probably have files you changed but have not saved to the project history. Maybe new files you just created. Maybe work you set aside for later. If your computer dies right now, a backup tool that only saves your project history would restore you to your last save point, not to where you actually were. That gap could be minutes or hours of lost work.
A complete backup tool should capture five types of in-progress work:
- Staged changes: files you marked as ready to save but have not saved yet
- Modified files: files you changed but have not marked as ready
- New files: files you just created that the project does not track yet
- Set-aside work: work you explicitly saved for later (called a "stash")
- In-progress operations: if you were in the middle of reorganizing your project history
Committed history is one layer of repository state. The operational state (the work between commits) represents a second, equally critical layer that most backup tools ignore.
At any given time, a development environment contains uncommitted state across five namespaces:
- Index (staging area): staged but uncommitted changes
- Working tree deltas: modified but unstaged files
- Untracked files: new files not yet added to version control
- Stash stack: explicitly shelved work-in-progress
- Operation state: in-progress rebase, merge, or cherry-pick state machines
For AI engineering workflows, the gap between commits is often substantial: long-running training experiments, iterative prompt engineering, agent configuration tuning. A backup that restores to the last commit loses this operational context.
Verified restore
A backup you cannot restore is not a backup. It is a liability.
The industry has a name for this: "Schrodinger's backup." The backup simultaneously exists and does not exist until you try to restore it. Most teams never try until they need to, and by then it is too late to discover the backup was corrupted, incomplete, or encrypted with a key that no longer works.
A good backup tool should verify that backups are restorable without trusting the storage provider. This means the tool can prove, cryptographically, that a backup is intact and complete, without downloading the entire file and without relying on the storage provider's word that the file is healthy.
What verified restore looks like in practice:
- Integrity verification: The tool can confirm that the encrypted backup has not been tampered with or corrupted in storage. The authentication tag on an AES-256-GCM ciphertext serves this purpose. If the tag does not verify, the data has been modified.
- Completeness verification: The tool can confirm that all expected backup segments are present, without downloading them. Cloud storage metadata (object keys and sizes) should be sufficient to verify completeness.
- Restore testing: The tool can perform a full decrypt-and-verify cycle to prove the backup is restorable, on demand, without overwriting your current work.
The principle: Every claim the tool makes about your backup should be provable. "Your backup is safe" is a claim. "Here is the cryptographic proof that your backup is intact, complete, and restorable" is a verification. Demand the second.
A backup you cannot actually restore is not a backup. It is a false sense of security.
There is a concept called "Schrodinger's backup": the backup both exists and does not exist until you actually try to restore it. Most people never test their backups until the day they desperately need them. By that point, it is too late to discover the backup was damaged, incomplete, or locked with a key that no longer works.
A good backup tool should be able to prove your backups are healthy without you having to download everything and check manually. Here is what that looks like:
- Tamper detection: The tool can confirm nobody has modified your backup since it was created. If even one piece has been changed, the tool catches it.
- Completeness check: The tool can confirm all the pieces of your backup are present, just by looking at the file listing in your storage. No need to download gigabytes of data.
- Test restore: The tool can do a practice run, fully unlocking and checking a backup, without overwriting your current work.
A backup that cannot be verified as restorable is a liability, not an asset. The industry term is "Schrodinger's backup": the superposition collapses only at restore time, which is exactly when you can least afford a failure.
Verification must be independent of the storage provider. Three properties are required:
- Integrity: AEAD authentication tags (AES-256-GCM) provide per-ciphertext tamper detection. A modified backup fails tag verification before any plaintext is produced.
- Completeness: Backup inventory derivable from cloud storage metadata alone (object keys and sizes via ListObjectsV2). No sidecar manifests, no vendor API calls. Sequence gaps are detectable from key naming conventions.
- Restorability: On-demand decrypt-and-verify cycle that produces a structurally valid artifact without overwriting the current working state. This is proof-of-restorability, not a restore operation.
What if the vendor disappears
This is the question that separates real backup architecture from a SaaS feature checkbox. Every vendor will tell you they are reliable. The architecture should not require you to believe them.
If the backup vendor goes out of business tomorrow, you should be able to answer yes to all four of these questions:
- Can I still access my encrypted backups? If they are on user-owned storage, yes. If they are on the vendor's servers, you are racing against the shutdown clock.
- Can I still decrypt them? If the key is on your machine and was never shared with the vendor, yes. If the vendor held a copy of your key, you are dependent on their key escrow surviving the shutdown.
- Can I restore them without the vendor's software? If the decrypted output is a standard format that any git installation can read, yes. If it is a proprietary archive format, you need the vendor's restore tool, which you cannot get because the vendor no longer exists.
- Can I verify their integrity independently? If the verification relies on a vendor API endpoint, it stopped working when the servers went dark. If verification is built into the file format using standard cryptographic primitives, it works forever.
The answer to all four should be yes with zero dependencies on the vendor's continued operation. That is the test. Client-side encryption, user-owned storage, open backup format, and local verification. Any tool that ticks all four boxes survives its own vendor's disappearance.
Any tool that does not is a service you are renting, not a backup you own.
This is the question that tells you whether a backup tool truly protects you or just works while the company is around. Every company says they are reliable. Your backups should not depend on that being true forever.
Imagine the backup company shuts down tomorrow. You should be able to answer "yes" to all four of these:
- Can I still get to my backups? If they are in your own storage account, yes. If they are on the company's servers, you are racing against a shutdown deadline.
- Can I still unlock them? If the key is on your computer and was never shared with the company, yes. If the company had a copy of your key, you are depending on their systems surviving the shutdown.
- Can I open them without the company's app? If the unlocked backup is in a standard format, yes. If it is in a custom format only their app can read, you are stuck. You cannot download the app because the company no longer exists.
- Can I check that they are still intact? If the checking depends on the company's website being online, it stopped working when they shut down. If the checking is built into the file itself, it works forever.
This is the vendor continuity test: the architectural property that separates a backup system from a SaaS feature. The architecture must not require trust in the vendor's continued operation.
Four conditions must hold when the vendor ceases to exist:
- Data access: User-owned storage (S3-compatible bucket under your account) means vendor shutdown has zero impact on data availability. Vendor-controlled storage means a race against the shutdown timeline.
- Decryption capability: Client-side key custody means decryption is independent of vendor infrastructure. Vendor-held keys create a dependency on key escrow survival.
- Restore path: Standard output format (git-native artifacts) means any git installation can restore. Proprietary format means the restore tool died with the vendor.
- Verification independence: AEAD-based integrity verification built into the ciphertext format works forever. Vendor API-dependent verification stops when the servers go dark.
The checklist
Here is everything from this guide in one table. Print it. Bring it to your next tool evaluation. Ask every vendor every question.
| Question | Good answer | Red flag |
|---|---|---|
| Who holds the encryption key? | Only you. Key never leaves your machine. | "We manage keys for your convenience." |
| What cipher and mode? | AES-256-GCM (authenticated encryption). | "We use industry-standard encryption." |
| How are nonces handled? | Random 96-bit nonces, unique per operation. | Cannot answer or says "counter-based." |
| Where are backups stored? | Your own S3-compatible bucket. | "Our secure infrastructure." |
| What format are decrypted backups? | Standard git format, restorable by any git installation. | Proprietary archive or vendor-specific format. |
| How does it read a git repo? | Git-aware internal reads, not filesystem copy. | Filesystem copy of the .git directory. |
| Does it capture uncommitted work? | Index, working tree, untracked, stash, operations. | "We back up your committed history." |
| Can you verify without downloading? | Cryptographic proof from metadata alone. | "Download and check manually." |
| What if you disappear? | User keeps data, keys, and restore ability. | "We offer 99.9% uptime." |
DevSafe was built to answer every one of these questions correctly. Client-side AES-256-GCM encryption with keys that never leave your machine. User-owned storage on your own S3-compatible bucket. Open backup format using a standard, restorable format. Uncommitted work capture without touching your repository. Verified restore with cryptographic proof.
But do not take our word for it. Take the checklist. Ask us the same questions you ask everyone else. That is what it is for.
Here is a simple checklist you can use when comparing backup tools. For each question, the left column is what you want to hear and the right column is a warning sign.
1. Who holds the encryption key?
Good: Only you. The key never leaves your computer.
Warning: "We manage keys for your convenience."
2. What encryption method do they use?
Good: They can name the specific method (like AES-256-GCM).
Warning: "We use industry-standard encryption" with no specifics.
3. Where are backups stored?
Good: In your own storage account that you control.
Warning: "On our secure infrastructure."
4. What format are backups in?
Good: A standard format you can open with free tools.
Warning: A custom format that only their app can read.
5. Does it understand code projects?
Good: It reads from the project's internal structure, not just copying files.
Warning: It copies files one by one from the folder.
6. Does it save unsaved work?
Good: It captures all types of in-progress work.
Warning: "We back up your saved history."
7. Can you verify backups are healthy?
Good: Built-in proof that backups are intact.
Warning: "Download everything and check yourself."
8. What if the company disappears?
Good: You keep your data, keys, and ability to restore.
Warning: "We offer 99.9% uptime."
Consolidated evaluation matrix. Apply this to any backup tool under consideration for your infrastructure.
| Criterion | Pass | Fail |
|---|---|---|
| Key custody | Client-side only. Key material never crosses trust boundary. | Vendor-managed keys or key escrow. |
| Cryptographic stack | Named cipher + mode + KDF (e.g., AES-256-GCM + HKDF-SHA256). | Unspecified "industry-standard encryption." |
| Nonce strategy | Random 96-bit nonces from CSPRNG, unique per operation. | Counter-based or unspecified. |
| Storage custody | User-owned S3-compatible bucket. | Vendor-controlled infrastructure. |
| Output format | Standard git-native artifact, restorable without vendor tooling. | Proprietary archive format. |
| Repository interaction | Git plumbing reads (object database), zero-commit capture. | Filesystem copy of .git directory. |
| Uncommitted state | Five-namespace capture (index, working tree, untracked, stash, operations). | Committed history only. |
| Verification | AEAD-based integrity + metadata-only completeness check. | Vendor API-dependent or manual download. |
| Vendor independence | Zero dependencies on vendor continued operation. | Any restore/verify path requires vendor infrastructure. |
Frequently asked questions
What is the difference between client-side and server-side encryption in backup tools?
Client-side encryption encrypts your data on your machine before it leaves, using a key only you hold. The backup provider never sees your plaintext data. Server-side encryption means the provider encrypts your data after receiving it, using their own keys. With server-side encryption, the provider can read your data, their employees can access it, and a breach exposes your files in plaintext. For source code backups, client-side encryption is the only model that truly protects your intellectual property.
Why does a backup tool need to be git-aware?
A git-aware backup tool reads from git's internal object database rather than copying files from the filesystem. This matters because cloud sync services like iCloud and Dropbox corrupt .git directories through file locking races and partial writes. A git-aware tool creates proper git bundles that are immune to these corruption patterns, captures the full commit graph including branches and tags, and can verify structural integrity before encrypting. A filesystem copy cannot distinguish between a valid repository and a corrupted one.
What should I check before trusting a backup tool with my source code?
Ask eight questions: Does it use client-side encryption with keys you control? Does it use authenticated encryption like AES-256-GCM? Does it store backups in your own cloud storage account? Does it use an open, documented backup format? Is it git-aware rather than a filesystem copy? Does it capture uncommitted work? Does it verify restorability with cryptographic proof? And can you still access your backups if the vendor disappears? If the answer to any of these is no, the tool has a gap that could cost you data.
What does "client-side encryption" mean in plain terms?
It means your files are scrambled on your computer before they go anywhere else. The backup company never sees the unscrambled version. Compare this to "server-side encryption," where the company receives your actual files and then scrambles them on their end. They (and anyone who hacks them) can read everything. For your code projects, client-side encryption is the only way to truly keep your work private.
Why can regular backup tools break code projects?
Regular backup tools copy files one at a time. A code project managed by git is like a small database. Many internal files must stay in sync. If a backup copies some of those files while they are being updated, the backup captures a broken state. This is the same reason iCloud and Dropbox can corrupt code projects. A "git-aware" tool avoids this by asking git itself to create a clean snapshot as a single unit, so the backup is always consistent.
What questions should I ask before choosing a backup tool?
Ask eight things: Does it encrypt on my computer, not theirs? Can it name the specific encryption method? Does it store backups in my own account? Does it use a standard file format? Does it understand code projects (not just copy files)? Does it save my unsaved work? Can it prove backups are healthy? And if the company disappears, can I still get my data? If any answer is "no," that is a gap worth knowing about before you commit.
How does key custody affect the threat model for AI development infrastructure?
Client-side key custody eliminates the vendor from the trust boundary entirely. The vendor never holds plaintext or key material, so vendor-side breaches, insider threats, and legal compulsion yield only ciphertext. For AI teams handling model weights, training data, and agent configurations, this is the difference between a breach exposing your IP and a breach exposing encrypted blobs. Server-side encryption leaves the vendor as a privileged accessor: an exfiltration vector that persists for the lifetime of the backup relationship.
Why is filesystem-level backup insufficient for repositories with concurrent operations?
Git's object store maintains transactional consistency across multiple files: packfiles, indexes, refs, and lockfiles. A filesystem-level copy during concurrent operations (gc, rebase, merge, parallel CI clones) captures a partially-written state. The backup appears valid at the storage layer but contains a structurally corrupted repository. Git-aware backup reads from the object database via plumbing commands, producing an artifact that is consistent by construction. For agent workspaces and CI runners with high concurrency, this is a correctness requirement, not an optimization.
What is the minimum evaluation criteria for backup tooling in an AI engineering stack?
Nine criteria: client-side key custody, named cryptographic stack (cipher + mode + KDF), CSPRNG nonce generation, user-owned S3-compatible storage, standard output format, git-aware repository reads, five-namespace uncommitted state capture, AEAD-based verification independent of vendor infrastructure, and zero vendor dependencies in the restore path. Any gap in this matrix represents a single point of failure in your disaster recovery architecture. Apply these criteria to every tool under consideration, including DevSafe.