raketask gitlab:backup:restore aborts #1042

ClarkHartness · 2017-01-04T15:57:39Z

This appears it may be an Upstream issue but I wanted to post here to see if anyone has had the problem and overcome it in some way.

Current Instance and New Instance are running 8.15.2

rsync backup to new server, chmod 0644 file.

When I execute the docker to run the restore raketask the first sign of an issue is the "date: invalid date"

I can choose the backup file, the task starts but aborts at ** Execute gitlab:backup:restore

Thanks in Advance!
Clark

--trace below:
----- Lines Removed for brevity -----------
Configuring nginx...
Configuring nginx::gitlab...

date: invalid date '@1483543531_2017_01_04'
â£ 1483543531_2017_01_04_gitlab_backup.tar (created at )
date: invalid date '@1483533029_2017_01_04'
â£ 1483533029_2017_01_04_gitlab_backup.tar (created at )

Select a backup to restore:

Select a backup to restore: 1483533029_2017_01_04_gitlab_backup.tar
Running raketask gitlab:backup:restore...
** Invoke gitlab:backup:restore (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute gitlab:backup:restore
rake aborted!
TypeError: no implicit conversion of nil into String
/home/git/gitlab/lib/backup/manager.rb:122:in exist?' /home/git/gitlab/lib/backup/manager.rb:122:in unpack'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:32:in block (3 levels) in <top (required)>' /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:240:in block in execute'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:235:in each' /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:235:in execute'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:179:in block in invoke_with_call_chain' /usr/lib/ruby/2.3.0/monitor.rb:214:in mon_synchronize'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:172:in invoke_with_call_chain' /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:165:in invoke'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:150:in invoke_task' /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:106:in block (2 levels) in top_level'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:106:in each' /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:106:in block in top_level'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:115:in run_with_threads' /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:100:in top_level'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:78:in block in run' /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:176:in standard_exception_handling'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:75:in run' /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/bin/rake:33:in <top (required)>'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/bin/rake:22:in load' /home/git/gitlab/vendor/bundle/ruby/2.3.0/bin/rake:22:in

'
Tasks: TOP => gitlab:backup:restore

The text was updated successfully, but these errors were encountered:

ClarkHartness · 2017-01-04T18:31:45Z

I was able to Workaround this issue by running the raketask through docker exec

docker exec -it gitlab sudo -HEu git bundle exec rake gitlab:backup:restore RAILS_ENV=production

I had to remove all but one backup as I did not try to feed the backup directly to the rake command.

I will play around with it a bit before I put this instance into production.

adamniedzielski · 2017-01-10T09:05:11Z

The relevant issue in GitLab issue tracker is https://gitlab.com/gitlab-org/gitlab-ce/issues/26090. It will be fixed by https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8477 and released in a patch release to 8.15.

As a heads up to the maintainers of this project: we changed the timestamp format from 1483533029 to 1483533029_2017_01_04 in 8.15. If your code relies on the previous format of the timestamp (which may be the case because of date: invalid date in the logs), please update it. I'm sorry for the inconvenience!

Niceplace · 2017-01-16T17:10:22Z

I have the same error here, running

Gitlab : 8.15.4
Postgre : 9.6-1

Up from

Gitlab : 8.13.6
Postgre : 9.5-3

I can't restore my data from previous backup and the upgrade flushed all the data (repositories, groups, users).

What should I do ?

Niceplace · 2017-01-16T19:13:48Z

@sameersbn It seems that the restore system is broken for 8.15.6, can you confirm this ? Its a major blocker for me right now.

solidnerd · 2017-01-16T19:59:50Z

Hey,
what you can do is to format your file correctly and try to restore it again.

So copy the EPOCH from your file and check the date with date -d @1482721258 from your backup 1482721258_gitlab_backup.tar .

Rename your file like @adamniedzielski said so in this case it would be 1482721258_2016_12_26_gitlab_backup.tar.

Now you can exec the command as follow:

docker-compose run --rm gitlab app:rake gitlab:backup:restore BACKUP=1482721258_2016_12_26

Niceplace · 2017-01-16T20:07:24Z

Hi Niclas, thanks for the quick answer ! I'll give it a try !

waterdrops · 2017-01-19T02:16:23Z

Restoring from backup,I encounter a similar error,running


System information
System:		Ubuntu 14.04
Current User:	git
Using RVM:	no
Ruby Version:	2.3.3p222
Gem Version:	2.5.2
Bundler Version:1.13.7
Rake Version:	10.5.0
Sidekiq Version:4.2.7

GitLab information
Version:	8.15.4
Revision:	a0b1379
Directory:	/home/git/gitlab
DB Adapter:	postgresql
Using LDAP:	yes
Using Omniauth:	no

GitLab Shell
Version:	4.1.1
Git:		/usr/bin/git

the trace info below:


bundle exec rake gitlab:backup:restore BACKUP=1484769615_2017_01_18 RAILS_ENV=production --trace

** Invoke gitlab:backup:restore (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute gitlab:backup:restore
rake aborted!
TypeError: no implicit conversion of nil into String
/home/git/gitlab/lib/backup/manager.rb:122:in `exist?'
/home/git/gitlab/lib/backup/manager.rb:122:in `unpack'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:32:in `block (3 levels) in <top (required)>'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:240:in `block in execute'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:235:in `each'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:235:in `execute'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/usr/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:172:in `invoke_with_call_chain'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:165:in `invoke'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:150:in `invoke_task'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:106:in `block (2 levels) in top_level'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:106:in `each'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:106:in `block in top_level'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:115:in `run_with_threads'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:100:in `top_level'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:78:in `block in run'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:176:in `standard_exception_handling'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:75:in `run'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/rake-10.5.0/bin/rake:33:in `<top (required)>'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/bin/rake:22:in `load'
/home/git/gitlab/vendor/bundle/ruby/2.3.0/bin/rake:22:in `<main>'
Tasks: TOP => gitlab:backup:restore

xueshanf · 2017-02-02T03:40:19Z

@waterdrops

This works for me (8.15.4) - It looks like the BACKUP needs a full file name, not just timestamp:

docker exec gitlab.service /bin/bash -c "cd /home/git/gitlab; sudo -u git -H bundle exec rake gitlab:backup:restore force=yes RAILS_ENV=production BACKUP=1485922557_2017_02_01_gitlab_backup.tar

waterdrops · 2017-02-07T03:09:07Z

@xueshanf thanks,it works :); BACKUP file format changed in this version(8.15.4),thanks again 👍

Niceplace · 2017-02-07T20:02:52Z

I tested in another environment and followed the original procedure of sameersbn/docker-gitlab found here and it worked (providing I kept the same database version).

The thing I wasn't doing correctly was creating the backup with the rake task with the NEW gitlab image. I was trying to restore a backup created with the old image into the new one, which failed.

As Gitlab docs specify : "You can only restore a backup to exactly the same version of GitLab on which it was created. The best way to migrate your repositories from one server to another is through backup restore" source

due to format change in version 9.2 see: https://docs.gitlab.com/ce/raketasks/backup_restore.html#backup-timestamp sameersbn#1414 sameersbn#1042 (comment)

stale · 2020-05-07T10:46:04Z

This issue has been automatically marked as stale because it has not had any activity for the last 60 days. It will be closed if no further activity occurs during the next 7 days. Thank you for your contributions.

froque mentioned this issue Aug 9, 2018

date: invalid date correction #1699

Merged

stale bot added the wontfix label May 7, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

raketask gitlab:backup:restore aborts #1042

raketask gitlab:backup:restore aborts #1042

ClarkHartness commented Jan 4, 2017

ClarkHartness commented Jan 4, 2017

adamniedzielski commented Jan 10, 2017

Niceplace commented Jan 16, 2017 •

edited

Loading

Niceplace commented Jan 16, 2017

solidnerd commented Jan 16, 2017 •

edited

Loading

Niceplace commented Jan 16, 2017

waterdrops commented Jan 19, 2017 •

edited

Loading

xueshanf commented Feb 2, 2017

waterdrops commented Feb 7, 2017

Niceplace commented Feb 7, 2017 •

edited

Loading

stale bot commented May 7, 2020

raketask gitlab:backup:restore aborts #1042

raketask gitlab:backup:restore aborts #1042

Comments

ClarkHartness commented Jan 4, 2017

ClarkHartness commented Jan 4, 2017

adamniedzielski commented Jan 10, 2017

Niceplace commented Jan 16, 2017 • edited Loading

Niceplace commented Jan 16, 2017

solidnerd commented Jan 16, 2017 • edited Loading

Niceplace commented Jan 16, 2017

waterdrops commented Jan 19, 2017 • edited Loading

xueshanf commented Feb 2, 2017

waterdrops commented Feb 7, 2017

Niceplace commented Feb 7, 2017 • edited Loading

stale bot commented May 7, 2020

Niceplace commented Jan 16, 2017 •

edited

Loading

solidnerd commented Jan 16, 2017 •

edited

Loading

waterdrops commented Jan 19, 2017 •

edited

Loading

Niceplace commented Feb 7, 2017 •

edited

Loading