GitLab Backup / Restore through GUI?

I’m in a tricky situation right now: I have two GitLab Servers. The current live one is planned to be decommissioned as the owner of said server is no longer interested in supporting one. I’ve built my own GitLab Server (got HTTPS key/cert support set up, and even routing through Nginx properly) and plan for the current project on the current live GitLab to be moved to it. I obviously have terminal root access to my own GitLab Server, so I can update gitlab-secrets.json and gitlab.rb as necessary.

However, the owner of our current live GitLab is not contacting me. I want to backup the Git project on the live GitLab and restore it on my new GitLab Server. I have no way of being able to login to the server via terminal (as he never gave me the credentials), but I can login to the GUI and I do have Owner status on the live GitLab Server. This guide shows how to backup/restore via the terminal, but as mentioned this is not an option for me if I don’t have access to the live GitLab’s terminal.

Is there anyway in the GitLab GUI to backup a Git project and restore it in another GitLab Server? I suppose one option is to pull the project off the live GitLab Server and push it all to the new GitLab Server, but this seems like a messy ordeal when the project is about 20 GB in disk space. And if I’ve learned anything about Git (still rather a noob, the Programmers on my team are the real heroes, I’m just the new admin) is that Git Pushing can cause a lot of problems if just 1 file does not make the push.

EDIT: Please see this post. I no longer have Terminal Access to my Live GitLab (I did for awhile, but no longer), and I have until Monday (August 26) to get my Project and its Issues hosted somewhere temporarily until I’m ready to set up a new Server to host the new GitLab I’m talking about in the OP (my server host is pulling the plug on my GitLab, whether I’m ready or not).

You should be able to export the project from the live server and import it on your own server.

Make sure the import/export version matches on both the old and the new servers.

Importing will not be possible if the import instance version differs from that of the exporter.

Ok … both GitLab Servers are version 11.10.1 (861fe405571). I’m aware this isn’t the latest version, but right now I want to make sure I can export/import the project before I attempt to upgrade GitLab (especially since the GitLab Server I will be importing to I have full server access to and can revert the current snapshot if anything goes wrong).

@gregorip I checked out the Export instructions you linked … and I’ve run into a problem. I can’t find an “Export project” button.

There is an GitLab export and Project export enabled checkboxes in Settings, and they’re both checked … no export button. Where would I find the Export button?

I have 11.11.3 but I think this should be the same as with 11.10.1.

Go to your project settings, under the general tab, expand the Advanced section. There should be an export project button there.

So I was able to find the Export Project button in GitLab. Its been over 2 days now since I clicked the Export Project button, and unfortunately, I have yet to receive an email. Also I have yet to see a Download Export button come up in place of the Export Project button.

How long should I expect GitLab to export my project? Its about 15 GB in size, and is hosted on a fairly fast network host.

Is there some other way I can Export my project besides through the GUI? I have just gotten Terminal Access from my admin to this GitLab Server, so if there’s a way to export via Terminal, I’d like to hear how I can do it.

I’ve never tried exporting a really large project from GitLab so I don’t know how long you should wait but it only took a few minutes for me when exporting ~70MB project.

As far as I know the process of creating a backup is for the whole application - not project-specific.

I think at this point someone from GitLab can better help you than I can. Maybe @gitlab-greg could - I usually see him around.


Might be a relevant issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/2397

Hi @naupe,

Sorry to hear you’re in a tricky situation. It sounds like the export is failing to generate for this large project.

As @gregorip mentioned, the gitlab:backup:create backup process will create a backup of the entire application, not a single project.

I suggest attempting a different method of importing this project into the new instance you’ve built.

There are two alternatives that I think would work well for your use case.

Can you try importing the project by URL.
If the project is not publicly accessible, you’ll need to add authentication information to the source Git Repository URL (as shown in the screenshot)
Example: http(s)://username:password@<your_instance>/<group/user>/<project>.git

If this doesn’t work, try to export/import the project using the Project import/export API.

Hopefully one of these works and gets you up-and-running. Let me know how it goes.

1 Like

Thank you for the post @gitlab-greg. I have good news and bad news:

