I was responsible for administering a self hosted GitLab instance for a medium sized company and our backups never required downtime. The built in backup command doesn't require downtime but also isn't a consistent point in time snapshot (specifically because the instance keeps running while the backup is being taken). If they've decided they need one for some reason, stopping GitLab is certainly the easiest way, but not the only way of accomplishing that goal, but that'll be true of any self-hosted forge, including GitHub.
replyYou could stop it, do a snapshot of the storage and backup that for <1 min of downtime probably.
replyBut at the same time, if you're not a global company, doing it at 3am is probably fine.
Doing a snapshot of the storage while it's running wouldn't be bad either, it'd just be like having cut power at the point of the snapshot, right?
replyYes. And the database used by GitLab is Postgres which handles that just fine.
replyIt can be an issue if you are using gitlab as your container/package registry and production workloads need to pull from it, though.
replyThey should be pulling from a pull through scanning repository cache anyway, so they can be scanned before going into production.
replyWeird. I’ve been on a self hosted enterprise gitlab and I think we’ve have only one or two performance degradations/outages in the past 6 years
replyWe’re talking about the SaaS version, not self-hosted.
replyAre you sure?
reply> [...] and FWIW our *self-hosted* premium gitlab has about an hour a day downtime
AND
reply