Bitbucket backup: what a git clone does not save

If you are looking into Bitbucket backup, you have probably already heard the reassuring version: git is distributed, every developer has a full clone, so source control backs itself up. That is half true, and the missing half is the expensive one. Atlassian's own documented procedure for recovering a deleted Bitbucket Cloud repository is to rebuild it from a local copy you already hold — and a clone restores your commits and branches, not the review history wrapped around them.

This post covers what Bitbucket Cloud gives you natively, what Atlassian's documented recovery path actually restores, and what an independent copy adds.

Atlassian's documented recovery path is your own clone

Unlike Jira Cloud and Confluence Cloud, which both have an admin-triggered Backup Manager, Bitbucket Cloud has no equivalent full-export button. Its knowledge base article on the subject is titled, plainly, Reinstating deleted Bitbucket repositories from a local copy.

The documented procedure is exactly what it sounds like:

1. Start from a local repository copy that has most or all of the branches from the deleted repo
2. Have admin or write access to the workspace, with an SSH key or API token
3. Create a new repository
4. Point your local clone at it — git remote set-url origin <remoteURL>
5. Push everything back — git push --force --all

Atlassian's guidance then has you validate the result with git log and git branch -a to confirm the branches and commits came back. Note what that makes explicit: the recovery target is branches and commits. Restoring a deleted repository has never been a self-service action in the Bitbucket Cloud UI.

The practical consequence is that your disaster-recovery plan for source control is, by default, whoever happens to have the most complete clone on their laptop. If a repository is deleted on a Friday and the developer with the freshest copy is on leave, the state you can recover is whatever their last git fetch pulled down.

What a git clone does not contain

This is the part that catches teams out, and it isn't an Atlassian limitation so much as a fact about git. A clone contains the object database: commits, trees, blobs, tags and branch refs. It does not contain anything Bitbucket stores about that code in its own database. That includes:

• Pull requests — the diffs, the discussion, the approvals, and who approved what
• Inline review comments and the threads attached to specific lines
• Branch permissions and merge checks — the rules that enforced how code reached production
• Pipeline configuration state, repository and deployment variables, and deploy keys
• Repository settings and access grants — who could do what, and when that changed

For a lot of engineering teams that is annoying but survivable. For anyone operating under a change-control obligation, it is the actual problem: the pull request approval trail is your evidence of change control. ISO 27001 auditors, SOC 2 assessors and NIS2 conversations all ask how you demonstrate that changes to production systems were reviewed and authorised. In a Bitbucket-based workflow, that proof lives in pull request approvals — which no git clone has ever contained.

Rebuild a repository from a developer's laptop and the code comes back intact while the entire audit trail around it does not. The commits are there; the evidence that anyone reviewed them is gone.

Where the risk actually shows up

Deletion by an authorised account. A workspace admin — or an attacker holding admin credentials — can delete repositories from inside the product. No infrastructure access needed, and no self-service undo waiting on the other side.

Force-pushes and history rewrites. A git push --force that overwrites a branch is a legitimate, authenticated operation. If nobody's local clone happens to hold the overwritten commits, that history is genuinely gone. Note that the same --force flag appears in Atlassian's own recovery procedure, which tells you how blunt the available tooling is.

Slow-burn compromise. An attacker who sits inside a workspace for weeks before acting is betting that no clean copy from before their first change still exists anywhere. Against a recovery model built on developer laptops, that is a reasonable bet.

Offboarding. When the developer with the most complete clone of a rarely-touched repository leaves and their machine is wiped, your effective backup for that repository leaves with them — and nobody finds out until the repo is needed.

This is the same shared-responsibility split we set out across Atlassian Cloud's native backup limits and in what a Confluence backup actually keeps. Atlassian keeps Bitbucket running and survives its own hardware failures. Whether your repositories and their history are recoverable to a chosen point in time is your side of the line.

What an independent Bitbucket backup adds

An independent copy for Bitbucket Cloud should cover what a clone structurally cannot:

• Scheduled capture of repositories — every branch and tag, on a schedule, into a store that isn't a developer's laptop
• Pull request metadata — the reviews, comments and approvals that carry your change-control evidence
• Repository configuration — branch permissions, merge checks and pipeline variables, so a restored repo comes back governed the way it was
• Point-in-time restore rather than "whatever the freshest clone happens to hold"
• Anomaly detection so a mass repository deletion is flagged as it happens
• Restore into a workspace you control, without opening a support ticket and waiting

We help you choose and deploy that layer and get it running — you keep ownership of the platform and your workflow, we make sure the setup covers the Atlassian estate you actually have. The Atlassian Cloud backup and recovery page sets out what gets protected workload by workload, and the NIS2 SaaS backup requirements post covers the evidence side in more depth.

Where to start

If your honest answer to "how would we recover a deleted repository, with its review history intact?" is "someone probably has a clone", an assessment is the fastest way to find out how big that gap is — a short, practical look at your current exposure and what an independent copy would close.