Slashdot Mirror
GitLab Says It Found Lost Data On a Staging Server (theregister.co.uk)
GitLab.com, the wannabe GitHub alternative that went down hard earlier this week and reported data loss, has said that some data is gone but that its services are now operational again. From a report The Register: The incident did not result in Git repos disappearing. Which may be why the company's PR reps characterised the lost data as "peripheral metadata that was written during a 6-hour window". But in a prose account of the incident, GitLab says "issues, merge requests, users, comments, snippets, etc" were lost. The Register imagines many developers may not be entirely happy with those data types being considered peripheral to their efforts. GitLab's PR flaks added that the incident impacted "less than 1% of our user base." But the firm's incident log says 707 users have lost data. The startup, which has raised over $25 million, added that it lost six hours of data and asserted that the lost doesn't include users' code.
GitLab is actually quite good at it, really.
1. You can get all the wiki and code repo data by git cloning into a backup repository.
2. You can set up a remote mirror that gets automatically updated for the code. I don't think you can do that for the wiki, though.
3. Project admins can download a metadata dump to import in some other gitlab instance (e.g. a local instance of gitlab CE (floss) or EE (paid):
The following items will be exported:
Project and wiki repositories
Project uploads
Project configuration including web hooks and services
Issues with comments, merge requests with diffs and comments, labels, milestones, snippets, and other project entities
4. The data which is not exported (LFS objects, build traces and artifacts, container registry images) can be downloaded in some other way. E.g. LFS is usually cloned along with the git code repos.
Note that (3) **includes** the webhooks data that was not fully recovered.
So, yeah, anyone who lost truly important data in this gitlab.com event was actually just as guilty of not following the "Tao of Backup" properly as gitlab.com's sysadmins.
A "github clone" which comes with a CE edition which is FLOSS, and an EE edition, for either zero-cost (CE edition), or just $ (EE edition). And in both cases, you can have your own on-premises. github would be $$$, and I don't think it does on-premises (but even if it does, it is a lot more expensive).
It is also vastly preferred over github by anyone with small teams. It didn't get into fortune-500 by chance, nor did it get US$ 25M in funding by chance.
But yes, if you hate github's usability or flows, there is no reason to believe you wouldn't hate gitlab as well. They are *not* the same, but they're close enough.
Being it a Git repository, you don't have to worry too much about your "centralized" hosting provider – Each developer that has cloned a (non-shallow) repository will locally have everything needed to rebuild history were both providers to disappear. Git is a great backup strategy by itself :-)