3 ms·
More fairly to GitLab it was the underlying server that broke initially. The issue from there was that I couldn't restore from the backup as the newly installed
by corobo 5y ago
More fairly to GitLab it was the underlying server that broke initially. The issue from there was that I couldn't restore from the backup as the newly installed server was also a newer version of GitLab
Tried restoring it to the older version to run through the upgrade path and the process didn't want to work. Wish I could be more specific here but I gave up on it and decided it'd just be quicker to whip up a script to recreate all the groups/projects/CICD in a new install and push repos from backups
Don't let your GitLab server get outdated and don't consider it a valid backup unless it was taken with the latest version to avoid the same
Also it wasn't relevant here but make sure you're backing up the etc files too, while that wasn't an issue for me it could easily trip you over in a worst case scenario ( https://docs.gitlab.com/charts/backup-restore/backup.html#backup-the-secrets https://docs.gitlab.com/charts/backup-restore/backup.html#ba... )
Not a complaint, it's just one of the hats that needs wearing sometimes, would have been easier on me if someone else was handling it though :P
- ashildr 5y agoThank you. From what I know direct updates to the next major releases of gitlab are only supported from relatively recent releases. I guess that’s what caught you. We’ve been updating about as soon as an update is released for a while now, with very good results. (I’d rather have to restore a backup or a snapshot than to be running without the latest security fixes. If gitlab is down for an hour (didn’t happen in ~3 years) at least all developers have their local repo.)