docker-gitlab: backup fail in 8.16.6

i did not have configure a aws or google backup.

8.16.4

Uploading backup archive to remote storage  ... skipped

8.16.6

Uploading backup archive to remote storage {{GCS_BACKUP_BUCKET}} ... rake aborted!
Fog::Service::NotFound: google has no storage service
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-core-1.42.0/lib/fog/core/services_mixin.rb:18:in `rescue in new'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-core-1.42.0/lib/fog/core/services_mixin.rb:8:in `new'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-core-1.42.0/lib/fog/storage.rb:27:in `new'
/home/git/gitlab/lib/backup/manager.rb:172:in `connect_to_remote_directory'
/home/git/gitlab/lib/backup/manager.rb:50:in `upload'
/home/git/gitlab/lib/backup/manager.rb:37:in `block in pack'
/home/git/gitlab/lib/backup/manager.rb:20:in `chdir'
/home/git/gitlab/lib/backup/manager.rb:20:in `pack'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:20:in `block (3 levels) in <top (required)>'
NoMethodError: undefined method `to_sym' for {"GCS_BACKUP_ACCESS_KEY_ID"=>nil}:Hash
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-core-1.42.0/lib/fog/core/utils.rb:19:in `block in prepare_service_settings'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-core-1.42.0/lib/fog/core/utils.rb:17:in `each'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-core-1.42.0/lib/fog/core/utils.rb:17:in `prepare_service_settings'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-core-1.42.0/lib/fog/core/utils.rb:18:in `block in prepare_service_settings'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-core-1.42.0/lib/fog/core/utils.rb:17:in `each'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-core-1.42.0/lib/fog/core/utils.rb:17:in `prepare_service_settings'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-core-1.42.0/lib/fog/core/service.rb:267:in `handle_settings'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-core-1.42.0/lib/fog/core/service.rb:98:in `new'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-google-0.5.0/lib/fog/storage/google.rb:13:in `new'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-core-1.42.0/lib/fog/core/services_mixin.rb:16:in `new'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/fog-core-1.42.0/lib/fog/storage.rb:27:in `new'
/home/git/gitlab/lib/backup/manager.rb:172:in `connect_to_remote_directory'
/home/git/gitlab/lib/backup/manager.rb:50:in `upload'
/home/git/gitlab/lib/backup/manager.rb:37:in `block in pack'
/home/git/gitlab/lib/backup/manager.rb:20:in `chdir'
/home/git/gitlab/lib/backup/manager.rb:20:in `pack'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:20:in `block (3 levels) in <top (required)>'
Tasks: TOP => gitlab:backup:create
(See full trace by running task with --trace)

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 2
  • Comments: 17 (4 by maintainers)

Commits related to this issue

Most upvoted comments

Hi, I encountered an issue same as @gimler mentioned, and also found reason. I will make a pull request to resolve it.

Hey, I’m a little bit confused now. Is this a problem our Image or does it come from the upstream? The first error could be from us but this now seems me as an upstream error.

What file is that failure logged in?

I have this 8.16.6 image but am seeing a different backup failure: the backup tar file (%s_%Y_%m_%d_gitlab_backup.tar) is fine, but all of its components are also in the backup directory.

For instance, before today, the process just creates a single tar-file:

-rw-------  1 1000 1000 106956800 Feb 22 01:00 1487754057_2017_02_22_gitlab_backup.tar

But today, I find this:

-rw-------  1 1000 1000 106967040 Feb 23 01:00 1487840434_2017_02_23_gitlab_backup.tar
-rw-------  1 1000 1000       146 Feb 23 01:00 artifacts.tar.gz
-rw-rw-r--  1 1000 1000       159 Feb 23 01:00 backup_information.yml
-rw-------  1 1000 1000       146 Feb 23 01:00 builds.tar.gz
drwxrwxr-x  2 1000 1000      4096 Feb 23 01:00 db/
-rw-------  1 1000 1000   3709913 Feb 23 01:00 lfs.tar.gz
drwx------  4 1000 1000      4096 Feb 23 01:00 repositories/
-rw-------  1 1000 1000   2640677 Feb 23 01:00 uploads.tar.gz

They are confirmed redundant (the tar-file is complete, all components are identical). It’s easy enough to remove them manually, but this will quickly clutter things. I don’t know what will happen if the files exist when the next backup is attempted tomorrow morning (I don’t really want to find out, meaning I have another daily cleanup task until this is fixed).

(I’m happy to move this to a different issue if it’s completely unrelated.)