The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Last updated: 2020-12-23
Please reach out to Fabian Zimmer, Product Manager for the Geo group (Email) if you'd like to provide feedback or ask any questions related to this product category.
This strategy is a work in progress, and everyone can contribute. Please comment and contribute in the linked issues and epics on this page. Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision.
⚠️ The Geo group is focusing on improving GitLab's Disaster Recovery capabilities. We do support backup and restore on a best-effort basis. This means, we fix bugs in line with our SLOs but we have no capacity to contribute major feature improvements, such as incremental backups. We will re-evaluate the priority of this work in Q1 FY22.
GitLab supports backup and restore
procedures that rely
on standard unix tools, such as rsync and tar. By default, backups cover
most data but not GitLab’s configuration. For GitLab instances that contain
several hundred gigabytes or even terabytes, the current solution does not scale
well. This means that backing up or restoring such a GitLab instance can take many hours, which is a major issue.
GitLab is a crucial tool for many customers and if GitLab does not handle backups, customers will be forced to implement their own strategies. This is not efficient and leads to a very heterogeneous landscape that is difficult to maintain and support. GitLab should offer backup and restore capabilities for any scale and offer clear guidance for all reference architectures. This is important because because it enables customers to fit GitLab into their business continuity plans.
Backup and restore tools are primarily used by Sidney - (Systems Administrator).
Backups should be complete, easy to create, automate, and restore. They also need to complete as fast as possible, for example, to support point in time recovery.
In Q1 FY22 we will re-evaluate the priority of the backup and restore category and are going to assess all currently open issues to define the priorities further.
GitLab is used by customers with thousands of users and terabytes of data. Backups should be fast at any scale. This means that GitLab should not only support base backups but also incremental backups. Copying terabytes of data every time when a backup is performed is not efficient at this scale and can take many hours. Backups should also because be agnostic with regards to the backend - local storage, cloud storage etc. should all be configurable.
Currently, GitLab uses rsync to create backups and we should investigate
alternatives e.g restic to see if those help address some
of these concerns.
Backups should be incremental and work better at scale. We should be able to utilise a Geo secondary for backup related tasks.
Sometimes, a user may remove a single project by accident. In those cases, it may be desirable to restore only individual items from the backup. This should ideally be possible via the UI and can be performed by a systems administrator.
Sometimes a GitLab primary instance is under pressure from heavy usage and backing up may add additional load that is not desirable. As Geo becomes more complete, it will contain most if not all data from a primary. This means, backups should be able to run on a secondary, thereby reducing the pressure on the secondary. This is especially desirable for the PostgreSQL database.
Backup plans should be part of all reference architectures and should be enabled by default. When using such a reference architecture, a GitLab Backup should be able to recreate the entire architecture, configuration and restore all data.
Systems administrators should be able to use a complete UI and CLI that gives them access to all backup related functions.
Currently, all backup tasks are performed via rake tasks in the command line.
This is not necessarily a problem but it can result in low
visibility and requires
systems administrators to switch between different user interfaces. There is no
place in the GitLab user interface that allows systems administrators to access
backups.
GitLab should offer a dedicated Backup and Restore section that allows some of these functionalities:
We are in the process of defining the product direction and are not in a position to answer this yet.
This category is currently at the minimal maturity level, and our next maturity target is complete (see our definitions of maturity levels).
We are still investigating what is required to move the category from minimal to complete. You can track the work in the viable maturity epic.
All major competitors offer backup solutions for their products.
We do need to interact more closely with analysts to understand the landscape better.
Not yet available.
