A few years ago, the founder of a backup company asked his R&D team a simple question. How is our own source code protected? The answer came back fast and confident: “It’s on the cloud in BitBucket, so we’re fine”.
A quick search told a different story. The team read the shared responsibility model for the first time, understood that their code was their problem and not their provider’s, and built a product to fix it. That product became GitProtect, and that question is the one Xhuljo Mezini brought to the Work Evolution Summit for you to answer about your own instance.
Xhuljo covers partner development at GitProtect, part of Xopero Software, a backup and disaster recovery company from Poland with more than 16 years in the market, customers in over 60 countries, and a base past 100,000 organizations.
His session made one argument: the work your teams plan, document, and ship inside Jira and Bitbucket is business-critical data, and treating a cloud platform as its own safety net leaves you exposed.
The Data You Assume Is Safe
Every major platform provider publishes a shared responsibility model, and almost nobody reads it. The split is consistent. The provider protects the platform itself, its availability, infrastructure, and uptime. Your data, the actual content you put into the platform, stays your responsibility. Atlassian states its own version plainly. It will access your data only when there is a specific need, which is rare, and it can notify you of a breach and keep system-level backups. Your role is to configure access to fit your needs and to create backups of your data. Providers even recommend that you run third-party backup software for protection and compliance. The recommendation sits in the terms you clicked past.
Xhuljo did not have to argue this point for long, because the room proved it for him. During questions, an attendee named Adrian admitted he had completely forgotten Jira needed backing up at all, then asked the audience to raise a hand if they backed up their Jira. Out of the whole room, one company did, maybe two. Ask the same question of your own team and see what answer you get.
Your DevOps Platforms Now Run the Business
The reason this matters more than it used to is that the data moved. Xhuljo pointed out that Jira and Bitbucket stopped being tools only software companies use. He now sees them across manufacturing, public sector, automotive, energy, healthcare, finance, telco, and retail. Organizations shifted their daily work into cloud DevOps platforms, and those platforms hold far more than tickets and repositories. They hold the plans, the documentation, and the release management for the whole operation.
When the data moved, the risk moved with it. A few years ago, companies worried about servers, laptops, and the scattered places data used to live. Now a large share of business-critical information sits inside Jira, Bitbucket, and similar tools, which is exactly why those platforms need protecting like any other asset you depend on.
Why an Export Won’t Save You
A manual export feels like a reasonable safety step, and Xhuljo explained why it falls short. The data inside these platforms is layered. A Jira project is not just issues. It carries comments, attachments, workflows, projects, and boards. Restore an issue but lose its attachment and you are not actually back to normal, you are back to a different set of problems. Bitbucket and other git platforms work the same way. A repository holds pull requests, webhooks, pipelines, LFS, and branches on top of the source code itself.
Because GitProtect captures that full metadata rather than a flat copy, it can do things a simple export never could. On top of standard disaster recovery and granular restore, it offers cross-restore. If GitHub goes down, you restore the specific repositories you need to a different platform such as Bitbucket and keep working there. The same flexibility runs through deployment and storage. You can run the tool on-premise or in the cloud depending on your compliance rules, and you choose where the backups live, whether that is your own infrastructure, the vendor’s cloud, your cloud, or a hybrid split. That hybrid option satisfies the 3-2-1 rule Xhuljo called the golden rule of backup, three copies across two locations with at least one kept outside your infrastructure.
Compliance Turned Backup Into a Requirement
Backup is no longer only a good habit. Xhuljo walked through how compliance regulations now treat DevOps data as information assets that must be protected under law, which forced a mindset shift. Protecting laptops and servers used to feel like enough. Now the expectation extends to code repositories, Jira issues, pipelines, attachments, and documentation.
The certifications your clients ask about make this concrete. To earn ISO 27001, you have to prove your DevOps data is protected and that your backups actually work, which means backing up regularly, testing recovery, and controlling access. SOC 2 Type 2 pushes on the same points, access control, backup and disaster recovery planning, and testing. Strip away the differences and every regulation asks for a similar short list. Back up critical data, test that recovery works, control who can reach your data, and keep backup data protected and separate from production. When a client asks whether you comply with something like NIS2, protecting your critical data is part of the answer whether you planned for it or not.
What Actually Goes Wrong
Xhuljo was clear that dramatic attacks are only part of the picture. Ransomware and hijacked accounts happen. So do failed integrations, botched migrations, and provider outages. He also named the newest entry on the list, AI agents that make changes to source code they were never authorized to touch, which teams are already reporting. But the cause he flagged as most likely is the least cinematic one.
Most damage comes from normal daily work going wrong. Someone deletes a project by mistake. A bulk update rewrites thousands of issues in one action. Attachments break during a migration. A workflow change quietly damages field mapping. Every one of those is recoverable if you kept a backup, and permanent if you did not.
Migration deserves its own caution, since the risk there runs high. Xhuljo’s guidance is to make a copy of your data before you migrate, then take another copy the moment you finish, so if anything breaks along the way you can revert to the original state rather than reconstruct it from memory.
How Long Can You Work Without Jira?
Xhuljo put a question to the room that cuts straight to the cost: “How long can your company work without Jira?”
Walk the timeline yourself. Lose Jira for one hour and you probably cope, falling back to Slack, Teams, spreadsheets, and notes. Lose it for a day and the pain sharpens, teams lose visibility, customers wait longer, SLAs slip, and managers stop knowing what is happening. Lose it for several days and it becomes a genuine business problem, with releases delayed and incident management grinding down. The shorter your recovery time, the less your business and your team suffer, which is the whole point of planning for it in advance.
He tied specific failures to specific recoveries so the plan stays practical. An accidental repository deletion calls for a granular restore of just that piece. A compromised account calls for a full restore, the disaster recovery path. A provider outage is where cross-restore earns its keep, moving you to a different platform so work continues.
Building a Strategy You Can Trust
The mindset Xhuljo wants you to adopt is proven resilience, and the distinction is sharp (“we tested it and we know that we can restore”). That replaces the hope that you are probably fine with evidence that you can recover and a real number for how long it takes.
Prevention still matters, but he treats backup as the last line of defense that has to be ready when prevention fails. To get there, he laid out the practices worth building your strategy around.
Cover all your data, since anything still in the platform plays a role. Keep long-term retention, because audits, legal cases, and internal policies sometimes need data from months or years ago. Lean on granular restore to keep recovery time low, since most mistakes are small. Stay flexible on storage and keep as many copies in as many places as you sensibly can. And manage everything from one central platform, so protecting Jira, Bitbucket, Confluence, GitLab, and Azure DevOps is a single process rather than a different scramble for each tool.
The uncomfortable pattern Xhuljo kept returning to is that most teams only ask these questions after something has already gone wrong. You have the chance to ask them first. So ask yourself, this question today: If you raised your hand right now, could you say your Jira is backed up, and could you prove the restore works?
—
About Life in Codes
Life in Codes is on a mission: to support organizations of all kinds to work in a more productive way. That means smart tools, healthy practices, and training the people. As an Atlassian Solutions Partner active in Romania, Estonia, Belgium, UK and the UAE, with our team spread across Europe.
Our client roster includes start-ups, SMEs, large financial institutions like SWIFT, government organizations like the European Commission, and logistics providers such as DHL.Our expertise spans a wide range of solutions, including ITSM, Agile Project Management, Digitalization, Knowledge Management, next-level customer support, DevOps, cloud migration and Rovo AI agents.
We firmly believe that working smart is universal – regardless of industry, company size, or team composition. – our diverse client base is a testament to this philosophy. Whether you’re a tech-focused team or not, Atlassian tools, coupled with our expertise, can significantly enhance your productivity and collaboration.
At the end of the day, we believe in the power of teamwork and we aspire to help people reach their full potential. By partnering with Life in Codes, you’re not just adopting new tools – you’re embracing a more efficient, collaborative, and successful way of working. Schedule an appointment
