GitLab SaaS backup: Why cloning your repos isn’t enough

We have been conditioned to treat git clone as an insurance policy when it isn’t. A clone copies your code, and code is only a fraction of what lives in your GitLab.com project. The issues, merge requests, wikis, snippets, CI/CD configuration, and project metadata that your team actually runs on? None of that comes down with a clone. And when it comes to SaaS resilience, that gap matters more than most engineering teams realize: 87% of IT professionals reported SaaS data loss incidents in 2024. Version control is not exempt.

This is a category-education piece, so let’s be direct about the myth and the reality. The myth is that if your repos are cloned locally or mirrored somewhere, your GitLab is “backed up.” The reality is that a GitLab SaaS backup and a git clone are not the same thing, and the difference is exactly the stuff that hurts most when it goes missing.

Is a git clone a backup of my GitLab?

No. A git clone (or even a --mirror clone) copies the Git repository: your commits, branches, and tags. That is genuinely useful, and you should keep doing it. But GitLab is a full DevOps platform, not just a Git host. The project management and collaboration layer sits in GitLab’s database, not in the Git object store, so it never travels with a clone.

Here is what a clone leaves behind:

• Issues and their comments, labels, milestones, and linked history
• Merge requests, including discussion threads, approvals, and review context
• Wikis (these are technically a separate Git repo, but rarely cloned alongside code)
• Snippets stored in the project
• CI/CD configuration state beyond the .gitlab-ci.yml in the repo — variables, pipeline schedules, environments, and secrets
• Project metadata like members and permissions, integrations, boards, releases, and settings

For most teams, the issues and merge request history are the institutional memory. Losing your main branch is recoverable in an afternoon. Losing three years of decision context in merge request threads is not.

Why GitLab.com SaaS backup is different from self-managed

If you have read GitLab’s documentation on backups, you may have seen the gitlab-backup tooling and instance-level backup commands. Those apply to self-managed GitLab, where you control the server. On GitLab.com SaaS, you do not have that access.

As one practitioner put it: “Comprehensive backups available in self-managed installations aren’t possible with SaaS offerings.”

That’s the core GitLab.com backup limitation. Self-managed admins can snapshot the entire instance — repositories, database, and configuration — in one operation. On SaaS, GitLab operates the infrastructure, and you operate within it. You get project and group export features and the API, but not a full-instance dump.

This is the Shared Responsibility Model in action. Your SaaS provider keeps the platform running, redundant, and available. You are responsible for recovering your own data when it’s deleted by accident, wiped by a bad automation, or lost when an admin leaves and their access cascades through your projects. GitLab keeps the lights on; getting your issues and wikis back is your job. (Rewind wrote up how this split works across SaaS platforms in the Shared Responsibility Model explainer. The framing applies directly to GitLab.com.)

How to back up GitLab SaaS honestly

There’s no single button, so a real GitLab SaaS backup strategy layers a few approaches. Here’s the honest landscape.

A few practical notes:

• Project exports are the closest native equivalent to a real backup. They bundle issues, merge requests, wikis, and metadata into a downloadable archive. But they are manual, subject to size limits, and give you an archive to re-import, not surgical, item-level restore of a single deleted issue.
• API-based approaches work well if you have the engineering time to script them, schedule them, and store the output somewhere independent. The catch is that you own the whole pipeline, including the unglamorous restore-testing part.
• Don’t back up GitLab to GitLab. Storing your only export inside the same platform you’re protecting is like backing up your hard drive to your hard drive. Follow the 3-2-1 backup rule: three copies, two locations, one independent of the SaaS provider.

Whatever you choose, test the restore. An untested backup is a hypothesis, not a safety net.

FAQ

Does a git clone back up my GitLab issues and wikis?
No. A clone copies repository code only. Issues, merge requests, snippets, and most metadata live in GitLab’s database and are not included. Wikis are a separate Git repo and are rarely cloned alongside code.

Can I take a full instance backup of GitLab.com?
No. Full-instance backup tooling is available only for self-managed GitLab. On GitLab.com SaaS, you rely on project/group exports, the API, or third-party backup tools.

What’s the best way to back up GitLab SaaS?
Layer it: keep code mirrored, use GitLab’s project/group export for issues and metadata, and store copies independently of GitLab following the 3-2-1 rule. Automate with the API or a third-party tool if you have recurring recovery needs, then test restores regularly.

Does Rewind back up GitLab?
No. Rewind backs up GitHub, Azure DevOps, and the Atlassian suite (Jira, Confluence, Bitbucket, Jira Service Management), among other SaaS tools. Rewind does not currently support GitLab.

Whose responsibility is my GitLab data?
Yours. Under the Shared Responsibility Model, GitLab maintains platform infrastructure and availability; recovering your own user-generated data from accidental deletion, bad automations, or departing admins is your responsibility.

Sorting out resilience across a multi-platform DevOps stack is rarely obvious. Talk to a SaaS resilience expert at Rewind for help thinking through where your data is exposed and what good coverage looks like, GitLab included, even where the answer is native tooling rather than us.

And for a steady drip of SaaS resilience thinking, subscribe to Retro, our monthly newsletter.