Good News: The Import function works! Only took 5 mins, shockingly enough!

Bad News: The Cloned Project is … smaller. While the project on the original GitLab is 20 GB, this cloned one is 19 GB.

  • Original Project on Old Server: ( 402.2 MB repository, 0 Bytes build artifacts, 19.6 GB LFS )
  • Cloned Project on New Server: ( 0 Bytes repository, 0 Bytes build artifacts, 19 GB LFS )

Where is the missing 402.2 MB repository and .6 GB of LFS?

Other Bad News: I’ve discovered on my New GitLab Server that I’m unable to Rename or Delete Projects. This is likely entirely unrelated to my concern I mentioned earlier, but I want to highlight it in case there is an issue with the GitLab Install:

  • When I try to delete a project, I receive 500 - Whoops, something went wrong on our end. I can only click “Go Back”, and the project is still there.
  • When I try to renamea project, I receive 500 - Whoops, something went wrong on our end. I can only click “Go Back”, and the project is not renamed.

I have no issues like this on the current live GitLab, and both are on version 11.10.1 (861fe405571). If possible, I do not want to update either GitLabs until I’ve moved the New Server to its new lab and the Old GitLab Server is decommissioned.

I assume both GitLabs need to be the same version for the Import process to work? And I do fear trying to update both and Issues arising on the Old GitLab (I don’t have the ability to rollback like I do on the New GitLab Server).

Hi @naupe,

Ideally, both GitLabs will be the same version for the import process. Even so, I would not expect a slight mismatch in versions to cause the issues you’re seeing.

It seems like the import was not successful.

Which import function did you use?

I suggest deleting this project and re-attempting the import using one of the other methods. If you’re unable to delete the project using the GUI (which seems to be the case), you can do it using the Projects API.

Regarding the 500 errors, I suggest running a gitlab-ctl reconfigure followed by a gitlab-ctl restart on the new server and seeing if the problem persists.

@gitlab-greg: Importing the project by URL. Certainly seems like the simplest method to importing projects, and very fast too. But obviously files are missing …

I want to get back to what is now a bigger issue at hand now, and could very well tie into my issues with project importing:

When I run gitlab-ctl reconfigure, I’m receiving the following error (where domainname.com is a placeholder I’m posting here, not the actual Domain Name I’m using).

There was an error running gitlab-ctl reconfigure:

/etc/gitlab/gitlab.rb:1671: syntax error, unexpected tIVAR, expecting keyword_do                                      or '{' or '('
...ct_emails'] = [admin@domainname.com] # This should be an a...
...                    ^~~~~~~~~~~
/etc/gitlab/gitlab.rb:1671: syntax error, unexpected ']', expecting end-of-input
...ls'] = [admin@domainname.com] # This should be an array of...
...

The email address is definitely correct, and this is the first time I’m seeing this error. I’m still using GitLab version 11.10.1 (861fe405571). Anyways, I went ahead and updated that line of code in gitlab.rb: from letsencrypt['contact_emails'] = [admin@domainname.com] to letsencrypt['contact_emails'] = ['admin@domainname.com'] (I assume this is the right syntax correction?). When I run gitlab-ctl reconfigure again, here is what I now get:

There was an error running gitlab-ctl reconfigure:

letsencrypt_certificate[git.domainname.com] (letsencrypt::http_authorization line 3) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 20) had an error: RuntimeError: [git.domainname.com] Validation failed for domain git.domainname.com

Running handlers complete
Chef Client failed. 8 resources updated in 24 seconds

Looking at the certificate.rb file, I have no idea how to go about solving it. Also, after I’ve performed the gitlab-ctl reconfigure a second time, I now get an Nginx 502 Bad Gateway error.

So … that’s troubling. A summary of my setup: I am running Proxmox VE as the Main OS and VM Manager of my Server, an Nginx VM that is handling Reverse Proxying as well as Certbot (Let’s Encrypt) for HTTPS and the GitLab VM (which is not supposed to be handling HTTPS) along with other VMs being reverse proxied through Nginx.

