Migrating Repo Storage

Hey Guys

New here, so please excuse the inevitable knowledge gaps. I’ll try to be concise to make up the difference…

We run an on-prem Gitlab EE server, version 12.0.2 on Centos 7. For conciseness;

image|617x499

Currently, our repo storage location is a mount point connected to a NAS, and it contains about 7GB of .git files. For various reasons, including that pointing at a NAS for this fills me some horror, we’d like to move the repo location from this mountpoint/NAS to a local storage location which is part of the server.

I already/mount point allocated and with enough storage space, but before touching anything I wanted to confirm that I am following the right process to safely move the repo.

If my digging around for answers is correct, I am going to follow this process;

  1. Stop the Gitlab services.
  2. Copy the data from /nasmountpoint to /local/data/gitrepo/
  3. Browse to/open /var/opt/gitlab/gitaly/config.toml
  4. Under [[storage]] change path = ‘/gitrepo/repositories’ to the /local/data/gitrepo folder above.
  5. Unmount /nasmountpoint (to be sure it is no longer being used)
  6. Start the Gitlab services

As I said, pretty fresh to Gitlab in general, so please scream at me if the above is incorrect, incomplete or unnecessarily risky.

Much appreciated!

Mike

Hi,

looks good to me with one exception: Reading the Gitaly docs, especially for the storage parts, makes me believe that you need to ensure that both, config.toml and GitLab’s main config file gitlab.rb are in sync with the storage paths - if you run both on the same host.

https://docs.gitlab.com/ee/administration/gitaly/reference.html#storage

These names and paths are also defined in the gitlab.yml configuration file of GitLab. When you run Gitaly on the same machine as GitLab, which is the default and recommended configuration, storage paths defined in Gitaly’s config.toml must match those in gitlab.yml .

(not sure why it is called gitlab.yml here, I guess that’s a typo)

After modifying the config files, make sure to reconfigure GitLab before restarting it.

One thing I’d suggest doing before going anywhere else - take a full backup snapshot of that server. So in case there are troubles, you can always restore and rollback.

Cheers,
Michael

1 Like

Hi Michael

That’s really great, thank you for taking the time to reply.

I’ll definitely be taking the time to snapshot/backup before making any changes, as this is all live. In terms of that Gitlab.yml file you referenced, do you know off the top of your head what the correct file is if it isn’t gitlab.yml?

Thank you!
Mike

Hi,

/etc/gitlab/gitlab.rb contains the main GitLab configuration, the storage options are mentioned here.

Cheers,
Michael

Perfect, thank you. I’ll check both of those config files, put a process together and let you know how I get on. :slight_smile:

Much appreciated Michael.

Mike

1 Like

Hi Michael

I hope you had a great Christmas/New Year break. I thought I’d come back and update you re progress, and of course ask a question as part of the process. :slight_smile:

So, I (snapshotted and then) copied over my repo data from the NAS it was previously hosted on to local storage. I updated the gitlab.rb file and the gitaly config file, and restarted everything. Unfortunately, following the restart, all of the projects in Gitlab simply returned a 404 error (served inside the gitlab UI), but none of the projects were accessible.

I can only assume there is a permissions issue with the files and folders, but just wanted to check this wasn’t something you had heard of before?

Many thanks
Mike

Update:

I solved the 404 issue by reconfiguring the ‘git’ user as the owner of the git repository folder, by using;
chown -R git /gitrepo

(chown -R )

Will update for reference/searchability once the procedure is completely finished with any tips/gotcha’s.

Glad you’ve solved it by yourself, I was a little busy in the past days :wink:

Permissions are always the first thing I’ll look at when troubleshooting these access problems. The second shot are security mechanisms like SELinux or AppArmor preventing access.

Cheers,
Michael