Using the GitLab backup script

The GitLab backup script records the revision of the Rails app when making the backup, and refuses to restore to another revision. This is not quite compatible with how omnibus-gitlab works.

1. There is no revision for the backup script to detect.
2. It is hard to go back to a specific old revision of the Rails app, because you would either have to find a .deb containing that revision or build one yourself.

/cc @sytses

Won't we version our .deb packages? I think the requirement to install an old deb to restore the backup is reasonable.

It would mean for us to keep .debs available (140MB+ each) for every omnibus-gitlab release (including patch releases) for however long we want people to be able to update from a given version.

Regardless of the hosting issue there is also the issue that the current backup code in GitLab will not work because it expects to be run in a git repository (see the link in the issue description).

Good points @jacobvosmaer feel free to put this on the agenda

Reassigned to @jacobvosmaer

mentioned in merge request !53 (merged)

I have discovered a new issue. The backup script assumes that the git user can rename the repositories directory to repositories.old.timestamp. Due to the directory layout in omnibus-gitlab, this is not possible: git owns /var/opt/gitlab/repositories, but not /var/opt/gitlab. This makes sense from a security perspective, because /var/opt/gitlab also contains the Postgres and Redis data directories.

mentioned in issue #63 (closed)

Done in https://gitlab.com/gitlab-org/omnibus-gitlab/milestones/2

Status changed to closed