Live data from Hacker News

Data Loss at GitLab

blog.2ndquadrant.com

151–160 of 236 posts

Re: Data Loss at GitLab

#151

Earlier quoted context omitted.

HN can be funny sometimes. GitHub got a lot of hate about a year ago just for not releasing new features. GitLab cost everyone a day because their backup/ops practices were silly, and everyone loves them more. I've screwed up before, and I sympathize/empathize with their ops folks, but this should make us think about plan B in case something like this happens again.

> GitLab cost everyone a day GitLab isn't popular because of the stability of its cloud platform. It's popular because you can install your own instance for free practically anywhere with minimal effort. I run GitLab CE on a box in my server closet for projects that involve livelihoods.

You can also look at RhodeCode CE - supports git/mercurial/svn and has a really nice installer you can use to keep things up to date.

Re: Data Loss at GitLab

#152

With this incident, they once again showed that they are dedicated to transparency, even in the worst days. This increased their popularity on me and I believe among other developers. However, this may not be the case with the business people. I hope they can survive that and also publish a guide for getting better at the "ops" side of the things.

HN can be funny sometimes. GitHub got a lot of hate about a year ago just for not releasing new features. GitLab cost everyone a day because their backup/ops practices were silly, and everyone loves them more. I've screwed up before, and I sympathize/empathize with their ops folks, but this should make us think about plan B in case something like this happens again.

>GitLab cost everyone a day

That's just nonsense. In most cases, the local repo should be more than enough to continue work.

Re: Data Loss at GitLab

#153
post #121

Earlier quoted context omitted.

>It's popular because you can install your own instance for free practically anywhere with minimal effort. If that is the reason why you use Gitlab, then why not try gitea or gogs? gogs is written in Go and provides a docker image or a drop in binary

Gogs is pretty sweet. After hearing about it here I installed it on my old home server with constrained memory because I couldn't meet Gitlab's (IMO) obscene memory requirements. It's perfect for my needs as a hobbyist and I even use it as a secondary Git server from work. It's also way, way faster than a self-hosted Gitlab or any public Git server, so even though my current server has more than enough memory to run…

It might be related to git and not Gogs/Gitea itself.

I've found Gitea to handle larger repos fine after running the following:

  git config --global core.packedGitWindowSize 16m
  git config --global core.packedGitLimit 64m
  git config --global pack.windowMemory 64m
  git config --global pack.packSizeLimit 64m
  git config --global pack.thread 1
  git config --global pack.deltaCacheSize 1m
This reduces the memory used by git during certain operations.

Re: Data Loss at GitLab

#154
How can a "company" with more than 150 employees, (That is essentially, a data storage company) let this happen?

GitLab is surely losing subscribers faster than land in Crimea after this...

Re: Data Loss at GitLab

#155

Earlier quoted context omitted.

I think you might be confused. One of the nice things to happen to OSS was the availability of kernel ( Linux kernel that is ) and git ( ... ) and both set very open models which allowed the OSS to trive. Github allowed for using git without knowing it .

I think you might be confused. One of the nice things to happen to OSS was the availability of transistors and electricity. Both made it possible to make millions of logic calculations per second without knowing it. :)

I think you might be confused. One of the nice things to happen to OSS was the availability of human beings to actually develop the concept of OSS and any underlying technology.

Re: Data Loss at GitLab

#156

Earlier quoted context omitted.

HN can be funny sometimes. GitHub got a lot of hate about a year ago just for not releasing new features. GitLab cost everyone a day because their backup/ops practices were silly, and everyone loves them more. I've screwed up before, and I sympathize/empathize with their ops folks, but this should make us think about plan B in case something like this happens again.

>GitLab cost everyone a day That's just nonsense. In most cases, the local repo should be more than enough to continue work.

Yeah, kind of defeats the whole D part of DVCS when you centrally-host everything. GitHub is great for creating an open-source watering hole and becoming a de-facto standard for open source project hosting, but bad for mission-critical stuff if you're relying on something like that to be 100% available, especially when using a technology which is designed to be distributed.

Re: Data Loss at GitLab

#157

Earlier quoted context omitted.

HN can be funny sometimes. GitHub got a lot of hate about a year ago just for not releasing new features. GitLab cost everyone a day because their backup/ops practices were silly, and everyone loves them more. I've screwed up before, and I sympathize/empathize with their ops folks, but this should make us think about plan B in case something like this happens again.

There's another reasonable takeaway: GitLab will probably now prepare for this sort of thing better than the average competitor who hasn't been bitten by this.

We'll certainly learn from this, post-mortem write-up issue is in https://gitlab.com/gitlab-com/www-gitlab-com/issues/1108

Re: Data Loss at GitLab

#158

With this incident, they once again showed that they are dedicated to transparency, even in the worst days. This increased their popularity on me and I believe among other developers. However, this may not be the case with the business people. I hope they can survive that and also publish a guide for getting better at the "ops" side of the things.

I am sick of the "They are transparent so it's ok" argument. The fact is this type of thing should not happen anymore.. I get it, stuff fails but it's not acceptable to lose production data at this scale and save face by being transparent. That was ok back in 2003.. Not anymore.

Compare with Github and their 98.935% uptime over the past month: https://status.github.com/graphs/past_month

Neither should be exclusively relied upon for business-critical services. Ask Github about their production backups and DR plans some time.

Re: Data Loss at GitLab

#159

Honestly, I'm completely flabbergasted by this. Five backups, and NONE worked properly? Who made this? The S3 bucket was EMPTY? Has no one ever tested any of these backups? It's not just the impact, which is fairly sizeable in it's own right, but it's the HUGE oversight on their part and the fact they tried to pin part of this on PostreSQL? Credit where it's due; their report/transparency were good if a little unprof…

I agree. Their catastrophe is not the kind of thing that represents mild hiccups in operations that will be quickly resolved by the same employees who allowed this scenario to occur the first time around. This isn't the result of a single oversight. It screams of a systemic problem with the way the business operates - period. Maybe every project is rushed out with the deadline being the only metric that counts, quali…

I totally agree with needing an experienced DBA, we've had a vacancy open for this for a while https://about.gitlab.com/jobs/specialist/database/

Re: Data Loss at GitLab

#160

How can a "company" with more than 150 employees, (That is essentially, a data storage company) let this happen? GitLab is surely losing subscribers faster than land in Crimea after this...

Incident upon incident followed by a mistake under pressure late at night.

--it happens. I suspect the the guy responsible for the final straw is feeling pretty bad. I know I've come close to doing similar things on production environments I really didn't want to be touching while they were falling apart.

But they've been honest about it. If they learn from it and six hours of database data is the worst data loss they ever experience I think it'll be a credit to them that they've been promptly transparent.

Post reply on HN