Hi Team,
I'd like to understand our Bitbucket Cloud backup policy. Based on my online research, my understanding is that Atlassian backs up Bitbucket Cloud data and retains it for 7 days—though please correct me if I've got the retention policy wrong. I have a few questions:
Thanks in advance for your help.
Hi @Dinesh_Prajapati, your 7 days is right, specifically as the support restore window. Atlassian's backup KB: "we perform hourly snapshot backups of your repositories and store these in AWS. Our support team is able to restore your core repository content within a 7-day window of data loss."
On the outage question, no. Those snapshots are Atlassian's own disaster recovery, and the trust page is blunt about it: "We don't use these backups to revert customer-initiated destructive changes... To avoid data loss, we recommend making regular backups." For an outage, what that page actually promises is narrower than it sounds: "Bitbucket data is located in two different availability zones within the US-East region." That's zone redundancy inside a single region, and the quarterly testing it mentions covers the backups. Your real cover there is git itself, which the same KB points at: "every person in your workspace who has forked your repository has a complete copy with a full history."
Deletion is the narrow exception, and it's where your metadata question gets its answer: "The Support team can help recover core repository content only, as long as the deletion happened within the last 7 days. We are unable to recover metadata or any content that was deleted past 7 days." Commits are in the git data, so they're covered. Pull requests, PR comments and pipeline history are the metadata. Those are gone. BCLOUD-19832 is the open request to change it, Gathering Interest with 31 votes since 2020.
For process, raise a ticket at support.atlassian.com/contact inside the 7 days. The prerequisites KB gates that though, so check it first: only a paid-workspace member can raise a ticket, and the reporter has to be a repo or workspace admin before support will touch the data. The repo then comes back renamed with the deletion date appended, which you change in Repository Settings.
So the metadata is yours to cover. git clone --mirror handles the code, which is what that backup KB recommends. For the rest, schedule GET /2.0/repositories/{workspace}/{repo_slug}/pullrequests and the matching /pipelines, and repeat the state parameter (state=OPEN&state=MERGED&state=DECLINED&state=SUPERSEDED) because that endpoint returns open PRs only by default. I tested it on a public repo: one PR came back bare, 30 with the states repeated. That backup KB also still tells you to authenticate with an app password, and those stopped working on 28 July. An API token needs scopes or it won't authenticate (read:repository:bitbucket), and the username differs by surface, x-bitbucket-api-token-auth for git and your Atlassian account email for the REST calls above.
Hello @Dinesh_Prajapati ,
Just a few words to add a bit more information to @Gabriela - LeanZero answer. Atlassian follows the Atlassian Cloud Security Shared Responsibility model; it means that Atlassian provides enterprise-grade infrastructure to keep the platform running smoothly, while account data management remains the customer's responsibility.
Atlassian team can recover your Bitbucket data within 7 days after the deletion.
If your team requires long-term retention, point-in-time restores, and complete control over repository metadata, it's better to look at dedicated backup apps from the Atlassian Marketplace.
Third-party solutions like GitProtect for Bitbucket complement Atlassian's infrastructure by offering automated backups for code and metadata, granular point-in-time recovery, and customizable retention policies, etc.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.