Rake backup issue in 14.4.1


While taking rake backup after upgrading the GitLab to latest - v14.4.1 , we are getting the logs like below

docker exec gitlab gitlab-backup create

time="2021-11-05T08:39:57.470Z" level=warning msg="skipped create" command=create error="manager: repository empty: repository skipped" gl_project_path=xxxx/xxxx/xxxx relative_path=@hashed/0e/8a/0e8a6eedd28d2f1c776f0d48f7451b46e959470fb0c500f0d232d0b0ebac3a50.design.git storage_name=default
time="2021-11-05T08:39:57.473Z" level=warning msg="skipped create" command=create error="manager: repository empty: repository skipped" gl_project_path=xxxx/xxxx/xxxx.wiki relative_path=@hashed/0e/8a/0e8a6eedd28d2f1c776f0d48f7451b46e959470fb0c500f0d232d0b0ebac3a50.wiki.git storage_name=default

But these repositories are actually not empty.

While importing the backup we are getting below errors:-

docker exec gitlab gitlab-backup restore

time="2021-11-05T07:25:50.003Z" level=info msg="started restore" command=restore gl_project_path=xxxx/xxxx/xxxx relative_path=@hashed/f9/b7/f9b7214ee25dcca034227e1c869d5430dbc5b2a566ca4585bbfd16e8dbfd6b3b.design.git storage_name=default
time="2021-11-05T07:25:50.012Z" level=warning msg="skipped restore" command=restore error="manager: repository skipped: restore bundle: filesystem sink: get reader for \"@hashed/f9/b7/f9b7214ee25dcca034227e1c869d5430dbc5b2a566ca4585bbfd16e8dbfd6b3b.design.bundle\": doesn't exist" gl_project_path=xxxx/xxxx/xxxx relative_path=@hashed/f9/b7/f9b7214ee25dcca034227e1c869d5430dbc5b2a566ca4585bbfd16e8dbfd6b3b.design.git storage_name=default



I’m having the same issue with 14.4.2

1 Like

I’m having the same issue with 14.4.2

Having the exact same issue on 14.4.1

We are experiencing this with 14.5.0

I have the same issue on Gitlab CE 14.6.0 which prevents me from migrating to a new server. How can I resolve this?

ouch - didn’t expect to see this so consistently across so many versions of 14x. Is there a known bug for this?

I’m trying to restore a backup onto 14.4.1 from 14.4.1 and seeing this.

Are you all using docker?

I’ve just tried this with gitlab-ce installed normally (I don’t use docker). Have been able to restore 14.6.0 to a new server with 14.6.0. My procedure for a normal Gitlab installation:

  1. Install gitlab-ce.
  2. Copy gitlab.rb and gitlab-secrets.json to /etc/gitlab on new server
  3. Make sure sudo is installed (if you made new clean install of Linux, not all distros have sudo by default).
  4. If a specific IP was set for listening on in gitlab.rb, set this to the new server else nginx will fail to start later. If listening on all IP’s, then nothing to change.
  5. Run gitlab-ctl reconfigure to get gitlab running with empty data.
  6. Copy backup file to server and put in /var/opt/gitlab/backups
  7. Run chown git:git /var/opt/gitlab/backups/1641250988_2022_01_04_14.6.0_gitlab_backup.tar
  8. Run gitlab-ctl stop puma && gitlab-ctl stop sidekiq
  9. Run gitlab-backup restore BACKUP=1641250988_2022_01_04_14.6.0
  10. Run gitlab-ctl reconfigure
  11. Run gitlab-ctl restart
  12. Run gitlab-rake gitlab:check SANITIZE=true
  13. If gitlab-secrets.json was copied, run gitlab-rake gitlab:doctor:secrets

Obviously my procedure is different than compared to docker, because I’ve got it installed normally using gitlab-ce debian package. But hope some of the steps will help a bit. For me it worked, so I’m not sure if there is an issue with the Docker restore procedures or not.

If using docker, check the steps here: Back up and restore GitLab | GitLab and perhaps adapt my steps accordingly to get the restore working under docker. Alternatively if still no luck, open an issue here: Issues · GitLab.org / GitLab · GitLab

1 Like