The only solution to stopping the 502 Bad Gateway error I’ve found is rolling back the VM to prior to performing a gitlab-ctl reconfigure. Of course the issue of deleting and renaming projects still remains. Clearly there’s some issues with my GitLab setup. Any suggestions?

@gitlab-greg @gregorip No ideas to suggest?

@naupe It sounds like the project is failing to import using the Import file
or importing the project by URL

I suggest deleting this project and re-attempting the import using import via Project import/export API.
If you’re unable to delete the project using the GUI, you can do it using the Projects API.

You could try running gitlab-ctl tail > gitlab-tail.log while the import is processing and any errors should be captured in this log with a tag of “error” or “failed” with info on what failed and when during the import process.

I went ahead and updated that line of code in gitlab.rb : from letsencrypt['contact_emails'] = [admin@domainname.com] to letsencrypt['contact_emails'] = ['admin@domainname.com'] (I assume this is the right syntax correction?).

This is correct. Quotes (') are necessary to parse the email address as expected.

The letsencrypt error:
letsencrypt_certificate[git.domainname.com] (letsencrypt::http_authorization line 3) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 20) had an error: RuntimeError: [git.domainname.com] Validation failed for domain git.domainname.com

Is failing at the domain verification stage.

I am running Proxmox VE as the Main OS and VM Manager of my Server, an Nginx VM that is handling Reverse Proxying as well as Certbot (Let’s Encrypt) for HTTPS and the GitLab VM (which is not supposed to be handling HTTPS) along with other VMs being reverse proxied through Nginx.

If the domain is entered correctly, then I suspect the Nginx VM handling reverse proxying/certbot is introducing issues that cause the letsencrypt domain verification to fail.

@gitlab-greg Again, thank you for your continued assistance!

The Project API documentation is confusing. How do I delete the project via API in terminal?

So I guess I’d need to open a second window and run it while reconfiguring? I don’t know that it matters because … the GitLab Reconfiguration now succeeds! Here is the gitlab.rb file:

external_url 'https://git.domainname.com'
registry_nginx['redirect_http_to_https'] = true
mattermost_nginx['redirect_http_to_https'] = true

nginx['redirect_http_to_https_port'] = 80	# Originally commented out
nginx['redirect_http_to_https'] = true
nginx['listen_port'] = 80			# originally 8081, a port I enabled for GitLab on my Router ... well, Nginx isn't listening for port 8081, but 80 instead
nginx['listen_https'] = false

letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['admin@domainname.com']	# Added single quotes
letsencrypt['auto_renew'] = true		# originally false
letsencrypt['auto_renew_hour'] = 12
letsencrypt['auto_renew_minute'] = 30
letsencrypt['auto_renew_day_of_month'] = "*/7"

I think the changes in the Redirect and Port were what fixed it. Here is what the end of the gitlab-ctl reconfigure showed:

Running handlers:
Running handlers complete
Chef Client finished, 8/681 resources updated in 17 seconds
gitlab Reconfigured!

However, I still have the 500 errors:

  • When I try to delete a project, I receive 500 - Whoops, something went wrong on our end. I can only click “Go Back”, and the project is still there.
  • When I try to renamea project, I receive 500 - Whoops, something went wrong on our end. I can only click “Go Back”, and the project is not renamed.

I did some Google Searching and found these pages:


I can’t remember if it was 1 of these 2 Issues or a different one altogether, but one of the comments proposed that the issue is related to non-completed project imports. That explanation seems to make the most sense to me, given that my GitLab setup is working just fine otherwise: I’m just just unable to delete/rename projects, and the project I’m trying to import didn’t import all the way properly.

So, I guess this goes back to the API: how do I delete projects via the API? And then how should I go about importing/exporting the project from the old GitLab Server to the new GitLab server via API? Again, I’m having a lot of difficulty understanding the API guide.

To use the API, you’ll need some form of authentication, usually a token.

To delete a project, you’ll also need the project_id, which you can find on the project page in the web interface.

Then you’re all set to remove a project using the API

curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://<your_gitlab>/api/v4/projects/<project_id>

