What is a backup trust framework?
A backup trust framework is a structured set of questions that evaluates whether a backup solution will actually protect your data under real failure conditions. Instead of checking whether a backup exists, it tests five properties: vendor independence (can you restore without the vendor?), encryption ownership (does the storage provider hold the keys?), completeness (does it capture uncommitted work?), verification (have you tested a restore?), and disaster recovery (what happens when your machine is gone?). Most developers assume their backups work because they have never tested them under the conditions where backups actually matter.
A backup trust framework is a checklist that tells you whether your backup will actually work when you need it. Not whether a backup exists, but whether it will hold up on the worst day: a stolen laptop, a dead hard drive, a corrupted project folder. It asks five simple questions that reveal the gaps most people do not know they have.
A backup trust framework is a verification protocol that evaluates backup solutions against five independently testable properties: vendor independence, encryption boundary, state completeness, restore verification, and disaster recovery. Each property maps to a specific failure class. The framework is tool-agnostic and designed to produce machine-verifiable pass/fail results that can be integrated into CI/CD pipelines and compliance reporting.
Why these questions
Most developers have some form of backup. GitHub hosts their repos. Time Machine runs in the background. Maybe an external drive sits on the desk. The backup exists. The question is whether it works when you need it.
"When you need it" is not a normal Tuesday. It is the day your laptop gets stolen, your SSD fails mid-project, or a cloud sync service silently corrupts your .git directory. The conditions are always worse than you planned for. The backup either survives those conditions or it does not.
These five questions are not about any specific tool. They are a framework for evaluating whether your backup strategy holds up under the scenarios that actually happen to developers. Each question targets a common assumption that feels true until you test it.
Why do these questions matter for your projects?
You probably already have some kind of backup. Maybe you push to GitHub. Maybe your computer backs up automatically. Maybe your files sync to the cloud. The backup exists. But will it actually save you when something goes wrong?
"Something goes wrong" is not a small mistake. It is your laptop getting stolen, your hard drive dying, or a cloud sync service quietly breaking your project files. These five questions help you find the gaps before a bad day finds them for you.
These five questions target the failure modes that surface in production systems under adversarial conditions, not normal operations.
Most backup strategies are validated against normal conditions: scheduled backups, working hardware, accessible services. The five questions test against the conditions where backups actually matter: vendor shutdown, provider breach, incomplete capture, untested restore paths, and total machine loss.
Each question maps to a specific class of failure that existing tools leave unaddressed. The framework is tool-agnostic -- it evaluates properties, not products.
Q1: Can you restore without the vendor?
This is the vendor independence test. If the company that made your backup tool disappears tomorrow, can you still get your data back?
It sounds unlikely. Companies do not just vanish. Except they do. Startups get acqui-hired and shut down their products. Established companies deprecate services. Pricing changes make a tool unaffordable overnight. Terms of service change. Accounts get suspended. Vendors get breached and go offline for weeks.
The question is not whether your vendor will disappear. The question is whether your backup format requires the vendor to exist to restore.
If your backup is stored in a proprietary format that only the vendor's software can read, you do not have a backup. You have a deposit. The difference matters the day you need to make a withdrawal and the bank is closed.
A good backup tool should store data in a format you can read independently. For git repositories, that means standard git formats: bundles, pack files, or bare repos. Something that git itself can consume without any third-party software in the loop.
The storage location matters too. If your backups live on the vendor's servers and you lose access when your subscription lapses, the format is irrelevant. You need to control where the backup lives. Your storage account, your credentials, your data.
How to test it
- Uninstall the backup tool completely.
- Using only standard tools (
git, file managers, command-line utilities), attempt to locate and restore one of your backups. - If you cannot, your backup has a vendor dependency.
Imagine the company that made your backup tool shuts down tomorrow. Can you still get your projects back?
This is called "vendor lock-in." It means your data is trapped inside one company's system. If they raise prices, change their rules, get hacked, or simply close, your projects go with them.
Your backups are stored in a standard format that any tool can read. They live in your own storage account, not the vendor's servers. If the backup company disappears, your data stays exactly where it is.
Vendor independence is a supply chain risk question. In production systems, any single-vendor dependency in the backup path is a single point of failure.
Format dependency: Proprietary backup formats require the vendor's software to restore. Vendor shutdown = data loss.
Storage dependency: Backups on vendor-controlled infrastructure are inaccessible when the account lapses or the service terminates.
API dependency: Restore workflows that require vendor API calls fail when the API is unavailable, rate-limited, or deprecated.
Q2: Can the storage provider read your data?
This is the encryption test. When your backup sits on a remote server, who can read it?
Most storage providers encrypt data "at rest." This means the data is encrypted on their disks. It does not mean the provider cannot read it. Server-side encryption protects against someone stealing the physical drive. It does not protect against the provider themselves, their employees, a subpoena, or a breach of their infrastructure.
The distinction is between encryption the provider controls and encryption you control. If the provider holds the keys, they can read your data. If you hold the keys and encrypt before upload, they cannot.
The only encryption that protects you from the storage provider is encryption that happens before the data leaves your machine, with keys the provider never sees.
This matters more than most developers think. Source code contains secrets: API keys in config files, database credentials in environment templates, proprietary algorithms in application logic. Even if you scrub secrets from commits, your backup might capture uncommitted files that contain them.
A good backup tool should encrypt everything locally, before any data touches the network. The encryption keys should never leave your machine. The storage provider should see nothing but opaque, encrypted blobs. They should not be able to distinguish a backup of your side project from a backup of your production infrastructure.
How to test it
- Log into your storage provider's console or dashboard.
- Navigate to where your backups are stored.
- Try to open or preview any backup file.
- If you can read the contents, your data is not encrypted in a way that protects you.
Can anyone peek at your files? When your project is backed up to the cloud, who else can see it?
Most cloud storage services say they "encrypt your data." But that usually means they hold the keys. They can still open your files. Their employees can see them. A court order can access them. A security breach exposes them.
If the storage company holds the keys, they can read your files. If you hold the keys and lock everything before uploading, nobody else can. A good backup tool locks your project on your computer before it ever leaves.
Encryption boundary analysis. The question is not whether encryption exists, but where the trust boundary falls.
Server-side encryption: Provider holds keys. Protects against physical disk theft. Does not protect against provider access, insider threat, legal compulsion, or infrastructure breach.
Client-side encryption: User holds keys. Data is encrypted before network transit. Provider sees opaque blobs. This is the only model that satisfies zero-trust requirements for source code containing secrets, credentials, and proprietary logic.
Q3: Does it capture what you haven't committed yet?
This is the completeness test. Most backup strategies for developers start and end with committed code. Push to GitHub, and you are backed up. But committed code is only part of the picture.
Think about what lives on your machine right now that is not in any commit:
- Staged changes in your git index, ready to commit but not yet committed.
- Working tree modifications you have been iterating on for hours.
- Untracked files like new modules, config drafts, or test fixtures you have not added to git yet.
- Stashed work from context switches you made three days ago and forgot about.
- In-progress operations like a rebase or merge that you are halfway through resolving.
If your machine dies right now, a GitHub clone recovers your last commit. Everything in that list is gone.
The work you lose in a crash is always the work you have not committed. That is, by definition, the most recent work. The freshest thinking. The hardest to reconstruct from memory.
A good backup tool should capture the full state of your repository, not just the commit history. That means the index, the working tree, untracked files, stashes, and any in-progress git operations. If it only backs up what is already committed, it protects the past but not the present.
This does not mean the tool should commit your work for you. Your commit history is yours to manage. But the backup should capture uncommitted state independently, without creating commits, without modifying your refs, without advancing HEAD. A snapshot of everything, taken without side effects.
How to test it
- Make some changes to a tracked file but do not commit.
- Create a new file but do not
git addit. - Stash something.
- Run your backup.
- Delete the repo and restore from backup.
- Check: are your uncommitted changes there? The new file? The stash?
Does your backup save your work-in-progress? Not just the finished stuff you have saved and committed, but everything you are in the middle of?
Think about what is on your computer right now that you have not officially saved to your project history:
If your computer dies right now, pushing to GitHub only saves the last thing you committed. Everything else is gone. A good backup captures all of it automatically.
State coverage analysis. Most backup tools capture only the commit graph. In production, the uncommitted state is where active work lives.
1. Index (staging area): Changes staged for next commit. Lost on clone.
2. Working tree: Modified tracked files. The active edit surface.
3. Untracked files: New modules, configs, test fixtures not yet added to git.
4. Stash stack: Context-switched work. Often forgotten, always valuable.
5. Operation state: In-progress rebase, merge, or cherry-pick. Half-resolved conflicts.
Q4: Have you ever tested a restore?
This is the verification test. It is the simplest question on this list and the one most developers fail.
A backup that has never been restored is an assumption, not a fact. You assume the backup completed. You assume the data is intact. You assume the restore process works. You assume you remember how to use it. You have verified none of this.
Backups fail silently. A misconfigured exclude rule skips a critical directory. A storage permission change blocks uploads but does not throw an error. An encryption key rotation invalidates older backups. A file size limit truncates large repositories. These failures leave a backup that looks present but is not usable.
The only backup that exists is one you have restored. Everything else is a hope with a timestamp on it.
A good backup tool should make verification automatic, not something you remember to do quarterly. Ideally, the tool should verify that each backup is restorable at the time it is created, not weeks later when you need it. The verification should prove that the data is intact and complete without requiring you to download and restore the entire backup every time.
Some approaches to verification are better than others. A checksum proves the file was not corrupted in transit. A cryptographic authentication tag proves the file was not tampered with. A structural check proves the backup contains valid data that the restore process can actually use. The more the tool verifies automatically, the less you depend on manual testing.
How to test it
- Pick a backup from more than two weeks ago.
- Restore it to a new directory (not your existing repo).
- Verify the repo is functional: run
git log, check out a branch, compile the project. - If you have never done this, you do not know whether your backups work.
Have you ever tried getting your project back from a backup? Not just making the backup -- actually restoring it?
Most people never test this. They trust that the backup is there and that it works. But backups can fail quietly. A setting gets changed. A file gets skipped. Something gets corrupted along the way. You would not know until you actually need it.
A good backup tool checks itself automatically. Every time it saves your work, it also verifies that the save can be used to bring everything back. You should not have to remember to test it yourself.
Restore verification is the difference between a backup claim and a backup fact. In production systems, unverified backups are a compliance liability.
Level 1 -- Checksum: Proves data was not corrupted in transit.
Level 2 -- Auth tag: Proves data was not tampered with (AEAD verification).
Level 3 -- Structural: Proves the backup contains valid, parseable data.
Level 4 -- Restore test: Proves the full pipeline produces a working repository.
Q5: What happens when your machine dies -- not your repo?
This is the disaster recovery test. Most backup strategies protect against repository-level problems: a bad merge, a force push, a corrupted .git directory. But the scenario that ruins your week is not a broken repo. It is a broken machine.
Your laptop gets stolen. Your SSD fails. You spill coffee on your keyboard and the machine will not boot. The repo is not damaged. It is gone. Along with everything else on that machine.
When your machine dies, the restore process starts from zero. New machine, no software installed, no configuration, no local state. The question is: can you go from a bare machine to a working copy of your repository, including all the uncommitted work from your last backup?
This is where most backup strategies reveal their hidden dependencies:
- SSH keys that grant access to private repos, stored only on the dead machine.
- Environment files with API keys and database credentials, never committed to git.
- Tool configurations for your editor, shell, and development environment.
- Local databases and test data that your application depends on.
- The backup tool itself, which needs to be installed and configured before it can restore anything.
A good recovery path should be simple enough to execute under stress. When your machine dies, you are already having a bad day. The restore process should not make it worse. Ideally: install the tool, point it at your storage, get your repos back. No hunting for keys. No reconstructing configuration from memory.
A good backup tool should enable a full recovery from a new machine with minimal prerequisites. That means the backup should be self-contained enough that the tool, your storage credentials, and your encryption key are all you need. The tool should be able to discover what backups exist in your storage without relying on any local state from the old machine.
The recovery process should also handle multiple repositories. Most developers do not have one repo. They have five, ten, fifty. A machine-level disaster affects all of them simultaneously. The tool should be able to inventory and restore all of your backed-up repositories, not just one at a time.
How to test it
- Imagine your current machine is gone. You are sitting in front of a fresh install.
- Write down every step required to recover your most important repository to a working state, including uncommitted work.
- Count the steps. Count the credentials you need. Count the things you would have to remember.
- If the list is longer than five steps, your disaster recovery plan has too many failure points.
What if your computer breaks? Not your project -- your entire computer. Stolen laptop. Dead hard drive. Coffee spill. Everything on that machine is gone.
Now picture sitting down at a brand new computer. Can you get your projects back? All of them? Including the stuff you were working on yesterday that you had not saved yet?
Most people discover they need passwords, login keys, and app settings that only existed on the old machine. A good backup removes those surprises.
Disaster recovery is the integration test for your entire backup strategy. It validates every other property under the worst-case constraint: zero local state.
RTO (Recovery Time Objective): Time from bare machine to working repository. Measures tool installation, authentication, discovery, download, and decryption pipeline latency.
RPO (Recovery Point Objective): Maximum data loss window. Determined by backup frequency and whether uncommitted state is captured. Without five-namespace capture, RPO is bounded by last commit, not last save.
Using the framework
These five questions are a scoring rubric. Run your current backup strategy through each one. Be honest about the answers.
# Backup Trust Evaluation
1. Vendor independence
Can I restore without the vendor? [ yes / no ]
2. Encryption
Can the storage provider read my data? [ yes / no ]
3. Completeness
Does it capture uncommitted work? [ yes / no ]
4. Verification
Have I successfully tested a restore? [ yes / no ]
5. Disaster recovery
Can I recover from a dead machine? [ yes / no ]
# Passing answers: yes, no, yes, yes, yes
# Any wrong answer = a gap in your protectionMost developers will find at least two gaps. That is not a failure of diligence. It is a failure of tooling. The backup tools most developers use were not designed to pass all five tests. They were designed to solve one or two of these problems and ignore the rest.
GitHub solves vendor independence (your code is in git, you can clone it anywhere) but fails the completeness test (uncommitted work is not captured) and the encryption test (GitHub can read your private repos).
Time Machine solves completeness (it captures everything on your disk) but fails the encryption test if the drive is not encrypted, and fails the disaster recovery test if the backup drive was sitting next to the machine that was stolen.
iCloud or Dropbox syncing your project folder fails in a different way: it can actively corrupt your .git directory through file locking conflicts, partial writes, and race conditions. This is not theoretical. Git's own documentation warns against it. The "backup" is the threat.
No single approach passes all five unless it was designed to. That is the point. These questions define what a real backup solution needs to do. Not what is easy. Not what is popular. What works when the day goes wrong.
Run the checklist. Find your gaps. Then decide what to do about them.
Here is a simple scorecard. For each question, check whether your current setup passes or fails.
The five questions define a compliance matrix. Each maps to a verifiable property with measurable pass/fail criteria.
| Property | Verification Method | Compliance Domain |
|---|---|---|
| Vendor independence | Format validation (standard git bundle) | SOC 2 Availability |
| Encryption boundary | Key custody audit | ISO 27001 A.10 |
| State completeness | Namespace coverage report | NIST 800-53 CP-9 |
| Restore verification | Automated restore test | NIST 800-53 CP-4 |
| Disaster recovery | RTO/RPO measurement | SOC 2 Processing Integrity |
Frequently asked questions
How do I know if my backup will work when I need it?
Test an actual restore. Uninstall your backup tool, then try to recover a repository using only standard tools like git. If you cannot locate, decrypt, and restore your data without the vendor's software, your backup has an untested dependency that may fail under real disaster conditions.
What is the difference between server-side encryption and client-side encryption for backups?
Server-side encryption means the storage provider encrypts your data on their disks using keys they control. They can still read your files. Client-side encryption means you encrypt data on your own machine before uploading, using keys the provider never sees. Only client-side encryption protects your backups from the provider, their employees, legal requests, and infrastructure breaches.
Does pushing to GitHub count as a backup?
Pushing to GitHub preserves your committed history, but it does not capture uncommitted changes, working tree modifications, stashed work, or in-progress merge and rebase states. If your laptop dies mid-project, everything not yet committed is lost. A complete backup captures all five namespaces of git state, not just the commit graph.
How do I know my project is actually safe?
Try restoring it. Delete your project folder, then use your backup to bring it back. If everything comes back exactly the way it was, your backup works. If anything is missing, you found a gap before it mattered.
Is saving to iCloud or Dropbox enough?
Cloud sync services like iCloud and Dropbox can actually damage your project files. They were designed for documents and photos, not for the complex file structures that coding projects use. A proper backup tool understands your project structure and protects it correctly.
What if I am not a professional developer?
These five questions apply to anyone who builds things with code. Whether you are learning, building a side project, or creating with AI tools, losing your work is the same frustration. The questions help you check whether your safety net is real.
How does this framework integrate with CI/CD pipelines?
Each of the five questions maps to a verifiable assertion. Vendor independence becomes a format validation check. Encryption becomes a key custody audit. Completeness becomes a namespace coverage report. Verification becomes an automated restore test in a clean container. Disaster recovery becomes a documented runbook with measured RTO. All five can run as pipeline stages.
What compliance frameworks does this align with?
The five properties map directly to SOC 2 control domains (availability, confidentiality, processing integrity), ISO 27001 Annex A controls for backup and cryptography, and NIST 800-53 CP (contingency planning) and SC (system and communications protection) families. The framework provides the verification evidence these audits require.
Can agent workspaces use this framework for automated state protection?
Yes. Agent workspaces generate uncommitted state continuously. The completeness test (question 3) is critical: the backup must capture index, working tree, untracked files, stash, and operation state without creating commits. Automated verification (question 4) ensures each checkpoint is restorable before the agent proceeds. This turns backup from a background concern into an active component of the agent reliability stack.