Gitlab repository backup

Spoiler: In order to back up your gitlab repositories, it may be useful to mirror your repository. The data will be kept on a remote server, along with all modifications.

It’s fine to back up your personal files on a remote server. But when it comes to a git repository, it can get much more tedious.

Indeed, using classic backup mechanisms requires cloning the repository (and therefore taking up space locally), updating it regularly and sending it to the remote server.

Another, simpler method can be to create a mirror of your repository to which all the modifications will be automatically sent.

Mirror. Quadronet_webdesign @ pixabay

The main advantage of this method is that if your server fails, you immediately have a backup repository, without having to replace anything.

Setting up

What we want exactly is that when we perform an action on our repository, it will automatically be reflected in a remote repository, which will serve as a backup.

Since version 8.2 Enterprise Edition of Gitlab, two kinds of mirroring are possible: push and pull.

For anyone with a basic knowledge of git, this should speak to you. The push method sends all the changes to a remote repository, while the pull method asks your repository to fetch all the changes.

The method we will use in our case is push.

Creation of the backup repository

The first step is to create a new repository, on a remote server, which will serve as a backup.

On our end, we used gitlab.com, but there are others, like framagit. You can also create your own server somewhere …

Here I’ll take the example of gitlab.com, but creating a repository is the same for all servers using gitlab.

First, you need to register (or create an account) and once registered, just click on the New Project button, in order to create a new repository.

New project

The data requested for the creation of the project are:

Repository creation

Hit Create project, and you’re done, your project is created.

Configuration

Now let’s move on to configuring the mirroring. To do this, you have to go to the repository you want to save and use the gitlab web interface.

In the project menu, choose Settings> Repository.

menu

In the menus that are offered, you must choose Mirroring Repositories and Expand , in order to be able to access the configuration part.

Dépôts miroirs

You will then have access to a form allowing you to configure mirroring.

The requested data are:

Configuration

Once the configuration is good, just press mirror repository to validate. Your remote repository will then appear in the list just below.

byte overflow

Et après ?

Security

Unlike duplicity, which allowed to encrypt the data sent, the data saved in this way is found in clear on the remote server.

In the case of our projects, we have a repository with us, on which we make our modifications, and a remote repository, with gitlab, because we wanted the code to be freely accessible without exposing our gitlab instance.

For byte overflow to be available on Google Play, it must be signed by our certificate. And since the signing is done automatically by the continuous integration in our gitlab, it would be dangerous to store the keys in the repository …

The solution is therefore to put the data in the secret variables in the CI.

These variables can be found in the menu Settings> CI/CD , in the part Variables .

To summarize, since the data sent is not encrypted, you should never leave any identifiers or certificates in your repositories.

Limitations

Deposits at gitlab.com have a limited size. The maximum repo size is officially 10GB. To be taken into account before wanting to back up your deposit.

This does not always seem to be the case … In many forums, the size limit of gitlab seems to be a hot topic of discussion. Still, officially, it is 10GB.