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.
The main advantage of this method is that if your server fails, you immediately have a backup repository, without having to replace anything.
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
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.
The data requested for the creation of the project are:
- Project name : the name of your repository
- Project URL : the URL of your repository. By default, generated automatically using the name of the project.
- Description : if you want to describe your project.
- Visibility level
- Private : only allows access to authorized users,
- Internal : allows access to connected users,
- Public : the project is visible to all,
- Initialize repository with a README
Hit Create project, and you’re done, your project is created.
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.
In the menus that are offered, you must choose Mirroring Repositories and Expand , in order to be able to access the configuration part.
You will then have access to a form allowing you to configure mirroring.
The requested data are:
- URL: the URL of the remote repo to which all changes will be sent.
- Mirror Direction: push. So that all modifications in our repository are pushed to the mirror repository
- Authentication method: You can use a password or an ssh key.
Once the configuration is good, just press mirror repository to validate. Your remote repository will then appear in the list just below.
Et après ?
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
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.
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
gitlabseems to be a hot topic of discussion. Still, officially, it is 10GB.