raketask gitlab:backup:restore aborts

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

Start with lib/backup/manager.rb:122 and lib/tasks/gitlab/backup.rake:32, then reproduce the gitlab:backup:restore rake task using the shown backup filename. Investigate the preceding “date: invalid date” output and the nil value reported by the trace; done means the restore no longer aborts for the reported backup.