*I am running a dockerized gitlab and need to move it to a hosted server OR i need to update dockerized gitlab to the last version without lost any data.
When i make a backup from docker gitlab, i can’t restore this backup into a new hosted server. I think there’s not possible because a different docker style (docker-hosted server)
Can someone give an option to update my gitlab 15.9.3 to the latest version. Step by Step for docker, or if i can do it to a hosted server will be very usefull for my company.
I have no experience with dockerized GitLab. But I believe I’ve seen people talk about using the same tools for backup/restore as is used on omnibus installations. So the generated backup should look similar.
Can you say what commands you use to take a backup, and restore it on the new machine, and what error (just give the full output) you get when trying to restore it on the new server.
Hi @grove Thanks for answer.
I take the backup with : docker exec -it gitlab gitlab-rake gitlab:backup:create
Then i move the backup to the new hosted server and execute this command gitlab-rake gitlab:backup:restore BACKUP=XXXXXXXXX
And the output is:
2023-07-05 12:53:42 UTC – Unpacking backup …
tar: Unexpected EOF in archive
tar: rmtlseek not stopped at a record boundary
tar: Error is not recoverable: exiting now
2023-07-05 12:54:07 UTC – Unpacking backup failed
2023-07-05 12:54:07 +0000 – Deleting backup and restore lock file
I believe that the dockerized backup is marked for docker version, and can´t be used for a non-docker version, but i need it works
EDIT: i tried this too. gitlab-backup restore BACKUP=1687964137_2023_06_28_15.9.3
gitlab-backup is mostly just a wrapper around gitlab-rake gitlab:backup: so it’s not surprising that you get the same result from both commands.
I don’t think that rake task detects that it’s dockerized, and therefor the resulting backup won’t a specific for dockerized versions anyway.
The error you get suggests that the tarball containing the backup is corrupted (and nothing about docker vs. non-docker). I can’t see from that if it has been bad from taking the backup or if it’s the move that has done it. In any case you can’t use the corrupted file, you can test a backup/recreate the error with something like tar tf <backup-file> (we make our backups with SKIP=tar so the creation of that file is not done, so I can’t see what the files are called).
Thanks again, i will try to make a new backup. Is there a command to check if the backup is good or not?
Can i check it before moving to the new server?
I try to move it by scp command, and winscp program but have the same output, so i presume that the .tar never end the copy right?
The tar tf ... command I mentioned can partially verify a backup (and will catch this kind of error) and can be used both before and after the move, and only requires tar which is pretty standard (I don’t remember seeing a machine without it).