Git Server Selection

One of the most popular self-hosted Git servers is GitLab [5], which of course also runs on the service at gitlab.com . However, the massive GitLab, written in Ruby, requires quite a bit of performance on the part of the server hardware. In return, GitLab delivers a wide range of functions, such as a wiki, a bug tracker, and an integrated container image repository. If you only use a Git server as a backup target, you don't need all of these features and are better off with a simple, but agile, Git server like Gitea [6], which handles many databases and runs in containers with low resource requirements (Figure 3). For administrators with a predominantly Windows background, the free Bonobo [7] Git Server in .NET integrates directly with Internet Information Services (IIS).

Figure 3: The simple Gitea Git server functions as a central backup server in the LAN or WAN.

To create a second, remote backup of a local repository, you need a Git server. Here, too, you have a whole range of open source offerings. Gitea is the simplest solution for newcomers. Written in Go, it derives from Google's in-house Git server Gogs but is maintained by a somewhat more liberal developer community than the Google original. Like Git itself, Gitea is available for all major platforms, so the server service also runs smoothly on Windows. All you need is an existing Git installation and a database. Gitea supports MySQL and PostgreSQL as well as Microsoft SQL Server (MSSQL) or, for simple test setups, SQLite. Of course, Gitea can also be run in a Podman or Docker container.

Once started, Gitea listens on ports 3000 (HTTP) and 22 (SSH) by default. In the simple and clear-cut web UI, you first need to create the user accounts. To avoid the need to log in with a username and password, you will want to use SSH keys to authenticate. The key pairs usually are generated with a centralized key management system and then assigned to the users. In smaller environments, however, users on the client PCs can create key pairs themselves with ssh-keygen. Remember always to keep a copy of the SSH keys outside the client PC.

With the remote server running, you first log in to the Gitea UI with your user account, where you store the public SSH key, if this has not already been done elsewhere. In your account, you then create an empty repository for the backup data and mark it as a Private repository . Gitea returns the appropriate SSH URL. Now you can add the remote storage path origin to the existing local repository,

git remote add origin git@<Server>:<User/Repository>.git

and copy the local repository, including all previous commits, to the remote server:

git push -u origin main

The -u lets you define the remote server origin as the default upstream server for the repository. Future changes can then be sent to the origin server with the git push command, without any additional parameters. Git lets you specify multiple remote repositories and use

git push <name>

to send the updates to different servers.

The Git server can run on the company LAN as well as on a cloud system or in the demilitarized zone (DMZ) with an Internet connection. Because communication between the client and server relies on SSH encryption anyway, the cloud backup to the in-house Git server is secure even without a virtual private network (VPN). Either the web interface of the Gitea server on port 3000 should be protected by a reverse proxy/load balancer with HTTPS termination, or the service itself should run on HTTPS with a suitable certificate. To do this, modify the configuration of Gitea in ./gitea/conf/app.ini and expand the following section:

[server]
PROTOCOL = https
ROOT_URL = https://<URL>:<Port>
HTTP_PORT = <Port>
CERT_FILE = cert.pem
KEY_FILE = key.pem

Hosted Git services such as GitHub or GitLab are obviously out of the question as backup targets because they limit the size of the repositories.

Git in Git

Once you have familiarized yourself with the Git tool, you can optimize its use. For example, if you are just working on a project for a certain period of time, you can back up all related data to a separate directory and therefore to a separate Git. If the folder is inside an existing repository, Git notices and excludes the project directory as its own repository from the underlying Git.

The user then backs up two repositories: The document directory itself and the project. Thanks to Git's group features, project data can be shared between workgroups and checked out to multiple clients. When the project is completed, the clients can delete the local project directory, and the Git server keeps all the data as an archive that is available to users at any time.

Conclusions

Backup and version control are closely related topics, so Git is a very good choice as a backup tool for user data. Of course, Git does not back up the operating system or the installed applications or their configuration in the registry.