GitLab Dedicated Overview: Do You Still Need GitLab Backup?

Last Updated on March 6, 2024

GitLab Dedicated has just made a fresh start, but it has already come to the limelight among active GitLab contributors. So, to be able to keep up we’ve decided to dive deep into this topic and find out what you should expect from this solution. And we’re ready to share our findings with you… 

What is GitLab Dedicated? 

GitLab released GitLab Dedicated in 2022 yet it had had limited availability up to June 2023. So, now it’s possible for a wider audience to try this single-tenant SaaS solution. 

During that pre-release period, GitLab actively analyzed the needs of its users and closely cooperated with its Limited Availability customers to get their feedback and improve its new project. Thus, having all the customers’ needs and requirements evaluated, they build a DevSecOps platform that focuses on data residency, isolation, and private networking to help customers meet their compliance needs. 

So, let’s look at the core features that GitLab differentiates in its recently available to everyone DevSecOps product:

• possibility to choose the cloud region for your data to be stored, though not all the regions are still available, so you will need to check if GitLab supports the region of your choice. 
• Disaster Recovery feature, which permits you to set a secondary AWS region to store your data. The service provider makes backups of your GitLab Dedicated datastore and Git repos regularly.
• SAML authentication functionality that permits your GitLab Dedicated instance to act as a service provider.
• in-flight and at-rest data encryption with the possibility to add your own encryption key. 
• infrastructure-level isolation of your GitLab environment which is placed into a separate AWS account from other tenants. 

Onboarding: how to start with GitLab Dedicated?

If you want to give the new GitLab solution a try and request to create a new GitLab Dedicated environment for your organization, then you will need to provide GitLab with the following information:

• the number of users your organization is going to have,
• the primary region where you want to keep your data,
• the secondary region where you want to store your data,
• the backup region, which can be the same as your primary or secondary region,
• the instance subdomain from the main GitLab Subdomain (gitlab-dedicated.com),
• the initial size of your repositories in GB,
• one or two Availability Zone IDs for PrivateLink (if you’re planning a PrivateLink connection),
• KMS keys for your AWS services (if you’re planning to use this option).

What is the difference with other GitLab solutions?

GitLab Dedicated has absorbed all the best from other options GitLab and GitLab Ultimate have. Unlike other solutions, GitLab Dedicated provides a broader range of security features, including better encryption, full data and source code IP isolation, and full control over your data. 

And it’s not surprising, recently GitLab has conveyed a Global DevSecOps Survey trying to figure out security pain points DevSecOps face in their work. Thus, they discovered that about 44% of operation professionals are burdened with managing hardware or infrastructure tasks, and don’t have enough time to focus on their core duties. 

Steps to migrate to GitLab Dedicated

For those organizations who already use GitLab, there are a few ways to migrate from the GitLab solution they use to GitLab dedicated. They can do it by:

• using the UI, which includes group import and project import.
• through APIs, which include group import API and project import API
• with the help of Congregate Automation Tool, which also supports migrations from Bitbucket and GitHub to GitLab. 

Backup tools: is there still a need?

In spite of all the benefits GitLab Dedicated has, shorter cycle times, lower costs, better security, and enhanced productivity, you shouldn’t forget about a few things. Let’s look at them now…

Are there scheduled backups?

GitLab offers system snapshots on a regular basis, however, you don’t have the possibility to schedule them at the exact time you need, for example, to eliminate bandwidth throttling. 

Another thing is storage, usually with snapshots you get a full copy of your GitLab data which requires more space, and what if you have a big organization with thousands of DevOps who work on different projects? How much space in your storage instance will occupy that snapshot? And with time its weight will just grow!

For example, with GitPtotect.io you can set the Forever Incremental option, which assumes that you have the first full copy and then only incremental ones, which helps your team greatly save your storage space. 

GitLab Dedicated Disaster Recovery Plan: can it eliminate downtime?

Yeap… GitLab has improved security measures in GitLab Dedicated and even offers a Disaster Recovery Plan in case of a failure, but we still shouldn’t lose sight of the fact that GitLab is a service provider and not a backup vendor. Here is what GitLab Dedicated documentation states:

It means that if a severe disaster happens, all you need to do is to wait till GitLab restores your data. So, there is no possibility of point-in-time or granular recovery of repositories and only selected metadata to eliminate downtime and keep your organization’s business continuity. 

RTO and RPO: can I change those metrics?

And when it comes to RTO and RPO, in GitLab Dedicated they are predefined and may work only if you specify your primary and secondary region during the onboarding process. Let’s look at the documentation:

In the case of GitLab Dedicated, you may have a current RTO target for 8 hours and a current RPO target for 4 hours. It means that if you consider those metrics, your organization can easily put up with 8 hours of downtime and data loss of 4 hours. But what if you work in a highly vulnerable and demanding area, like finance, where RTO and RPO should be much lower to meet the compliance requirements? 

For example, GitProtect.io’s custom backup scheme permits you to customize your backups and meet much lower RTO and RPO metrics for more strict compliance needs. 

You can find out more about DR features your backup should have in our blog post: GitLab Restore And Disaster Recovery – How To Eliminate Data Loss.

Eliminate data loss risk and ensure business continuity with the first TRUE Disaster Recovery software for GitLab.

Final thought – the Shared Responsibility Model

GitLab has built a secure and reliable DevSecOps platform with numerous security features for DevOps that can help your organization with compliance. But still, GitLab is a service provider. And as any service provider, it follows the Shared Responsibility Model. It means that the git hosting service is responsible for its infrastructure business continuity, and you, as a customer, are responsible for your data. 

So, as you can see, building a reliable GitLab backup plan is still essential. In our blog post GitLab Backup And Restore Best Practices we shared a step-by-step plan on how to ensure that your GitLab data is constantly accessible and recoverable should any event of disaster occurs.