Change the request type (DELETE) and use syntax/variables as indicated here for most everything else project-related : https://docs.gitlab.com/ee/api/projects.html
and this for everything import/export related:
https://docs.gitlab.com/ee/api/project_import_export.html

Everyone can contribute to GitLab, so if you’d be willing to to help clarify or improve the documentation for other users, your contribution would be valuable.
You can suggest an improvement by creating an issue or suggest an improvement by submitting a merge request. This will “get the ball rolling” and make sure that it gets triaged approrpiately.

@gitlab-greg This is getting a lot more complicated, and the rabbit hole is going down a lot further now.

Alright, I think I figured this out. [My User Avatar] -> Settings -> Access Tokens -> Created a new api, sudo Personal Access Token.

I found an easy way to find the project_id: I go to https://git.domainname.com/api/v4/projects/ and I can just search for the ids manually.

So I login to the GitLab Server via Terminal, sudo to root and input the following:
curl --request DELETE --header "PRIVATE-TOKEN: <api-suo Personal Access Token>" https://git.domainname.com/api/v4/projects/3 (3 happens to be the ID for a project I want to delete)

I receive {"message":"500 Internal Server Error"} back. I try other Project IDs and receive the same. Obviously the same 500 error I was receiving in the GUI. So the API does not look like the solution and that there could be some other problem with my GitLab.

I go back to searching for this issue, and I come across a comment in a GitLab Issue relating to what I’m having issues with:

@mholle & @lxndr.bertrand are you able to follow http://review-docs-docs-s51l30.178.62.207.141.xip.io/ce/raketasks/backup_restore.html#reset-runner-registration-tokens and see if that helps, please?

So its a bad link now sadly, but in the URL I notice something about “reset runner registeration tokens”. I have no idea what runners are, so I find this article in the GitLab documentation. I can’t find the General pipelines settings (only a Continuous Integration and Deployment option in CI/CD), but I did find Admin Area -> Overview -> Runners … and get a 500 Internal Error in the GUI.

Then I find this StackOverflow link and follow the leading comments, perform it … and no errors! I go to the GitLab GUI and when I go to Admin Area -> Overview -> Runners … no error this time! Now I click the Reset runners registration token button. I’m … not sure this has helped me in any way (and probably what I did in Terminal was the same thing, yes?). In the Runners screen, it says " Install GitLab Runner" … so Runners aren’t even installed? Are they relevant?

Still getting the 500 error when I try to rename or delete projects. As per this issue, it looks like I need to find this General pipelines settings for resetting the runner registration token, which I’ve been unable to find. I also found another issue relating to the 500 error and “general pipeline settings timeout”, so I feel like I’m getting somewhere … I just have no idea what to try next.

Would you mind explaining what a Runner is? Is it important at all? Do I need to install GitLab Runner? What is the General Pipeline Settings and why do I need to set a Timeout?

EDIT: I think its in my best interest to see what the GitLab production log has to say:

