Error with gitlab backup after GItlab CE 14.3.6 version upgrade

Hi , We have upgraded gitlab ce to 14.3.6 and after this we tried taking manual backup using cmd “gitlab-rake gitlab:backup:create” but we faced issue saying .

time=“2022-11-12T05:32:23Z” level=fatal msg=“create: pipeline: 1 failures encountered”
rake aborted!
Backup::Error: gitaly-backup exit status 1
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/gitaly_backup.rb:44:in wait' /opt/gitlab/embedded/service/gitlab-rails/lib/backup/repositories.rb:43:in dump’
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:114:in block (4 levels) in <top (required)>' /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:281:in block in execute’
/opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:281:in each' /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:281:in execute’
/opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:219:in block in invoke_with_call_chain' /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:199:in synchronize’
/opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:199:in `invoke_with_call_chain’

Have you tried the gitlab-backup create command instead of gitlab-rake ?

After upgrade to 14.9.5 , we again tried taking backup and it worked with the same cmd
gitlab-rake gitlab:backup:create

@lame8hamza can you paste you backup command and let me check?
Also are you aware of Registry and crond service , because after upgrade in prod i m not able to see this two service using the cmd “gitlab-ctl status” but same we tested in our test env and was able to see both service running.

The command to create backup with newer versions(12.2 and above) of gitlab ce is ‘gitlab-backup create’ as stated in the docs in this link Back up GitLab | GitLab
Make sure that you respected the requirements for backuping your instance, for example, you should have the same version of the instance you’re creating the backup from in order to restore it in the new instance, otherwise that might cause some troubles with the gitlab services in the restored instance