Skip to content

Technical

3-2-1 Backup Rule: Does Your Data Exist in 3 Places?

Have you heard of the 3-2-1 backup rule? The idea is simple but powerful: if your data doesn't exist in at least 3 places, it doesn't really exist. More specifically, the rule says:

  • 3 copies of your data
  • 2 different storage media (e.g., local disk + cloud)
  • 1 copy stored off-site

It's a well-established baseline in the industry, and some organizations even extend it to a 3-2-1-1-0 model — adding one immutable or air-gapped copy and zero unverified backups. Despite how long this rule has been around, a surprising number of people (and teams) still don't follow it.

This week's (2026-05-12) chat we want to talk about backup habits — at home, at work, for your personal projects, wherever. Some discussion starters:

  • Do devs take better care of their data and have better backup habits than non-devs? Or does knowing how things work make us more complacent ("the cloud handles it")?
  • Do you have your own system for protecting your data? What does it look like in practice?
  • Any nightmares or lessons learned the hard way?

Everyone and anyone is welcome to join as long as you are kind, supportive, and respectful of others. Zoom link will be posted at 12pm MDT.

3-2-1 Backup Rule

What's happening with GitHub.

GitHub had quite a time last month:

April 23 (Merge Queue incident): A regression in the merge queue (especially with squash merges involving multiple PRs) caused incorrect merge commits. It affected 658 repositories and 2,092 pull requests. Changes from earlier merges were inadvertently reverted in some cases. No data loss occurred (commits were still in Git), but default branches ended up in inconsistent states for some repos. GitHub couldn’t auto-fix everything safely.

April 27 (Elasticsearch/search incident): The Elasticsearch cluster (used for search in PRs, issues, projects, etc.) became overloaded—likely from a botnet attack—and stopped returning results. This disrupted UI search features for several hours but didn’t affect core Git operations or APIs.

Others have commented on their recent decline (see chart below). Do you still trust them? Are you sticking with them, or exploring alternatives? Don’t forget... GitHub isn’t Git 😉 .

Everyone and anyone are welcome to join as long as you are kind, supportive, and respectful of others. Zoom link will be posted at 12pm MDT.

alt text

How Deep Should You Go?

Today’s chat (2026-04-21) we’ll talk about this ongoing debate between what you should know as a developer.

One side says: “Every programmer should learn C. Implement a linked list, hash table, and binary tree. Then build a simple CLI program and a basic network server. Not because you’ll use it daily, but because it strips away every abstraction you’ve been hiding behind and shows you what’s really beneath whatever language you use daily.”

Another side responds: “Every C programmer should write assembler. Every assembler programmer should write machine code. Every machine code programmer should design a chip. Every chip designer should work on a Turing ticker tape machine. Learn what you need for the level you work at. And a bit of what’s further down and further up the stack. For most people, linked lists are further down the stack than they need to venture.”

Who’s right? What has worked for you personally?

Everyone and anyone is welcome to join as long as you are kind, supportive, and respectful of others.

Close-up of ticker tape