Testing a backup on a separate server

DevSecOps
,
1

I’m trying to restore a backup to a separate server from the Kubernetes hosted cluster that we run just to test the effectiveness of the backups.

I’ve setup a standalone gitlab instance (it’s definitely the same version) and restored the backup from the command line.
The primary issue i have at the moment is when i try to hit the page i’m constantly hitting
the following error.

RuntimeError (Object Storage is not enabled for FaviconUploader):
  
app/uploaders/object_storage.rb:530:in `storage_for'
app/uploaders/object_storage.rb:305:in `object_store='
app/uploaders/object_storage.rb:103:in `upload='
app/uploaders/object_storage.rb:88:in `retrieve_from_store!'
carrierwave (1.3.4) lib/carrierwave/mounter.rb:35:in `block in uploaders'
carrierwave (1.3.4) lib/carrierwave/mounter.rb:33:in `map'
carrierwave (1.3.4) lib/carrierwave/mounter.rb:33:in `uploaders'
carrierwave (1.3.4) lib/carrierwave/mount.rb:142:in `favicon'
carrierwave (1.3.4) lib/carrierwave/mount.rb:366:in `favicon'
lib/gitlab/favicon.rb:8:in `main'

This isn’t a production server so i don’t mind hacking at it, i’ve checked the secrets and everything seems ok except for the AvatarUploader complaining about the same thing.

Does anyone know if there is anyway to hack at the database to get this running and repoint everything to the local file system, i’ve had a look for example the packages_package_files table uses the file_store column to determine whether its local or on some kind of object store.

I honestly just need the thing to start and to look at one repo, i get this is less than optimal but it’s just a test of the backups we’re taking to make sure that they are recoverable should we need them.

2

Restoring a GitLab backup to a standalone instance can be challenging, especially when migrating from a Kubernetes-hosted environment that relies on Object Storage. The error you’re encountering suggests that GitLab is still trying to reference object storage for assets like favicons and avatars, even though your new instance doesn’t have it enabled. To resolve this, update the gitlab.rb configuration to disable object storage and ensure all file references in the database are set to use the local filesystem. Running gitlab-ctl reconfigure after making these changes should help GitLab recognize the updated storage settings. Additionally, checking if the favicon and avatar files exist in /var/opt/gitlab/gitlab-rails/public/uploads/ and manually uploading them if necessary can prevent missing file errors.

Another crucial step is ensuring that all database entries referencing Object Storage are updated to point to local storage. The file_store column in tables like packages_package_files determines whether files are stored remotely or locally, so running an SQL update to set file_store = 1 can redirect GitLab accordingly. If the issue persists, restarting GitLab services using gitlab-ctl restart can help apply the changes effectively. Platforms like the GitLab website and expert development team provide valuable insights into troubleshooting similar issues. Testing backups in a separate environment is a great practice to ensure disaster recovery readiness, and addressing storage mismatches will make the restoration process smoother.