Gitlab Restore Info regarding mount points

Dear Team,

I need to reinstall my Gitlab Omnibus Installation, since the current installation is on CentOS 7. The new installation will be on Rocky OS.

I plan to do Gitlab Backup restore following Restore_Gitlab

However, I have questions regarding the part Restoring directories that are mount points
If you’re restoring into directories that are mount points, you must ensure these directories are empty before attempting a restore. Otherwise, GitLab attempts to move these directories before restoring the new data, which causes an error.

Does that mean, I need to keep following directories empty? Since these are SMB shares

  • lfs_storage_path (/mnt/data/isi_git_lfs)
  • registry_path (/mnt/data/isi_git_registry)

And does following needs to be empty as well -

gitlab_rails[‘gitlab_repository_downloads_path’] = ‘/mnt/data/local/gitlab/tmp’
gitlab_rails[‘artifacts_path’] = “/mnt/data/local/gitlab/shared/artifacts”
gitlab_rails[‘uploads_directory’] = “/mnt/data/local/gitlab/uploads”
gitlab_rails[‘pages_local_store_path’] = “/mnt/data/local/gitlab/shared/pages”
gitlab_rails[‘backup_path’] = “/mnt/data/local/backup”

git_data_dirs = /mnt/data/local/gitlab/data

gitlab_rails[‘shared_path’] = '/mnt/data/local/gitlab/shared

postgresql[‘dir’] = “/mnt/data/local/gitlab-postgresql”

Basically, does “/mnt/data/local” need to be emptied before restoration?

Thanks for the help,

Best Regards,

What does it matter that they are SMB mounts?
They shouldn’t contain anything but what GitLab has put there, and that should be in the backup.

If you have put anything else in those directories, you’re pretty much on your own in finding out how to make that available to anything else that depends on it. GitLab wants the directories it’s configured to use to be empty.

No, /mnt/data/local/gitlab and /mnt/data/local/gitlab-postgresql need to be empty. If that is the directories GitLab is configured to use.
Again it’s directories that shouldn’t contain anything important that is not included in the backup.

If you can make GitLab unavailable during this operation, I think (but I’m not guaranteeing anything and it’s your installation) it would work to configure GitLab to use some other directories while restoring and then merging the directories afterwards. Of course that requires some disk space on the drives holding the temporary directories, but with some care/work I think it should be possible to place them on the drives that will end up holding the data, making the temporary requirements minimal.

Thank you for your response. The fact that these are SMB shares shouldn’t matter, but I mentioned it for context. These shares contain the Container Registry and LSF data.

The restore documentation was unclear to me. It seems to say that if the restore is done into directories that are mount points, only those mount points should be empty, and the rest can remain as they are.

Since /mnt/data/local is on a separate volume from the OS, this volume and its data will remain intact after the OS reinstallation. If I could restore without emptying /mnt/data/local, I would leave it as is.

However, since /mnt/data/local/gitlab and /mnt/data/local/gitlab-postgresql are configured for use, I will empty them before the restoration.

This is my first time performing a GitLab restore.

Best regards,

That is unclear to me. What is “the rest”?
The rest of the directories? That includes directories where unrelated things are stored, GitLab of course doesn’t care.
The rest of the mounts? Again GitLab doesn’t care what else is on there.

If you know what you’re doing (to a degree that precludes anyone asking those questions), could save some time by not restoring data that is already there, but you really need to know what you’re doing, or you end up with an inconsistent system, where e.g. there is data in the filesystem that GitLab can’t find because it’s not referenced in the database.

By the rest I mean rest of directories that are configured to be used by Gitlab other than the mount points(in my case I use mounts for LFS and Container registry)

I understand that Gitlab does not care about unrelated directories and unrelated mount points.

But I understand now, thanks for explaining.

Best Regards,