root@gitlab:~# less /var/log/gitlab/gitlab-rails/production_json.log | grep error
{"method":"GET","path":"/admin/runners","format":"html","controller":"Admin::RunnersController","action":"index","status":500,"error":"ActionView::Template::Error: ","duration":121.42,"view":0.0,"db":7.32,"time":"2019-08-07T01:42:51.642Z","params":[],"remote_ip":"1.2.3.4","user_id":4,"username":"naupe","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0","queue_duration":null,"correlation_id":"hIca7O7LTW5"}
{"method":"GET","path":"/admin/runners","format":"html","controller":"Admin::RunnersController","action":"index","status":500,"error":"ActionView::Template::Error: ","duration":115.21,"view":0.0,"db":7.27,"time":"2019-08-07T01:42:54.503Z","params":[],"remote_ip":"1.2.3.4","user_id":4,"username":"naupe","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0","queue_duration":null,"correlation_id":"HAivIvWG7S8"}
{"method":"DELETE","path":"/eg-leaders/Leads_Repository","format":"html","controller":"ProjectsController","action":"destroy","status":500,"error":"OpenSSL::Cipher::CipherError: ","duration":31.56,"view":0.0,"db":3.37,"time":"2019-08-07T01:46:24.697Z","params":[{"key":"_method","value":"delete"},{"key":"authenticity_token","value":"[FILTERED]"},{"key":"projectName","value":"Leads_Repository"},{"key":"namespace_id","value":"eg-leaders"},{"key":"id","value":"Leads_Repository"}],"remote_ip":"1.2.3.4","user_id":4,"username":"naupe","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0","queue_duration":null,"correlation_id":"ydplROYmLt4"}
{"method":"DELETE","path":"/eg-leaders/Leads_Repository","format":"html","controller":"ProjectsController","action":"destroy","status":500,"error":"OpenSSL::Cipher::CipherError: ","duration":32.27,"view":0.0,"db":4.92,"time":"2019-08-07T02:00:16.685Z","params":[{"key":"_method","value":"delete"},{"key":"authenticity_token","value":"[FILTERED]"},{"key":"projectName","value":"Leads_Repository"},{"key":"namespace_id","value":"eg-leaders"},{"key":"id","value":"Leads_Repository"}],"remote_ip":"1.2.3.4","user_id":4,"username":"naupe","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0","queue_duration":null,"correlation_id":"4yrWRjCyXI5"}
{"method":"DELETE","path":"/eg-leaders/Leads_Repository","format":"html","controller":"ProjectsController","action":"destroy","status":500,"error":"OpenSSL::Cipher::CipherError: ","duration":32.77,"view":0.0,"db":4.88,"time":"2019-08-07T02:03:04.759Z","params":[{"key":"_method","value":"delete"},{"key":"authenticity_token","value":"[FILTERED]"},{"key":"projectName","value":"Leads_Repository"},{"key":"namespace_id","value":"eg-leaders"},{"key":"id","value":"Leads_Repository"}],"remote_ip":"1.2.3.4","user_id":4,"username":"naupe","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0","queue_duration":null,"correlation_id":"Ru1dgp3V2b1"}
{"method":"DELETE","path":"/EJH/death-screen","format":"html","controller":"ProjectsController","action":"destroy","status":500,"error":"OpenSSL::Cipher::CipherError: ","duration":32.42,"view":0.0,"db":4.69,"time":"2019-08-07T02:03:12.164Z","params":[{"key":"_method","value":"delete"},{"key":"authenticity_token","value":"[FILTERED]"},{"key":"projectName","value":"death-screen"},{"key":"namespace_id","value":"EJH"},{"key":"id","value":"death-screen"}],"remote_ip":"1.2.3.4","user_id":4,"username":"naupe","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0","queue_duration":null,"correlation_id":"3uELfUESUi9"}
{"method":"DELETE","path":"/EJH/death-screen","format":"html","controller":"ProjectsController","action":"destroy","status":500,"error":"OpenSSL::Cipher::CipherError: ","duration":30.03,"view":0.0,"db":3.35,"time":"2019-08-07T02:29:25.226Z","params":[{"key":"_method","value":"delete"},{"key":"authenticity_token","value":"[FILTERED]"},{"key":"projectName","value":"death-screen"},{"key":"namespace_id","value":"EJH"},{"key":"id","value":"death-screen"}],"remote_ip":"1.2.3.4","user_id":4,"username":"naupe","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0","queue_duration":null,"correlation_id":"Gz9Be9SwfY2"}
{"method":"DELETE","path":"/company-name/ProjectName","format":"html","controller":"ProjectsController","action":"destroy","status":500,"error":"OpenSSL::Cipher::CipherError: ","duration":36.17,"view":0.0,"db":5.5,"time":"2019-08-07T02:29:45.279Z","params":[{"key":"_method","value":"delete"},{"key":"authenticity_token","value":"[FILTERED]"},{"key":"projectName","value":"ProjectName"},{"key":"namespace_id","value":"epoch-games"},{"key":"id","value":"ProjectName"}],"remote_ip":"1.2.3.4","user_id":4,"username":"naupe","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0","queue_duration":null,"correlation_id":"S5mi1jkR1F1"}
{"method":"GET","path":"/company-name/ProjectName/settings/ci_cd","format":"html","controller":"Projects::Settings::CiCdController","action":"show","status":500,"error":"ActionView::Template::Error: ","duration":658.05,"view":0.0,"db":35.62,"time":"2019-08-07T02:30:27.939Z","params":[{"key":"namespace_id","value":"company-name"},{"key":"project_id","value":"ProjectName"}],"remote_ip":"1.2.3.4","user_id":4,"username":"naupe","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0","queue_duration":null,"gitaly_calls":1,"gitaly_duration":6.16,"correlation_id":"IaMsGvtXi07"}
{"method":"GET","path":"/company-name/ProjectName/settings/ci_cd","format":"html","controller":"Projects::Settings::CiCdController","action":"show","status":500,"error":"ActionView::Template::Error: ","duration":771.09,"view":0.0,"db":36.14,"time":"2019-08-07T02:30:39.404Z","params":[{"key":"namespace_id","value":"company-name"},{"key":"project_id","value":"ProjectName"}],"remote_ip":"1.2.3.4","user_id":4,"username":"naupe","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0","queue_duration":null,"gitaly_calls":1,"gitaly_duration":7.46,"correlation_id":"C5gWIR2wY96"}
{"method":"DELETE","path":"/EJH/death-screen","format":"html","controller":"ProjectsController","action":"destroy","status":500,"error":"OpenSSL::Cipher::CipherError: ","duration":30.94,"view":0.0,"db":3.34,"time":"2019-08-07T02:31:28.846Z","params":[{"key":"utf8","value":"✓"},{"key":"_method","value":"delete"},{"key":"authenticity_token","value":"[FILTERED]"},{"key":"namespace_id","value":"EJH"},{"key":"id","value":"death-screen"}],"remote_ip":"1.2.3.4","user_id":4,"username":"naupe","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0","queue_duration":null,"correlation_id":"crvA0uih4r1"}
{"method":"DELETE","path":"/EJH/death-screen","format":"html","controller":"ProjectsController","action":"destroy","status":500,"error":"OpenSSL::Cipher::CipherError: ","duration":32.06,"view":0.0,"db":5.31,"time":"2019-08-07T02:31:34.835Z","params":[{"key":"utf8","value":"✓"},{"key":"_method","value":"delete"},{"key":"authenticity_token","value":"[FILTERED]"},{"key":"namespace_id","value":"EJH"},{"key":"id","value":"death-screen"}],"remote_ip":"1.2.3.4","user_id":4,"username":"naupe","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0","queue_duration":null,"correlation_id":"wcWlJp5EiA"}
{"method":"DELETE","path":"/EJH/death-screen","format":"html","controller":"ProjectsController","action":"destroy","status":500,"error":"OpenSSL::Cipher::CipherError: ","duration":33.74,"view":0.0,"db":4.36,"time":"2019-08-07T02:32:47.818Z","params":[{"key":"utf8","value":"✓"},{"key":"_method","value":"delete"},{"key":"authenticity_token","value":"[FILTERED]"},{"key":"namespace_id","value":"EJH"},{"key":"id","value":"death-screen"}],"remote_ip":"1.2.3.4","user_id":4,"username":"naupe","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0","queue_duration":null,"correlation_id":"OAloisb56u"}

