Azure DevOps holds the parts of software delivery nobody can recreate from memory: the commit history, the sprint plans built up over months, the pipeline definitions that turn a merge into a production deployment. None of it is backed up by Microsoft in a way you can actually rely on. Azure DevOps backup is the gap almost every DevOps team assumes someone else has covered, and almost nobody has.
This guide covers what actually lives in Azure DevOps, what Microsoft's own documentation says about recovering it once it's gone, the deletion and compromise scenarios that catch teams out, and how third-party Azure DevOps backup closes the gap.
What Lives in Azure DevOps (and What Disappears With It)
Azure DevOps isn't just a code repository. A typical organisation has years of work spread across four connected areas:
- Repos — Git history, branches, tags, and pull request records. For teams still on TFVC, changesets and shelvesets too.
- Boards — work items, sprints, backlogs, queries, delivery plans, and dashboards. This is the institutional memory of what was built, why, and in what order.
- Pipelines — YAML and classic pipeline definitions, release definitions, environments, variable groups, and deployment history.
- Wikis — project documentation, often the only up-to-date record of how a system actually works.
Lose any one of these and the cost isn't really the data: it's the weeks of context that go with it. A sprint board rebuilt from memory is missing the reasoning; a pipeline recreated from scratch is missing the tuning that made it reliable.
What Microsoft Actually Says About Recovering Deleted Data
This is the part most teams get wrong, usually by assuming Azure DevOps works like OneDrive or SharePoint, with a recycle bin and a generous retention window. It doesn't, not for most of what matters.
Microsoft's own Data protection overview for Azure DevOps states plainly that accidental deletion of customer assets (repositories, work items, attachments, artifacts) isn't something Microsoft Support will restore. Microsoft does run internal disaster-recovery backups for its own service continuity, but those exist to keep Azure DevOps itself running after an outage; they were never built for, and aren't available for, rolling back something a user or a script deleted.
The one genuine safety net is at the organisation and project level. Delete an organisation and Microsoft holds it, disabled, for 28 days before permanent deletion, recoverable yourself from your profile's "Organizations Pending Deletion" page. Deleted projects get the same 28-day self-service window. That's genuinely useful if someone deletes the wrong project by mistake and notices within a month.
Everything below that level is a harder line. Work items follow a similar pattern in miniature: soft-deleted items sit in a Recycle Bin for a retention period and can be restored from there, but once an item is permanently destroyed (via the API's destroy=true, or once retention lapses) it's gone, and Microsoft Support won't bring it back. Individual repositories, pipeline definitions, and wiki pages have no recycle bin at all: delete one, and unless you've got your own backup, it doesn't come back.
Deletion and Compromise Scenarios That Actually Happen
None of this is hypothetical. The failure modes that show up in practice are mundane rather than dramatic:
- A departing team member cleans up "their" repos on the way out, not maliciously, just tidying, taking history nobody else had a copy of.
- A migration or bulk-import script goes wrong, deleting or overwriting hundreds of work items in the time it takes to notice the flag was inverted.
- A pipeline YAML refactor breaks the definition, and the previous working version was never saved anywhere outside Azure DevOps itself.
- A compromised or over-scoped personal access token gets used to wipe boards or repos. Azure DevOps PATs are a known target precisely because they're often scoped more broadly than they need to be.
- An organisation gets deleted outside the 28-day recovery window and nobody notices until it's already gone for good.
Every one of these is the kind of thing that happens on an ordinary Tuesday, not the result of a sophisticated attack.
How Third-Party Azure DevOps Backup Actually Works
Because Microsoft treats accidental deletion as the customer's problem, closing the gap means running backup independently of Azure DevOps, ideally on infrastructure that a compromised Azure DevOps org or a leaked Azure credential can't also reach.
Keepit for Azure DevOps is built on that principle: backups run on Keepit's own cloud, entirely separate from Microsoft's infrastructure, twice daily, to blockchain-verified immutable storage that ransomware or a bad actor with valid Azure DevOps credentials can't touch. Coverage spans Azure Repos (Git pack files, refs, branches and tags, for repositories up to 256 GB), Azure Boards (work items, queries, sprints, areas, backlogs, boards, dashboards and iterations), Azure Pipelines (pipeline definitions, environments, releases, library resources, deployment groups and agent pools), and wikis. Recovery is point-in-time, so you're not stuck choosing between "everything" and "nothing." Cross-user restore means work isn't stranded when the account that created it has since been deactivated.
Worth being upfront about the gaps too, since no backup product covers everything: Keepit doesn't currently capture work item comment reactions, the links between work items, pipeline secure files and variables (a platform API limitation, not a Keepit one), pipeline permissions, or wiki attachments themselves (attachment links are preserved, the files aren't). For most teams those are edge cases rather than blockers, but they're worth knowing about before you assume "backup" means "everything, forever." If cross-platform restore to GitHub, GitLab or Bitbucket matters more to you than infrastructure independence, our Keepit vs GitProtect comparison for Azure DevOps walks through the trade-off in detail.
Setting It Up
The practical side is straightforward. Connecting Azure DevOps backup involves authorising access to the organisations and projects you want covered, scoped only to what's needed, in the same least-privilege spirit that should already apply to your PATs; confirming the backup schedule matches how fast your teams actually work (twice-daily is standard, adequate for boards and pipelines that change throughout the day); and running a real test restore before you need one for real. A backup nobody has ever restored from is a hope, not a plan.
For teams already running Keepit to protect Microsoft 365 or another SaaS workload, adding Azure DevOps is one more connector inside the same console rather than a second platform to learn and manage. That matters for SaaS backup generally: the workloads worth protecting rarely sit still at just email and files, and DevOps tooling is exactly the kind of "we'll get to it eventually" gap that tends to surface at the worst possible time.
For MSPs, the same logic applies at the portfolio level. Clients running their own Azure DevOps organisations are usually the client's most technical stakeholders, which means a missed backup gap there is the one most likely to get noticed, and remembered, when something goes wrong. Bundling Azure DevOps backup alongside existing Microsoft 365 protection is a small addition to an existing service, not a new sales conversation from scratch.
Azure DevOps is where the actual engineering work lives. Treating its backup as someone else's problem, Microsoft's or "future us", is how a routine Tuesday deletion turns into a project nobody can fully rebuild.