GitLab Database Incident – Live Report

Post by problems » Wed, Feb 01, 2017, 2:46 AM UTC

ChuckMcM wrote: post #68

btgeekboy wrote: post #62

> Our backups to S3 apparently don’t work either: the bucket is empty followed by > So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place. is no way to be running a public service with customer data. Did the person who set up that S3 job simply write a script or something and just go "yep, it's done" and walk away? Seriously?

> Did the person who set up that S3 job simply write a > script or something and just go "yep, it's done" and > walk away? I don't know of course, but one failure mode that has to be explicitly tested for is continual monitoring that the existing backup process is still working. We had a backup process at Blekko which stopped working once when an S3 credential that appeared unrelated was removed, as I recall it was a…

Post by hobarrera » Wed, Feb 01, 2017, 2:51 AM UTC

gizmo wrote: post #19

This is painful to read. It's easy to say that they they should have tested their backups better, and so on, but there is another lesson here, one that's far more important and easily missed. When doing something really critical (such as playing with the master database late at night) ALWAYS work with a checklist. Write down WHAT you are going to do, and if possible, talk to a coworker about it so you can vocalize th…

Post by hobarrera » Wed, Feb 01, 2017, 2:53 AM UTC

shawn-furyan wrote: post #123

piinbinary wrote: post #46

Earlier quoted context omitted.

Or use `mv x x.bak` when `rmdir` fails

Or even instead of any kind of rm command. mv is less subtle. I tend to prefer `mv x $(date +%Y%m%d_%s_)x` where: %Y - 4 digit year %m - 2 digit month %d - 2 digit day _ - underscore literal %s - linux timestamp (seconds since epoch) This ensures that the versions you're 'removing' will be lexically sorted from newest to oldest in a way that is easy to interpret and also works if you need to try more than once in a d…

Post by FireBeyond » Wed, Feb 01, 2017, 2:57 AM UTC

click170 wrote: post #75

gizmo wrote: post #19

This is painful to read. It's easy to say that they they should have tested their backups better, and so on, but there is another lesson here, one that's far more important and easily missed. When doing something really critical (such as playing with the master database late at night) ALWAYS work with a checklist. Write down WHAT you are going to do, and if possible, talk to a coworker about it so you can vocalize th…

BBC's Horizon has a really good episode about checklists and how they're used to prevent mistakes in hospitals, and how they're being adopted in other environments in light of that success. It's called How To Avoid Mistakes In Surgery for the interested.

Post by verytrivial » Wed, Feb 01, 2017, 2:58 AM UTC

nowarninglabel wrote: post #83

gizmo wrote: post #19

This is painful to read. It's easy to say that they they should have tested their backups better, and so on, but there is another lesson here, one that's far more important and easily missed. When doing something really critical (such as playing with the master database late at night) ALWAYS work with a checklist. Write down WHAT you are going to do, and if possible, talk to a coworker about it so you can vocalize th…

Yes, good tip from "Turn the Ship Around" by David Marquet is to use the "I intend to" model. For every action you are going to undertake that is critical, first announce your intentions and give enough time for reactions from others before following through.