root@gitlab:~# less /var/log/gitlab/gitlab-rails/production.log | grep Error
Completed 500 Internal Server Error in 120ms (ActiveRecord: 7.3ms)
ActionView::Template::Error ():
Completed 500 Internal Server Error in 113ms (ActiveRecord: 7.3ms)
ActionView::Template::Error ():
Completed 500 Internal Server Error in 30ms (ActiveRecord: 3.4ms)
OpenSSL::Cipher::CipherError ():
Completed 500 Internal Server Error in 31ms (ActiveRecord: 4.9ms)
OpenSSL::Cipher::CipherError ():
Completed 500 Internal Server Error in 31ms (ActiveRecord: 4.9ms)
OpenSSL::Cipher::CipherError ():
Completed 500 Internal Server Error in 31ms (ActiveRecord: 4.7ms)
OpenSSL::Cipher::CipherError ():
OpenSSL::Cipher::CipherError ():
Completed 500 Internal Server Error in 28ms (ActiveRecord: 3.4ms)
OpenSSL::Cipher::CipherError ():
Completed 500 Internal Server Error in 34ms (ActiveRecord: 5.5ms)
OpenSSL::Cipher::CipherError ():
Completed 500 Internal Server Error in 654ms (ActiveRecord: 35.6ms)
ActionView::Template::Error ():
Completed 500 Internal Server Error in 769ms (ActiveRecord: 36.1ms)
ActionView::Template::Error ():
Completed 500 Internal Server Error in 29ms (ActiveRecord: 3.3ms)
OpenSSL::Cipher::CipherError ():
Completed 500 Internal Server Error in 30ms (ActiveRecord: 5.3ms)
OpenSSL::Cipher::CipherError ():
Completed 500 Internal Server Error in 32ms (ActiveRecord: 4.4ms)
OpenSSL::Cipher::CipherError ():

