Weeks ago, the world watched helplessly as he Notre Dame Cathedral, burned. While this event was notable for many reasons, one of the things that struck us here at Technically Religious was the protocol used by emergency responders: Save the people, save the art, save the altar, save what furniture you can, then focus on the structure, in that order. We know what can be rebuilt and what can't.” In this episode, Josh and Leon compare and contrast that disaster recovery process to the ones typically used in IT. Listen or read the transcript below.

Leon: 00:00 Hey everyone. It's Leon. Before we start this episode, I wanted to let you know about a book I wrote. It's called "The Four Questions Every Monitoring Engineer is Asked", and if you like this podcast, you're going to love this book. It combines 30 years of insight into the world of IT with wisdom gleaned from Torah, Talmud, and Passover. You can read more about it, including where you can get a digital or print copy over on adatosystems.com. Thanks!

Leon: 00:25 Welcome to our podcast where we talk about the interesting, frustrating, and inspiring experiences we have as people with strongly held religious views working in corporate IT. We're not here to preach or teach you our religion. We're here to explore ways we make our career as IT professionals mesh - or at least not conflict - with our religious life. This is Technically Religious.

Josh: 00:45 A few weeks ago, the world watched helplessly as one of the iconic buildings in Paris, the Notre Dame cathedral burned. While this event was notable for many reasons. One of the things that struck us here at Technically Religious was a response by one of the bystanders, who understood what was happening on the ground. He said,

Leon: 01:04 "The fire department in Paris followed a protocol. Save the people, save the art, save the altar, save what furniture you can, then focus on the structure. In that order. They know what can be rebuilt and what can't."

Josh: 01:17 Now that smacks of a disaster recovery policy to us. But I think we in IT might look at it differently. Which is what we're going to do in this episode. Joining in the discussion with me today is Leon Adato.

Leon: 01:31 Hi everyone. And of course, the other voice that you're hearing is Josh Biggley.

Josh: 01:35 Hello. Hello.

Leon: 01:36 Okay, so I think the first thing, because we're talking about disaster recovery, is let's get our terms. Let's define our data library and differentiate between redundancy, high availability, disaster recovery, risk mitigation, all those things. So do you wanna take a crack at it? Do you want to just collaboratively? Do this?

Josh: 01:58 I love redundancy. And in this world of cloud, I think redundancy is the thing that we do really well now because you know, you can set up a system that is in two regions and so if one of your regions fails here, the region will pickup, you can do a multisite region. Redundancy to me feels like a descriptor that actually bridges across HA and DR and risk mitigation. Um, yeah, redundancy feels like a catchall term, right? It's not something you can achieve. I don't know. What do you think, Leon?

Leon: 02:36 All right. All right. So I think redundancy at its simplest is "there's another one of them." There's another

Josh: 02:42 Oh, like RAID

Leon: 02:43 Yeah. Okay. Right. There's like RAID, you know, having multiple disks - RAID 0 - which is just having two discs, one backing up the other constantly. Or RAID 5... any of the other flavors of raid. So I think redundancy means "having more than one" and yes, redundancy can fit into a high availability plan. But high availability is more nuanced. High availability means that no matter what happens, the "thing" - the service, or the the network, or whatever, is going to be available. That can also be done by doing load balancing. It can also be done by, you know, in networking terms, channel bonding, so you can have those. So redundancy by itself