Does this shed any new light on the situation? I am seeing “runners” coming up. And what could this CipherError be?

(I have added generic “company”, “company-name”, “ProjectName”, “EJH” and “1.2.3.4” for privacy’s sake)

I didn’t find anything else in the other logs that seemed like it would be useful, but then I’ve just been grepping for combinations of “error” and “Error”.

EDIT 2: On the old GitLab Server, I notice the CI/CD Settings in it has:

  • General pipelines
  • Auto DevOps
  • Runners
  • Variables
  • Pipeline triggers

As mentioned before, in the new GitLab I could only find Continuous Integration and Deployment option for CI/CD of projects’ settings.

@gitlab-greg Anymore suggestions for me to try?

@gitlab-greg So I solved the issue of deleting and renaming projects. I posted the Issue here on GitLab.com and got some very quick feedback. All I had to do was follow the steps under When the secrets file is lost and now I get no more errors when deleting or renaming projects.

There is still the major problem of importing the project: I tried again last night to import through the GUI, and not everything was pulled:

  • Old/Live GitLab: 20 GB ( 403.1 MB repository, 0 Bytes build artifacts, 19.6 GB LFS )
  • New GitLab: 19 GB ( 0 Bytes repository, 0 Bytes build artifacts, 19 GB LFS )

I also tried importing through API in Terminal, but I don’t think I’m getting the file= part correct … not sure what I’m supposed to put to be honest:

root@gitlab:~# curl --request POST --header "PRIVATE-TOKEN: <my_api_sudo_access_token>" --form "path=company-name" --form "file=@gitlab.domainname.cpm/company-name/Project.git" https://gitlab.domainname.com/api/v4/projects/import
Warning: setting file gitlab.domainname.com/company-name/Project.git
Warning: failed!
curl: (26) read function returned funny value

I realize that even if I still get the full contents of the project, it may not include the current Issues, User Accounts and the Slack Integration I have set with the Live GitLab. A full backup of the Live GitLab and restore to the New GitLab is probably the best solution … but I want to know:

  1. Is there a way to backup and restore the Live GitLab in the New GitLab environment without the restore touching the /etc/gitlab/gitlab.rb ?
  2. Is there a way to backup and restore the Live GitLab in the New GitLab environment without the restore touching the CI/CD variables and Runner registration tokens that I just fixed?

@gitlab-greg @gregorip Everything was going good … and now everything is real bad. Long story short: I currently have until this Monday to get the Project and Issues from my Live GitLab to somewhere else (server host isn’t giving me a choice)! I also no longer have terminal access to my Live GitLab (I can no longer access the Terminal whatsoever!).

I really need to know:

  1. Is there any way I can export the Issues? The “Export as CSV” button does not exist in my GitLab … but then I think I remember reading elsewhere that this is an Enterprise-only feature? If so, is there any way I can get the Issues off a project in my Live GitLab?
  2. Is there any suggestions on Third-Party Cloud Git Repositories I could upload a 20 GB project to? I’ve tried importing to GitLab.com, but its only imported 503 MB (I assume the free version has some kind of Project Upload Limit?).

I do have a local copy of my project on my Home Machine if I lose access. I would ask if I could import my User List, but that’s the least of my worries.