1 00:00:00,000 --> 00:00:04,109 This week, we're talking about one of the most fundamental technologies 2 00:00:04,140 --> 00:00:08,700 underpinning today's data protection systems and that's replication. 3 00:00:09,059 --> 00:00:09,719 What is it? 4 00:00:09,750 --> 00:00:11,580 How is it different than other methods? 5 00:00:11,850 --> 00:00:14,820 And if it's so great, why don't we just use it for everything? 6 00:00:15,120 --> 00:00:18,960 And of course what's the difference between synchronous and asynchronous. 7 00:00:18,960 --> 00:00:20,099 And why does that matter? 8 00:00:20,520 --> 00:00:21,570 Hi, I'm W. 9 00:00:21,570 --> 00:00:23,130 Curtis Preston AKA Mr. 10 00:00:23,130 --> 00:00:23,669 Backup. 11 00:00:23,970 --> 00:00:27,689 And I've dedicated my 30 year career to helping people like you keep your data 12 00:00:27,689 --> 00:00:29,759 safe from all that would do it harm. 13 00:00:30,030 --> 00:00:32,009 This is the backup wrap-up. 14 00:00:52,539 --> 00:00:56,959 Welcome to the show with me, as always, as a guy who seems to never 15 00:00:56,959 --> 00:00:59,339 be happy until I have problems. 16 00:01:00,189 --> 00:01:01,799 Prasanna Malayandi. 17 00:01:01,809 --> 00:01:01,959 How's 18 00:01:01,969 --> 00:01:02,619 I'm good. 19 00:01:02,619 --> 00:01:06,479 I'm just trying to think what problems do you have right now? 20 00:01:08,089 --> 00:01:12,519 Talking about, I'm trying to edit the podcast and you're giving 21 00:01:12,519 --> 00:01:14,639 me problems about my network. 22 00:01:14,872 --> 00:01:15,122 That's, 23 00:01:15,122 --> 00:01:16,092 what I'm talking about. 24 00:01:16,132 --> 00:01:16,902 yeah, it's. 25 00:01:17,742 --> 00:01:19,970 What I do, you need someone to ask the hard questions, 26 00:01:19,994 --> 00:01:21,154 Somebody's got to do it. 27 00:01:21,204 --> 00:01:22,494 The network's going all right. 28 00:01:22,544 --> 00:01:25,064 Those that have followed, I do have this new tool. 29 00:01:25,064 --> 00:01:28,024 I have, um, the, uh, Firewalla. 30 00:01:28,483 --> 00:01:32,743 version 125 of Curtis's home network, architecture. 31 00:01:33,788 --> 00:01:34,298 Yeah. 32 00:01:34,438 --> 00:01:37,388 but I now have this Firewalla that gives me a lot more 33 00:01:37,388 --> 00:01:38,748 information than I had before. 34 00:01:39,398 --> 00:01:44,668 And unfortunately it verified, my new ISPs, thing that I use too 35 00:01:44,668 --> 00:01:46,198 much internet and I have to buy. 36 00:01:46,753 --> 00:01:50,913 the unlimited package, which is sad because it's another 50 bucks a month. 37 00:01:50,953 --> 00:01:55,283 But anyway, so let's get to the news of the week 38 00:02:03,306 --> 00:02:05,826 I'm going to let you take the first story, uh, 39 00:02:05,856 --> 00:02:10,436 Yeah, yeah, yeah, so the first one is an article that came out recently. 40 00:02:10,746 --> 00:02:14,876 it is about a backup compa I guess, would you call them backup or data 41 00:02:14,876 --> 00:02:19,866 protection company that recently, Raised around a funding, it's called Alcion. 42 00:02:20,651 --> 00:02:24,381 I actually used to work with the founder previously at an old job. 43 00:02:24,961 --> 00:02:29,731 and they actually raised a round of funding and it was actually led by 44 00:02:29,751 --> 00:02:35,461 Veeam, which is interesting because Veeam, as we all know, is also a backup 45 00:02:35,731 --> 00:02:41,406 company and they are investing in Alcion, who is primarily targeting backups 46 00:02:41,416 --> 00:02:45,596 for Microsoft 365 for SMB customers. 47 00:02:45,780 --> 00:02:46,280 today? 48 00:02:46,280 --> 00:02:48,650 That's their initial target market. 49 00:02:49,040 --> 00:02:52,120 I'd say that the biggest difference between the two companies, 50 00:02:52,330 --> 00:02:56,510 one is a software product, the other is a SaaS offering, and 51 00:02:56,600 --> 00:02:58,440 that makes them very different. 52 00:02:58,840 --> 00:03:02,830 And I guess Veeam felt that it was different enough. 53 00:03:03,110 --> 00:03:05,020 I like the quote in the article. 54 00:03:05,110 --> 00:03:08,790 It said something along the lines of that, that from Veeam, that 55 00:03:08,990 --> 00:03:12,570 this problem of ransomware is a big enough problem that we're going to 56 00:03:12,570 --> 00:03:14,110 need the whole industry to solve it. 57 00:03:14,120 --> 00:03:16,040 And so they invested in what. 58 00:03:16,355 --> 00:03:19,655 is essentially, I would call it a partial competitor, right? 59 00:03:19,655 --> 00:03:25,235 They do compete for the Microsoft 365 space, I also know the founder as 60 00:03:25,235 --> 00:03:30,325 well, and, I think they've taken an interesting angle with a very AI based 61 00:03:30,325 --> 00:03:32,385 approach, a very security based approach, 62 00:03:32,745 --> 00:03:32,935 Yeah. 63 00:03:32,935 --> 00:03:36,765 And one of the things that I'm actually looking forward to is seeing if this 64 00:03:36,775 --> 00:03:41,695 is going to force other vendors to reconsider how they approach the problem. 65 00:03:42,015 --> 00:03:42,445 And. 66 00:03:43,060 --> 00:03:46,820 Everyone in all the vendors raise a bar when it comes to ransomware 67 00:03:46,820 --> 00:03:51,070 protection and detection and other things like that, which we all 68 00:03:51,070 --> 00:03:51,390 need. 69 00:03:51,460 --> 00:03:51,770 Right? 70 00:03:52,171 --> 00:03:55,231 Anybody that's listened to this show knows that we're concerned about that problem. 71 00:03:55,711 --> 00:04:00,191 my second news story, it's from the enterprise strategy group, which for 72 00:04:00,491 --> 00:04:03,931 those of you that have known ESG for a while, they were, A few years ago, 73 00:04:03,931 --> 00:04:10,681 acquired by TechTarget, and there was a, 2023 survey of IT professionals. 74 00:04:11,541 --> 00:04:16,221 The most interesting number that I see here is that they said 65 percent 75 00:04:16,231 --> 00:04:21,571 of the almost 400 respondents said their organization were using some 76 00:04:21,571 --> 00:04:24,441 sort of cloud based, backup system. 77 00:04:24,901 --> 00:04:28,511 And the way they worded it, that could be either a cloud based 78 00:04:28,511 --> 00:04:32,551 service or they're storing a copy of their backups in the cloud. 79 00:04:33,121 --> 00:04:40,731 That, to me, really, that's a very different number, wouldn't you say, than 80 00:04:41,471 --> 00:04:41,791 a few years 81 00:04:42,046 --> 00:04:44,806 Yeah, everyone would be like, I don't trust my data in the cloud. 82 00:04:44,816 --> 00:04:48,496 How do I get my data up into the cloud and bring it back and all the rest of that? 83 00:04:48,676 --> 00:04:50,786 In fact, I think one of the interesting things was even just 84 00:04:50,786 --> 00:04:52,366 the title of the article, right? 85 00:04:52,366 --> 00:04:56,476 It's like cloud backup and disaster recovery evolved toward maturity. 86 00:04:56,896 --> 00:04:59,476 You know, that just kind of says it all, right, versus before you're 87 00:04:59,546 --> 00:05:04,836 fighting tooth and nail with customers, trying to persuade them, Hey, it's 88 00:05:04,836 --> 00:05:06,806 okay to store your data in the cloud. 89 00:05:06,976 --> 00:05:07,406 But 90 00:05:07,611 --> 00:05:13,471 Yeah, so the not so good number was saying that half of the surveyed orgs 91 00:05:13,811 --> 00:05:19,461 recovered 75 percent or less of their cloud data per incident on average. 92 00:05:19,811 --> 00:05:21,431 That sounds really bad. 93 00:05:21,781 --> 00:05:25,991 that is not, I agree with, Christoph Bertrand, which said that's just 94 00:05:25,991 --> 00:05:28,511 not acceptable for, such a mission 95 00:05:28,616 --> 00:05:33,266 I guess the question I would have is, it would be, we probably need 96 00:05:33,276 --> 00:05:38,246 to compare that to what's your recovery rate of on premises backups, 97 00:05:38,246 --> 00:05:39,656 because that's not going to be 100%. 98 00:05:40,481 --> 00:05:44,511 and then I think it's also not fair to compare it because how 99 00:05:44,521 --> 00:05:49,061 long has traditional backups, been around and had time to evolve 100 00:05:49,071 --> 00:05:50,711 versus cloud backups, right? 101 00:05:51,481 --> 00:05:54,681 It hasn't had that time to evolve and mature. 102 00:05:55,211 --> 00:05:57,131 Fully as these other products 103 00:05:57,495 --> 00:06:03,195 Yeah, I would say that part, having formerly worked at a cloud data protection 104 00:06:03,195 --> 00:06:09,205 vendor, I would think that the problem that I see with this number is that they 105 00:06:09,205 --> 00:06:14,195 do conflate people storing backups in the cloud versus people using a cloud service. 106 00:06:14,715 --> 00:06:17,115 I would be very surprised to learn that. 107 00:06:17,370 --> 00:06:22,210 People that are using a fully cloud based service, if they, if their recovery's 108 00:06:22,210 --> 00:06:28,460 failed, because the other, it's really, the cloud just happens to be a part of it. 109 00:06:28,870 --> 00:06:33,340 All of the same sort of misconfiguration problems that lead to problems 110 00:06:33,340 --> 00:06:37,679 with traditional backup are going to bleed over into a cloud. 111 00:06:39,000 --> 00:06:40,410 Just because you're using cloud 112 00:06:40,615 --> 00:06:41,595 but it's the cloud. 113 00:06:41,595 --> 00:06:42,255 It's magical. 114 00:06:42,265 --> 00:06:43,155 Come on Curtis. 115 00:06:44,145 --> 00:06:44,305 Yeah 116 00:06:46,720 --> 00:06:49,000 Yeah, it is magic. 117 00:06:49,060 --> 00:06:53,000 the one other interesting number from this survey, and there were 118 00:06:53,000 --> 00:06:56,640 some other interesting numbers, but just for brevity purposes, this other 119 00:06:56,640 --> 00:07:02,990 interesting number, they said 16 percent of the, respondents said that they. 120 00:07:03,525 --> 00:07:08,485 reviewed their, their cloud data protection strategies annually. 121 00:07:08,865 --> 00:07:13,315 that is, that's a very different number than back in the day. 122 00:07:13,325 --> 00:07:17,185 Back in the day, that number was like five years, maybe three years. 123 00:07:17,505 --> 00:07:18,845 Certainly not annually. 124 00:07:18,855 --> 00:07:23,075 Backup historically has been an incredibly sticky process. 125 00:07:23,445 --> 00:07:26,985 And, this idea that they would review it annually, I think it's a 126 00:07:27,045 --> 00:07:31,335 I think it also makes sense though, because you like with the five 127 00:07:31,335 --> 00:07:32,515 year, three year, five year, right? 128 00:07:32,515 --> 00:07:34,565 You have to worry about hardware depreciation, right? 129 00:07:34,575 --> 00:07:37,405 Upgrade cycles all the rest With cloud, right? 130 00:07:37,475 --> 00:07:41,115 There might be new technologies, cheaper ways to do things, right? 131 00:07:41,115 --> 00:07:42,295 Your workloads might change. 132 00:07:42,345 --> 00:07:45,675 what you had running on premises might be migrated to the cloud. 133 00:07:45,725 --> 00:07:46,575 now you have to reconsider it. 134 00:07:46,585 --> 00:07:47,435 How do I back it up? 135 00:07:47,855 --> 00:07:51,805 And so I think that's probably why looking at these things more 136 00:07:51,805 --> 00:07:55,015 frequently, like annually, probably starting to make a lot more sense. 137 00:07:55,135 --> 00:07:57,435 Well, that is the news of the day. 138 00:08:06,360 --> 00:08:11,875 on this episode of the Backup to basic series, we're going to be talking 139 00:08:11,875 --> 00:08:15,765 about replication, different kinds of replication, the good things, the bad 140 00:08:15,765 --> 00:08:22,675 things, and what they, you know, what they have to do with backup and, and 141 00:08:22,780 --> 00:08:23,100 I, I, 142 00:08:23,345 --> 00:08:23,515 it a backup, 143 00:08:23,980 --> 00:08:27,620 I, I, I I thought you were going to talk about like the replication 144 00:08:27,640 --> 00:08:31,775 technologies that they have in like Star Trek and, Right? 145 00:08:31,775 --> 00:08:33,955 Where it's like, create me, 146 00:08:35,455 --> 00:08:37,785 No, that's, that's not replication. 147 00:08:37,785 --> 00:08:38,215 That's... 148 00:08:39,050 --> 00:08:39,980 What is that called? 149 00:08:40,115 --> 00:08:40,825 what are those things? 150 00:08:42,360 --> 00:08:43,400 Transporters? 151 00:08:43,970 --> 00:08:45,200 Oh, oh, no. 152 00:08:45,435 --> 00:08:46,925 the making, the stuff, right? 153 00:08:46,925 --> 00:08:47,555 The food 154 00:08:48,540 --> 00:08:49,950 Do they call them replicators? 155 00:08:50,115 --> 00:08:50,595 Yeah. 156 00:08:50,870 --> 00:08:51,930 I think they call them replicators. 157 00:08:53,100 --> 00:08:59,220 We are, we are not discussing replicators like in Star Trek, although that does, 158 00:08:59,230 --> 00:09:01,390 those do sound magical, by the way. 159 00:09:01,620 --> 00:09:04,910 And by the way, like if you could do transporters, of course you 160 00:09:04,910 --> 00:09:06,160 could do replicators, right? 161 00:09:06,160 --> 00:09:10,550 Because all replicators are is storing a backup copy of the food and then 162 00:09:10,550 --> 00:09:12,820 saying this is what it is, right? 163 00:09:12,985 --> 00:09:17,855 Do you think that they have backups of those backups? 164 00:09:17,905 --> 00:09:18,435 The copies? 165 00:09:18,495 --> 00:09:22,635 Yeah, no, the copies of the food because imagine you wipe out the 166 00:09:22,675 --> 00:09:25,375 copies and then you've basically killed off humanity because they 167 00:09:25,375 --> 00:09:26,555 wouldn't have any way to make food. 168 00:09:29,480 --> 00:09:29,630 I 169 00:09:29,655 --> 00:09:33,185 Or maybe they're immutable, or maybe they're immutable copies, you know? 170 00:09:33,770 --> 00:09:35,270 Maybe they're immutable copies. 171 00:09:35,450 --> 00:09:37,990 I would, I would hope that no one can go in and change the 172 00:09:37,990 --> 00:09:39,830 food before it gets replicated. 173 00:09:40,750 --> 00:09:41,370 Um, 174 00:09:41,835 --> 00:09:43,255 On to a more serious matter. 175 00:09:44,310 --> 00:09:45,610 let's do a more serious matter. 176 00:09:45,840 --> 00:09:50,280 Well, so we, we've moved on the previous episodes. 177 00:09:50,280 --> 00:09:57,020 We talked about sort of regular kind of backups and they were, they were backups. 178 00:09:57,380 --> 00:10:03,910 That require a restore basically is, is what we were talking about. 179 00:10:04,210 --> 00:10:09,150 We've now moved on to types of backups where the restore 180 00:10:09,220 --> 00:10:11,070 is essentially already done. 181 00:10:11,730 --> 00:10:12,190 Right. 182 00:10:12,260 --> 00:10:13,730 Um, and replication. 183 00:10:13,830 --> 00:10:18,420 And so I'm, I'm, I'm putting these and, and by the way, you know, for those that 184 00:10:18,440 --> 00:10:22,350 don't know what I'm talking about, we are basically working our way through. 185 00:10:22,635 --> 00:10:26,805 This book, Modern Data Protection, which is my book, which is available, 186 00:10:26,815 --> 00:10:28,395 you know, wherever books are sold. 187 00:10:29,385 --> 00:10:33,475 And, um, you know, I might even put a, put a link in the show description there. 188 00:10:34,655 --> 00:10:40,185 Um, and the idea here is what we're talking about is methods of backup. 189 00:10:40,235 --> 00:10:45,355 And again, remember when I say backup, I I'm very broad in that term, methods 190 00:10:45,355 --> 00:10:47,475 of backup that support instant recovery. 191 00:10:47,485 --> 00:10:48,515 What do you want to talk about? 192 00:10:48,515 --> 00:10:49,445 What instant recovery is? 193 00:10:49,785 --> 00:10:53,475 Yeah, so, normally when you think about, you took a backup, you 194 00:10:53,475 --> 00:10:56,625 need to, something happens, you need to get back your data, right? 195 00:10:56,645 --> 00:11:00,505 If you had your data stored on tape, you gotta go fetch the tape, you gotta pull 196 00:11:00,505 --> 00:11:03,915 the data off of tape, copy it somewhere else, and now you actually have your data 197 00:11:03,915 --> 00:11:05,775 and you can do something with it, right? 198 00:11:05,815 --> 00:11:10,650 With Instant Recovery, It's really, your data is already available for you. 199 00:11:10,650 --> 00:11:14,630 You don't have to have any sort of processing that you have to do before you 200 00:11:14,630 --> 00:11:16,220 can actually start accessing your data. 201 00:11:17,790 --> 00:11:19,500 Yeah, I mean, it's a beautiful thing. 202 00:11:19,530 --> 00:11:24,350 I think that maybe, I dream that sometime in the future, this is 203 00:11:24,350 --> 00:11:25,810 the way all restores will be done. 204 00:11:26,885 --> 00:11:29,205 And the cloud really does make this possible. 205 00:11:29,205 --> 00:11:33,605 We could talk about that all day long, but we just need to work through 206 00:11:33,605 --> 00:11:40,025 the different ways that, um, we're going to create an always on readily 207 00:11:40,025 --> 00:11:44,325 available copy of the data, and the first that we're going to talk about is 208 00:11:45,010 --> 00:11:49,200 Before you get there though, I think one important point to cover is, I 209 00:11:49,200 --> 00:11:53,450 know you said in the future maybe everything will be like this, right? 210 00:11:53,490 --> 00:11:59,140 I think if you had a gazillion dollars, yes, Because there 211 00:11:59,140 --> 00:12:00,690 is a cost associated, right? 212 00:12:00,690 --> 00:12:03,160 Which I think is important to cover, right? 213 00:12:04,000 --> 00:12:08,860 With sort of using these various technologies that might make it more 214 00:12:08,860 --> 00:12:12,140 difficult now Like you said, maybe the cloud helps with some of these but there 215 00:12:12,140 --> 00:12:18,170 is still a cost associated with Keeping data on something that is instantly 216 00:12:18,170 --> 00:12:24,060 available Versus say using a tape or some sort of offline Media where the 217 00:12:24,080 --> 00:12:27,960 cost may not be just the cost of the storage but think about from power cooling 218 00:12:28,320 --> 00:12:29,700 Right all those other aspects as well 219 00:12:31,950 --> 00:12:37,610 Yeah, I was speaking in the future when these problems have all been solved. 220 00:12:39,220 --> 00:12:48,280 Um, I think even today that there are services, there are cloud storage 221 00:12:48,330 --> 00:12:57,450 services, that if used properly and judiciously, can provide you A ready 222 00:12:57,450 --> 00:13:08,130 to go copy of your data pennies on the dollar that costs you, you know, 223 00:13:08,190 --> 00:13:13,090 next to nothing to, to have and to possess and to have it ready to go. 224 00:13:13,410 --> 00:13:18,390 You will then pay through the nose if you use them, right? 225 00:13:18,680 --> 00:13:24,480 I'm thinking of course of like Glacier, Deep Archive, Instant Recovery. 226 00:13:25,005 --> 00:13:25,375 Right? 227 00:13:25,395 --> 00:13:30,845 There are services that are still storing the data on disk, but storing 228 00:13:30,845 --> 00:13:33,895 it in such a way, I don't know, we don't, you know, neither of us have 229 00:13:33,895 --> 00:13:39,725 ever worked at AWS or any of the cloud providers, but they're storing it in 230 00:13:39,725 --> 00:13:44,115 such a way that they've made it so cheap. 231 00:13:44,930 --> 00:13:48,870 To, to, to have that copy, to have it offsite, to have it in, 232 00:13:48,890 --> 00:13:50,330 you know, in another region. 233 00:13:50,780 --> 00:13:59,070 I just think that as that continues to happen, that we will eventually 234 00:13:59,070 --> 00:14:03,510 get to a place where all DR copies can be held like this. 235 00:14:04,070 --> 00:14:05,520 Can I have a dream, Prasanna? 236 00:14:05,520 --> 00:14:06,950 Can I have a dream? 237 00:14:06,960 --> 00:14:06,990 Can 238 00:14:07,450 --> 00:14:11,160 You can have a dream, but I think, but yes, but before, sorry, before 239 00:14:11,160 --> 00:14:14,560 we also continue on, I think we also need to define what we 240 00:14:14,560 --> 00:14:17,120 mean when we say instant, right? 241 00:14:17,120 --> 00:14:18,060 Because instant, 242 00:14:18,530 --> 00:14:21,210 when we say instant recovery, right? 243 00:14:21,210 --> 00:14:26,300 I think it's helpful to talk about that because instant is a spectrum, right? 244 00:14:26,320 --> 00:14:31,140 Like you were talking about for your Glacier instant restore feature, right? 245 00:14:31,650 --> 00:14:33,460 It's not like, Oh, I want my data. 246 00:14:33,460 --> 00:14:34,945 It's available within the Cloud. 247 00:14:35,565 --> 00:14:37,615 Like, snap my fingers, it's there. 248 00:14:37,745 --> 00:14:37,975 Right? 249 00:14:38,015 --> 00:14:42,015 It does take time, but that time may be acceptable to you, right? 250 00:14:42,045 --> 00:14:44,835 It might be, say, minutes, not days. 251 00:14:45,840 --> 00:14:46,140 yeah. 252 00:14:46,240 --> 00:14:49,100 So instant is kind of like continuous. 253 00:14:49,110 --> 00:14:50,600 It's a binary condition. 254 00:14:50,980 --> 00:14:52,310 It's sort of like immutable. 255 00:14:52,350 --> 00:14:53,660 It's a binary condition. 256 00:14:53,670 --> 00:14:55,330 It's like pregnancy, right? 257 00:14:55,570 --> 00:14:57,300 You're either pregnant or you're not. 258 00:14:57,730 --> 00:14:59,600 And so it's either instance or it's not. 259 00:14:59,620 --> 00:15:03,950 But it's yet another one of these terms where it's not truly binary. 260 00:15:04,350 --> 00:15:04,770 Right? 261 00:15:04,840 --> 00:15:09,550 It's just, we're defining instant recovery in this point is, I don't need 262 00:15:09,550 --> 00:15:11,610 to do a restore to do the recovery. 263 00:15:11,920 --> 00:15:13,390 The data's already been restored. 264 00:15:13,400 --> 00:15:16,650 It might take a few minutes to make it accessible to me. 265 00:15:16,865 --> 00:15:20,455 Yeah, sorry, and, and just for people who may not have heard our previous 266 00:15:20,695 --> 00:15:24,455 episodes, do you want to quickly cover differences between restore and 267 00:15:24,455 --> 00:15:26,015 recovery since you just talked about it? 268 00:15:29,170 --> 00:15:33,180 A restore is essentially the act of bringing back the, you know, 269 00:15:33,230 --> 00:15:35,150 the data and putting it in place. 270 00:15:35,150 --> 00:15:40,560 The recovery is the process of sort of bringing that data online and using it. 271 00:15:40,600 --> 00:15:44,090 And, and sometimes that recovery involves massaging other things. 272 00:15:44,090 --> 00:15:47,800 It involves massaging the data and it involves doing other things. 273 00:15:48,060 --> 00:15:49,680 When you're done with the recovery. 274 00:15:50,280 --> 00:15:52,100 Everything is working again. 275 00:15:52,780 --> 00:15:57,090 When you're done with the restore, everything is ready to be working again. 276 00:15:57,440 --> 00:16:01,730 Uh, so depending on how good or how complicated the restore is, 277 00:16:01,730 --> 00:16:04,680 the two may be, they, they may happen at the same time, but in a 278 00:16:04,680 --> 00:16:08,740 complicated situation, you do the restore and then you do the recovery. 279 00:16:10,190 --> 00:16:14,360 this case, uh, the recovery would be this instant of, um, 280 00:16:14,390 --> 00:16:15,780 you know, like I said, just, 281 00:16:15,965 --> 00:16:16,875 Everything's ready to go. 282 00:16:17,215 --> 00:16:18,065 Or sorry, everything. 283 00:16:18,085 --> 00:16:19,295 has, is available. 284 00:16:20,845 --> 00:16:21,615 Yeah, exactly. 285 00:16:21,755 --> 00:16:23,455 Uh, we don't have to do a restore. 286 00:16:23,945 --> 00:16:30,125 And I would say that in a true instant recovery, the size of the, of the thing 287 00:16:30,135 --> 00:16:34,915 being recovered should not be a factor. 288 00:16:34,975 --> 00:16:37,495 Whereas in a restore, it very much is, 289 00:16:38,035 --> 00:16:38,475 Oh yeah. 290 00:16:38,925 --> 00:16:39,215 right? 291 00:16:39,235 --> 00:16:39,555 Yeah. 292 00:16:39,655 --> 00:16:39,835 Yeah. 293 00:16:39,945 --> 00:16:40,295 Okay. 294 00:16:41,255 --> 00:16:47,045 So with that in mind, we're going to talk about the first method that could be used. 295 00:16:47,065 --> 00:16:52,745 And, and is used actually, it is used quite a bit to do an instant recovery. 296 00:16:53,775 --> 00:16:58,625 Uh, as we often do on the show, let me take you back in the day. 297 00:17:05,961 --> 00:17:06,311 Yeah. 298 00:17:06,371 --> 00:17:13,461 So back in the day, there was a very sharp dividing line between. 299 00:17:14,161 --> 00:17:16,971 Backup and recovery and disaster recovery. 300 00:17:17,341 --> 00:17:21,521 And for backup and recovery for what we also call operational 301 00:17:21,571 --> 00:17:24,471 recovery, you had a backup system. 302 00:17:24,481 --> 00:17:28,821 You went to tape and, and when you did a restore, you, you came back 303 00:17:28,821 --> 00:17:30,251 up, you came back off of tape. 304 00:17:31,151 --> 00:17:36,581 Anyone with a tight recovery time objective would never build, 305 00:17:36,711 --> 00:17:39,691 uh, their DR system based on tape back in the day, right? 306 00:17:39,871 --> 00:17:44,071 Even as we move to disk based backup and recovery systems, anybody with a 307 00:17:44,071 --> 00:17:49,311 tight RTO is not going to build their disaster recovery system built on 308 00:17:49,581 --> 00:17:51,341 having to do a restore first, right? 309 00:17:51,881 --> 00:17:57,081 So back in the day, if you worked at like a financial trading firm or 310 00:17:57,081 --> 00:18:01,371 something like that, and you wanted to have a disaster recovery plan because of 311 00:18:01,371 --> 00:18:05,281 course you wanted that because you had the OCC that was looking into you and 312 00:18:06,036 --> 00:18:06,426 Regulation, 313 00:18:06,521 --> 00:18:08,851 could say we're not a bank, right? 314 00:18:09,601 --> 00:18:12,111 You used replication. 315 00:18:12,471 --> 00:18:15,141 You had a backup and recovery system that did operational recoveries 316 00:18:15,141 --> 00:18:18,931 and file recoveries, and maybe even recovering an entire server. 317 00:18:18,931 --> 00:18:23,491 But if you had data that truly mattered, you used replication. 318 00:18:24,401 --> 00:18:26,231 And, and I know you worked at a company 319 00:18:26,436 --> 00:18:28,436 Yeah, that, was my first job out of, out of 320 00:18:28,436 --> 00:18:28,936 college. 321 00:18:31,136 --> 00:18:37,236 Yeah, So, let's talk about what replication is, uh, how does 322 00:18:37,236 --> 00:18:39,106 it typically manifest itself. 323 00:18:39,106 --> 00:18:39,766 Do you want to just... 324 00:18:40,186 --> 00:18:42,126 Sort of define what replication is? 325 00:18:42,406 --> 00:18:48,326 so replication is basically taking data, making a copy, and sending 326 00:18:48,326 --> 00:18:50,996 it off to some other system, right? 327 00:18:51,046 --> 00:18:51,686 At a high level. 328 00:18:51,696 --> 00:18:56,236 Now, there's various nuances and combinations that other system 329 00:18:56,236 --> 00:18:59,536 could be the exact same vendor, the same model, all the rest. 330 00:18:59,916 --> 00:19:02,436 As the original, it could be a different vendor, right? 331 00:19:02,436 --> 00:19:03,446 A different system. 332 00:19:03,846 --> 00:19:04,146 Right? 333 00:19:04,146 --> 00:19:05,506 So there are different ways you could do it. 334 00:19:05,506 --> 00:19:08,826 There are different protocols for transferring that data. 335 00:19:09,136 --> 00:19:11,996 You could use protocols that some of these vendors have built in 336 00:19:11,996 --> 00:19:15,046 for communicating between them to make things more efficient. 337 00:19:15,476 --> 00:19:19,396 Because when you have to send data across from one system to another, 338 00:19:19,756 --> 00:19:23,326 doing it over and over, because it's not like it's a one time operation, right? 339 00:19:23,356 --> 00:19:24,076 Depending, 340 00:19:24,186 --> 00:19:24,536 Yeah. 341 00:19:25,136 --> 00:19:29,206 If I could interrupt, I think that's one word missing from your definition. 342 00:19:29,436 --> 00:19:32,886 If I could insert at the beginning of your definition, the word continuously. 343 00:19:33,616 --> 00:19:34,116 Right. 344 00:19:34,406 --> 00:19:36,116 Because anybody can copy the data over. 345 00:19:36,146 --> 00:19:39,326 I think replication implies that we're continuously copying it 346 00:19:39,426 --> 00:19:39,616 over. 347 00:19:39,724 --> 00:19:43,484 The idea is that it, that it's happening all the time, right? 348 00:19:44,534 --> 00:19:47,504 We're going to talk about the difference between asynchronous and synchronous. 349 00:19:47,604 --> 00:19:53,144 So sorry for the confusion for those, but basically you have some data, you 350 00:19:53,144 --> 00:19:56,874 know, in A and you, and you have a copy of that data in B and that copy, 351 00:19:56,914 --> 00:20:02,984 that, that B copy is continuously, for lack of a better word, updated to 352 00:20:02,994 --> 00:20:05,574 be the same exact thing as what's in 353 00:20:05,709 --> 00:20:09,199 Yeah, so going to Curtis's disaster recovery scenario, right? 354 00:20:09,479 --> 00:20:12,349 Something happens on system A, right? 355 00:20:12,369 --> 00:20:16,859 System B has a version of what system A looked like at a point in time, 356 00:20:16,859 --> 00:20:20,409 and you can fail over to system B, and that's how you're instantly 357 00:20:20,419 --> 00:20:22,039 up and running, because system B 358 00:20:25,044 --> 00:20:27,974 I think one thing we should also cover, which I want to talk about 359 00:20:27,974 --> 00:20:32,254 earlier, I know you threw out the term recovery time objective. 360 00:20:32,254 --> 00:20:37,104 I think another point to talk about here is also recovery point objective, right? 361 00:20:37,169 --> 00:20:37,419 Yeah. 362 00:20:37,499 --> 00:20:38,019 Well, go ahead. 363 00:20:38,249 --> 00:20:39,069 You brought it up. 364 00:20:39,494 --> 00:20:43,774 So yes, in the case of when you're doing synchronous replication, yes, there's 365 00:20:43,774 --> 00:20:45,954 still going to be an RTO on that. 366 00:20:46,244 --> 00:20:50,094 But that RTO, you should be able to measure in seconds to minutes, depending 367 00:20:50,094 --> 00:20:53,084 on how long it takes you to bring up system B and make it available for 368 00:20:53,084 --> 00:20:54,234 your applications and other things. 369 00:20:55,454 --> 00:20:56,054 So that's kind of 370 00:20:56,054 --> 00:20:57,044 like RTO side. 371 00:20:57,224 --> 00:20:59,264 Do you wanna talk about the RPO, Curtis? 372 00:21:00,009 --> 00:21:00,349 Yeah. 373 00:21:00,349 --> 00:21:05,169 So the RPO is, is basically the amount of data that you 374 00:21:05,169 --> 00:21:07,619 agree that you can lose, right? 375 00:21:07,639 --> 00:21:13,149 The recovery point objective is we say we can lose an hour's worth of data. 376 00:21:13,149 --> 00:21:15,069 We can lose a day's worth of data. 377 00:21:15,369 --> 00:21:18,089 We can only lose five minutes worth of data. 378 00:21:18,099 --> 00:21:18,829 This is. 379 00:21:19,249 --> 00:21:21,619 You're setting your recovery point objective. 380 00:21:22,169 --> 00:21:24,589 What, to what point must you recover? 381 00:21:25,079 --> 00:21:31,419 And the fastest RPOs in the business are going to come from these types 382 00:21:31,419 --> 00:21:34,429 of products that we're going to talk about in the next couple of episodes. 383 00:21:34,429 --> 00:21:35,479 The first of which being. 384 00:21:35,889 --> 00:21:39,309 Uh, replication with a, with a, you know, a replication 385 00:21:39,309 --> 00:21:41,069 system, you could get an RPO. 386 00:21:41,409 --> 00:21:45,649 Uh, you could meet an RPO that's as close to zero as possible, 387 00:21:45,794 --> 00:21:46,904 actually seen zero, 388 00:21:48,459 --> 00:21:50,029 Yeah, I'm sure you can do zero. 389 00:21:50,039 --> 00:21:50,819 It's just that 390 00:21:51,704 --> 00:21:51,884 so 391 00:21:51,884 --> 00:21:52,184 I'm gonna 392 00:21:52,269 --> 00:21:52,959 could happen, 393 00:21:53,634 --> 00:21:55,964 So it's in a very, very unique case. 394 00:21:55,964 --> 00:21:59,564 So I don't know if you're aware of this, there is a mode on 395 00:21:59,569 --> 00:22:01,004 some systems called domino mode. 396 00:22:01,214 --> 00:22:03,524 It's out there in the industry, right? 397 00:22:03,524 --> 00:22:07,664 And basically what you're saying is, every time I accept a write 398 00:22:07,664 --> 00:22:11,874 on system, A, I'm gonna make sure it's replicated, it hit system B. 399 00:22:12,429 --> 00:22:15,989 It's acknowledged before system A acknowledges a client. 400 00:22:17,249 --> 00:22:17,709 Yeah, 401 00:22:17,889 --> 00:22:19,149 you're guaranteeing every 402 00:22:19,209 --> 00:22:22,709 basically, it's like a two phase commit for storage. 403 00:22:24,454 --> 00:22:29,084 A two phase commit is a term from database, um, world, which makes 404 00:22:29,084 --> 00:22:32,384 sure that it's written both to the log and it's written to the, you 405 00:22:32,384 --> 00:22:36,534 know, before you acknowledge that the, the transaction has happened. 406 00:22:36,594 --> 00:22:36,974 It's High 407 00:22:36,994 --> 00:22:40,954 latency, very expensive, but if you have those requirements, there is an option. 408 00:22:41,834 --> 00:22:42,634 But like you said, most 409 00:22:42,634 --> 00:22:43,174 people will... 410 00:22:44,034 --> 00:22:49,734 So the question is what matters more to you, performance or never losing any data? 411 00:22:51,354 --> 00:22:52,804 So let's, speaking of which. 412 00:22:53,194 --> 00:22:56,124 Let's talk about the difference between synchronous replication 413 00:22:56,164 --> 00:22:57,604 and asynchronous replication. 414 00:22:58,264 --> 00:23:04,474 Um, synchronous is basically what you just described that, um, well, 415 00:23:04,534 --> 00:23:05,674 it's not necessarily what you 416 00:23:05,679 --> 00:23:06,999 Yeah, not fully to domino 417 00:23:07,024 --> 00:23:10,944 we are going to, we are going to replicate every byte. 418 00:23:11,689 --> 00:23:13,559 As it's happening, right. 419 00:23:14,129 --> 00:23:21,059 And literally every single, you know, the moment it, a change happens here, the rep, 420 00:23:21,069 --> 00:23:25,699 the change is going to be replicated to the, to the destination, to the target. 421 00:23:26,119 --> 00:23:26,549 Right. 422 00:23:26,989 --> 00:23:32,849 And, um, the, the good side of synchronous replication is you're going to have. 423 00:23:33,139 --> 00:23:35,669 The smallest RPO is possible, right? 424 00:23:35,699 --> 00:23:39,679 Including, I guess I, I, I, I guess I was aware of it. 425 00:23:39,679 --> 00:23:42,779 I didn't know that that, that I didn't know the term dominant mode, but, 426 00:23:42,809 --> 00:23:48,209 but I was aware of that, that idea, the, this is going to give you your, 427 00:23:48,259 --> 00:23:52,209 your tightest, uh, RPO as possible. 428 00:23:52,699 --> 00:23:56,879 The challenge with, uh, this is a little thing called the speed of light. 429 00:24:00,189 --> 00:24:05,749 The, um, it takes, so, you know, one of the things that we. 430 00:24:06,034 --> 00:24:11,374 That we know is that we want the recovery copy to be some 431 00:24:11,374 --> 00:24:14,254 distance away from the primary 432 00:24:14,379 --> 00:24:15,309 in the same rack. 433 00:24:16,174 --> 00:24:19,184 not in the same rack, not in the same town. 434 00:24:19,584 --> 00:24:26,774 Um, there are sadly some stories from 9 11 where there were companies 435 00:24:26,774 --> 00:24:30,554 that had their hot site, which was a synchronously replicated copy of 436 00:24:30,594 --> 00:24:33,814 their data in the, uh, other tower. 437 00:24:34,024 --> 00:24:38,104 And so there were companies that ceased to exist on 9 11 because they lost both their 438 00:24:38,104 --> 00:24:40,264 primary and their secondary copy, right? 439 00:24:40,264 --> 00:24:45,244 You don't want to have the two copies in the same place where a disaster 440 00:24:45,244 --> 00:24:49,504 could wipe out the entire town, a flood, a earthquake, whatever. 441 00:24:50,074 --> 00:24:53,314 And so you want to have some distance between. 442 00:24:54,074 --> 00:24:55,444 uh, the two. 443 00:24:55,444 --> 00:25:03,634 Now after 9 11, the, I don't know which, um, which governmental organization, 444 00:25:03,634 --> 00:25:09,564 but after 9 11, the, the fed, the federal government, not the fed, which 445 00:25:09,564 --> 00:25:11,004 we say the fed or you know what I mean? 446 00:25:11,244 --> 00:25:18,404 The federal government started to dictate that A recovery that, that a, that a 447 00:25:18,414 --> 00:25:23,334 synchronous copy of the data needed to be stored more than it was like 250 miles. 448 00:25:24,034 --> 00:25:28,724 And, and everybody basically came back and said, that's not really feasible. 449 00:25:28,984 --> 00:25:34,854 It's possible, but not feasible because going 250 miles. 450 00:25:35,159 --> 00:25:39,209 At the speed of light, every single time you replicate, every single time you 451 00:25:39,219 --> 00:25:46,639 update a block on every piece of storage, um, basically really pulls down the, um, 452 00:25:47,579 --> 00:25:49,399 the performance of the primary system. 453 00:25:49,729 --> 00:25:54,959 And the other thing to also mention is when you're doing synchronous replication, 454 00:25:55,289 --> 00:25:57,059 you want to make sure that you're... 455 00:25:58,114 --> 00:25:59,744 Destination system, right? 456 00:25:59,744 --> 00:26:05,164 Your replica copy is as performant as your primary copy, right? 457 00:26:05,164 --> 00:26:08,694 Because otherwise, if it starts to lag and slow down, eventually you're going to 458 00:26:08,704 --> 00:26:10,684 start falling further and further behind. 459 00:26:11,004 --> 00:26:14,424 And usually these technologies, after a while, they'll just stop accepting writes. 460 00:26:14,424 --> 00:26:17,154 And they'll kind of fall back into like an asynchronous mode and 461 00:26:17,474 --> 00:26:19,084 have to then catch back up, right? 462 00:26:19,084 --> 00:26:21,164 Which you don't want because that affects your RPO. 463 00:26:21,844 --> 00:26:22,654 Yeah, you don't want. 464 00:26:22,664 --> 00:26:23,234 Yeah. 465 00:26:23,384 --> 00:26:27,464 So yeah, so it's got to be basically the same, if not better 466 00:26:27,474 --> 00:26:32,154 performance on the backup system, which is crazy talk to most people. 467 00:26:32,844 --> 00:26:33,264 Right? 468 00:26:33,714 --> 00:26:37,584 Um, but that, but that is if you want an RPO of zero. 469 00:26:38,144 --> 00:26:42,484 Synchronous replication is literally your only choice, right? 470 00:26:42,934 --> 00:26:46,724 Let's talk about asynchronous replication and that is basically 471 00:26:46,724 --> 00:26:53,344 not that we're, we're not, we're going to build essentially a buffer. 472 00:26:53,889 --> 00:26:59,999 Uh, of writes as the, know, and we try to not let the buffer get full, right? 473 00:26:59,999 --> 00:27:05,709 The, basically the, what it does is it disconnects the, the writes on the 474 00:27:05,709 --> 00:27:11,179 other side with the writes on this side, we may, and we'll try to keep up 475 00:27:11,189 --> 00:27:17,169 with the pace, but writes can continue to update and you might get a spur of 476 00:27:17,169 --> 00:27:20,839 writes, uh, on the, on the primary side. 477 00:27:21,414 --> 00:27:25,474 And then they fill up the buffer and then, you know, the, the buffer gets emptied. 478 00:27:26,134 --> 00:27:31,834 And that I think works as long as essentially your, you know, your bandwidth 479 00:27:31,834 --> 00:27:33,884 and your latency is, is sufficient. 480 00:27:34,934 --> 00:27:35,804 Um, 481 00:27:36,579 --> 00:27:36,949 And, 482 00:27:38,084 --> 00:27:38,504 go ahead. 483 00:27:38,509 --> 00:27:42,529 and I just want to chime in that I know you called it async and async 484 00:27:42,549 --> 00:27:47,729 threw me for a while because in my mind async is different, but that's 485 00:27:47,729 --> 00:27:49,929 just based on my background, right? 486 00:27:49,989 --> 00:27:56,109 Um, other vendors might refer to this as like semi synchronous, right? 487 00:27:56,159 --> 00:27:59,419 Where it is not fully synchronous. 488 00:28:00,134 --> 00:28:00,664 Right, but 489 00:28:00,894 --> 00:28:02,754 Well, not synchronous. 490 00:28:03,124 --> 00:28:04,504 Asynchronous means 491 00:28:04,604 --> 00:28:07,834 know, I know, I know, but this is just some vendors. 492 00:28:07,834 --> 00:28:12,464 So if you are looking at vendor terminology, right, and looking at 493 00:28:12,464 --> 00:28:16,084 their vendor technical specs, what, so here's a question for you, Curtis. 494 00:28:16,514 --> 00:28:21,594 What are some things that a user can look at for a vendor's technical 495 00:28:21,594 --> 00:28:26,504 specs to determine if they support async replication, like what 496 00:28:26,504 --> 00:28:27,434 we're talking about right now? 497 00:28:29,049 --> 00:28:33,189 Well, I mean, I don't know what other words they would use to describe 498 00:28:33,189 --> 00:28:33,499 it, 499 00:28:34,374 --> 00:28:36,664 I know NetApp uses semi synchronous. 500 00:28:36,914 --> 00:28:37,734 For what you're describing. 501 00:28:38,079 --> 00:28:38,859 whatever. 502 00:28:39,099 --> 00:28:40,079 That's just mark. 503 00:28:40,129 --> 00:28:41,509 That's just marketing BS. 504 00:28:41,539 --> 00:28:42,009 Okay. 505 00:28:42,329 --> 00:28:44,679 It's either synchronous or it's not synchronous. 506 00:28:45,029 --> 00:28:48,629 You're either replicating everything as it's happening or you're not. 507 00:28:49,059 --> 00:28:49,639 Okay. 508 00:28:50,159 --> 00:28:55,889 Like, so the question is, so the question to the vendor, it's not, is, can my target 509 00:28:55,889 --> 00:28:59,759 copy ever get behind my primary copy? 510 00:29:01,559 --> 00:29:02,749 And the answer is yes. 511 00:29:02,749 --> 00:29:04,649 And it's like, well, well, how much are we talking? 512 00:29:04,649 --> 00:29:04,919 Right? 513 00:29:04,919 --> 00:29:06,849 So the question is, because that's going 514 00:29:07,594 --> 00:29:08,914 the, so that's 515 00:29:08,914 --> 00:29:09,874 actually the key, yeah. 516 00:29:10,539 --> 00:29:11,379 Yeah, exactly. 517 00:29:11,379 --> 00:29:16,939 So if you can build up a buffer of an hour of changes, you could lose an 518 00:29:16,939 --> 00:29:23,579 hour of changes on the, on the target end if you lost your primary, Um, 519 00:29:23,949 --> 00:29:24,519 and. 520 00:29:25,704 --> 00:29:30,414 what if you said like, I want, so, okay, so then I'll take back my comment. 521 00:29:31,744 --> 00:29:36,764 In your mind though, if I said I want to have a replica copy 522 00:29:36,774 --> 00:29:39,334 updated and my RPO is 8 hours. 523 00:29:40,394 --> 00:29:41,264 That's still async. 524 00:29:43,364 --> 00:29:44,124 Well, what else would you 525 00:29:44,334 --> 00:29:44,644 Okay. 526 00:29:44,674 --> 00:29:45,704 No, just, just checking. 527 00:29:46,694 --> 00:29:47,034 Yeah. 528 00:29:47,044 --> 00:29:49,084 I mean, again, you're either synchronous or you're not 529 00:29:49,434 --> 00:29:51,354 So then, so then I take back my comments, right? 530 00:29:51,364 --> 00:29:54,654 So if I look specifically, that's why I just wanted to make sure. 531 00:29:55,029 --> 00:29:56,484 You stand corrected, 532 00:29:56,694 --> 00:29:57,164 Yes. 533 00:29:57,374 --> 00:30:03,154 So if I look at, sorry, I used to, I'm more familiar with NetApp and NetApp's 534 00:30:03,164 --> 00:30:04,624 replication technologies, right? 535 00:30:04,624 --> 00:30:08,734 But if I look at NetApp, right, they have synchronous, which we talked 536 00:30:08,744 --> 00:30:11,274 about, which matches perfectly with what we were talking about. 537 00:30:11,744 --> 00:30:15,234 They have semi sync where it allows some amount of lag. 538 00:30:15,234 --> 00:30:17,144 I think it's up to 60 seconds. 539 00:30:18,384 --> 00:30:18,694 Right. 540 00:30:18,694 --> 00:30:21,294 But it does like what you said, buffering, and then they have 541 00:30:21,294 --> 00:30:23,404 sort of their async, right? 542 00:30:23,404 --> 00:30:27,954 Where it allows you to go beyond, I think it's from five minutes to, you can set a 543 00:30:27,964 --> 00:30:31,104 replication every five minutes to days, 544 00:30:32,174 --> 00:30:36,494 And those are just two different, those are just both asynchronous with different 545 00:30:36,604 --> 00:30:38,044 settings, as far as I'm concerned. 546 00:30:38,834 --> 00:30:43,804 Um, and, and you could also, like, if you were a net app and I don't think they do 547 00:30:43,804 --> 00:30:49,904 it like this, but if you waited until you took a snapshot and then replicated only 548 00:30:49,904 --> 00:30:54,064 the bits necessary for that snapshot, that's still kind of asynchronous, 549 00:30:54,124 --> 00:30:54,974 just a technology. 550 00:30:55,074 --> 00:30:55,654 That's a means. 551 00:30:55,744 --> 00:30:56,084 yeah. 552 00:30:56,444 --> 00:31:00,254 But generally here, we're not talking about snapshots and things, because 553 00:31:00,314 --> 00:31:01,794 that's what we're going to talk about. 554 00:31:02,634 --> 00:31:06,914 In a following episode, generally what we're talking about is two, 555 00:31:07,904 --> 00:31:13,764 you know, block devices that are being continuously updated to be 556 00:31:13,874 --> 00:31:17,234 exactly the same with possibly a lag. 557 00:31:17,944 --> 00:31:20,114 If there's a lag, then it's asynchronous. 558 00:31:20,114 --> 00:31:21,174 If there's no lag, then it's 559 00:31:21,574 --> 00:31:27,204 Does it have to be, so I'm going to ask another question. 560 00:31:27,594 --> 00:31:28,104 So 561 00:31:28,244 --> 00:31:28,644 you are 562 00:31:29,244 --> 00:31:30,194 I know I am. 563 00:31:31,144 --> 00:31:32,724 So you said block devices. 564 00:31:33,644 --> 00:31:39,954 Would you consider anything that also replicates a VM at a VM block level 565 00:31:41,024 --> 00:31:41,564 Yeah. 566 00:31:41,674 --> 00:31:42,044 Yeah. 567 00:31:42,094 --> 00:31:45,154 I mean, in the end, it's still a block device underneath, right? 568 00:31:45,154 --> 00:31:46,494 It's not what we're replicating. 569 00:31:46,494 --> 00:31:48,914 It's just that, um. 570 00:31:49,409 --> 00:31:53,129 We don't, we don't have this conversation when we're talking about object, 571 00:31:54,039 --> 00:31:54,739 Or files. 572 00:31:55,129 --> 00:32:03,029 We don't, we don't, well, even, even file replication, we don't really talk 573 00:32:03,039 --> 00:32:06,029 about synchronous and asynchronous when we do file replication, I don't think. 574 00:32:06,039 --> 00:32:07,609 I think that's always asynchronous. 575 00:32:09,299 --> 00:32:10,229 At least I don't think so. 576 00:32:10,239 --> 00:32:14,519 I think this is generally a block discussion, right? 577 00:32:15,079 --> 00:32:18,379 There may be exceptions to that rule, but generally this is a block discussion. 578 00:32:18,639 --> 00:32:20,629 Even if this is a NetApp, right? 579 00:32:20,639 --> 00:32:23,219 Really what you're replicating underneath the NetApp is file. 580 00:32:23,229 --> 00:32:25,929 It's a file device, but underneath you're replicating blocks. 581 00:32:27,099 --> 00:32:32,579 Um, all that, all that discussion just from one word. 582 00:32:33,079 --> 00:32:40,079 Um, so, you can also have a hybrid of these two things. 583 00:32:40,399 --> 00:32:41,899 Can you think of an example of that? 584 00:32:41,909 --> 00:32:41,929 Is 585 00:32:42,299 --> 00:32:42,609 Yeah. 586 00:32:42,669 --> 00:32:44,909 So take your bank example, right? 587 00:32:44,909 --> 00:32:47,769 So you're a financial customer in New York. 588 00:32:47,799 --> 00:32:50,289 You want to make sure that your data is synchronously 589 00:32:50,289 --> 00:32:52,499 protected to someplace nearby. 590 00:32:52,499 --> 00:32:55,519 So maybe you go over the river to New Jersey using synchronous 591 00:32:55,569 --> 00:32:59,579 replication, and now you need to make sure that you're protected in case 592 00:32:59,589 --> 00:33:01,699 something happens in the East coast. 593 00:33:01,979 --> 00:33:07,189 And so you might use async replication and send that copy off to say, Utah. 594 00:33:08,659 --> 00:33:09,899 that when we go through the woods? 595 00:33:10,179 --> 00:33:10,599 Yes. 596 00:33:13,059 --> 00:33:13,849 See what I did there? 597 00:33:14,499 --> 00:33:15,929 Over the river and through the woods? 598 00:33:16,299 --> 00:33:21,569 Um, yeah, so you might, and that was, I remember back in the day, 599 00:33:21,579 --> 00:33:24,759 we had a synchronous copy that was literally like right next door. 600 00:33:24,769 --> 00:33:28,619 I mean literally, when I say next door, I mean Like it's the next 601 00:33:28,619 --> 00:33:33,789 rack over, um, that was, uh, like an A or asynchronous replication. 602 00:33:33,789 --> 00:33:37,149 And then actually, will you remember Symmetrics and or, 603 00:33:37,149 --> 00:33:39,009 or, or EMC and, and NetApp? 604 00:33:39,249 --> 00:33:40,929 They, you'd have like three. 605 00:33:41,544 --> 00:33:44,894 You'd have like four storage arrays, right? 606 00:33:44,894 --> 00:33:45,254 You'd have the, 607 00:33:45,459 --> 00:33:46,039 Oh, you can have 608 00:33:46,039 --> 00:33:46,769 a lot more. 609 00:33:46,799 --> 00:33:47,079 Yeah, 610 00:33:47,524 --> 00:33:50,604 you'd have the synchronous that was right next to it, the asynchronous 611 00:33:50,604 --> 00:33:51,644 that was down the street. 612 00:33:51,664 --> 00:33:53,704 And then another asynchronous that was the other. 613 00:33:53,704 --> 00:33:54,064 Yeah, 614 00:33:54,279 --> 00:33:58,309 and sometimes there are customers who could use it for like data 615 00:33:58,309 --> 00:34:00,229 distribution use cases, right? 616 00:34:00,229 --> 00:34:01,029 So I need to 617 00:34:01,029 --> 00:34:04,729 make sure that my database is available locally in different countries. 618 00:34:04,739 --> 00:34:06,149 So I'm just going to replicate it all. 619 00:34:07,234 --> 00:34:07,464 yeah. 620 00:34:07,464 --> 00:34:12,374 So synchronous, both forms of replication have a lot more applications 621 00:34:12,494 --> 00:34:14,134 than just backup and recovery. 622 00:34:16,314 --> 00:34:23,874 Um, so I'm glad you mentioned, you know, or you VMs, there is another. 623 00:34:25,224 --> 00:34:33,004 Not file and not VM thing that gets replicated, which is very, where 624 00:34:33,004 --> 00:34:35,904 we still have sort of the same discussion about synchronous versus 625 00:34:35,904 --> 00:34:38,594 asynchronous, and that is databases, 626 00:34:39,709 --> 00:34:41,959 Application level synchronous 627 00:34:43,164 --> 00:34:43,604 right? 628 00:34:43,884 --> 00:34:47,684 And, and, and I'd say that in that case, basically. 629 00:34:48,114 --> 00:34:54,044 When we, again, that can definitely have two phase commit, right? 630 00:34:54,094 --> 00:34:55,104 So in the database. 631 00:34:56,174 --> 00:34:59,314 You're replicating a transaction or, or something. 632 00:34:59,334 --> 00:35:00,474 I don't have a better word. 633 00:35:00,474 --> 00:35:03,134 I know not every database has transactions, but I 634 00:35:03,144 --> 00:35:04,314 don't have a better word for 635 00:35:04,509 --> 00:35:07,139 It's the atomic unit, whatever it is, or sorry, the unit of 636 00:35:07,369 --> 00:35:11,569 Yeah, an atomic unit of a thing, you changed a thing in the database, right? 637 00:35:12,509 --> 00:35:15,869 And you're replicating that, rather than the blocks underneath. 638 00:35:16,429 --> 00:35:19,519 And, well, you could be replicating the blocks underneath, and that's 639 00:35:19,519 --> 00:35:20,389 what we're talking about over here. 640 00:35:20,389 --> 00:35:22,519 But at this point, we're talking about database level, 641 00:35:22,519 --> 00:35:23,989 application level replication. 642 00:35:24,439 --> 00:35:27,849 And when you do that, you have the choice of either immediate 643 00:35:27,899 --> 00:35:30,619 consistency, or eventual consistency. 644 00:35:30,919 --> 00:35:34,909 Which is essentially analogous to synchronous and asynchronous. 645 00:35:36,079 --> 00:35:39,459 And, and what made me think about it was when you were talking about that, 646 00:35:39,459 --> 00:35:45,859 there are other reasons that people replicate and, um, there are databases 647 00:35:45,889 --> 00:35:51,749 that allow replicating data, you know, across the world and the best. 648 00:35:52,159 --> 00:35:59,439 Example that a lot of people are used to is the DNS database, right? 649 00:35:59,739 --> 00:36:05,349 That is an eventually consistent, replicated, um, system. 650 00:36:05,619 --> 00:36:10,579 If you've never, if you've never made changes to DNS. 651 00:36:11,509 --> 00:36:13,499 Let me tell you, it can take a minute. 652 00:36:15,889 --> 00:36:20,059 I recently, literally in the last week or two, I've been making changes to 653 00:36:20,639 --> 00:36:25,669 various websites that I own to, you know, change their, uh, DNS entries 654 00:36:25,669 --> 00:36:32,709 and CNAME entries and things like that, and they don't all immediately happen. 655 00:36:33,159 --> 00:36:33,879 Um, 656 00:36:34,384 --> 00:36:34,884 And yeah, 657 00:36:34,999 --> 00:36:35,429 but 658 00:36:36,704 --> 00:36:38,324 they will eventually get there. 659 00:36:38,654 --> 00:36:44,564 That is essentially the database equivalent to, um, to, uh, 660 00:36:44,764 --> 00:36:45,994 asynchronous replication. 661 00:36:46,414 --> 00:36:48,534 Now, let me ask you a question. 662 00:36:49,264 --> 00:36:49,864 Prasanna, 663 00:36:49,909 --> 00:36:50,369 mm hmm. 664 00:36:51,264 --> 00:36:58,604 if replication is so amazing and we can have the tightest RPOs, and, and, and 665 00:36:58,714 --> 00:37:03,739 I think we can agree that Tighter RPOs are better than looser RPOs, right? 666 00:37:04,579 --> 00:37:09,969 An RPO of zero or a minute is way better than an RPO of 36 hours, which is what 667 00:37:09,969 --> 00:37:11,749 we typically get with a backup system. 668 00:37:12,249 --> 00:37:14,919 Why don't we do replication for everything? 669 00:37:14,929 --> 00:37:17,309 And by the way, money is not the issue. 670 00:37:18,039 --> 00:37:19,639 You knew what I was going to say, uh, 671 00:37:20,799 --> 00:37:24,169 It's not, well, it is an issue besides money, right? 672 00:37:24,319 --> 00:37:25,649 Because replication is 673 00:37:25,899 --> 00:37:26,659 yeah, so the 674 00:37:26,819 --> 00:37:27,489 don't we do that? 675 00:37:27,859 --> 00:37:34,079 so the biggest problem with replication is for most of the replication technologies, 676 00:37:34,129 --> 00:37:39,219 when you replicate it, you only have that one copy on your target system, right? 677 00:37:39,279 --> 00:37:45,274 And so, If you had a user who dropped a database table and you replicated that 678 00:37:45,274 --> 00:37:47,784 command over to your replica, guess what? 679 00:37:48,174 --> 00:37:51,914 It gets dropped on your replica as well, and you have no ability to recover. 680 00:37:52,924 --> 00:37:53,444 And 681 00:37:54,274 --> 00:37:59,824 so that's one of the biggest limitations of relying on replication, 682 00:38:00,574 --> 00:38:00,714 or at 683 00:38:00,799 --> 00:38:05,409 And same would be true of any change on the, on the primary system, which 684 00:38:05,409 --> 00:38:08,679 includes things like ransomware, right? 685 00:38:08,859 --> 00:38:11,289 So if there's a, if there's a hacker goes in. 686 00:38:11,564 --> 00:38:15,074 and deletes all your tables, or just, you know, corrupts your, your data, 687 00:38:15,404 --> 00:38:16,904 deletes all your files, whatever. 688 00:38:16,934 --> 00:38:20,224 It just, if a virus does, whatever, whatever, you know, if there's any 689 00:38:20,224 --> 00:38:24,054 kind of cyber attack on the primary system, it simply makes that attack more 690 00:38:24,054 --> 00:38:24,534 efficient, 691 00:38:24,724 --> 00:38:28,974 And because the entire purpose of replication is to create a duplicate 692 00:38:28,974 --> 00:38:31,004 copy on your target system, right? 693 00:38:31,614 --> 00:38:36,684 Immediately, if you ask for an RPO of zero, you're going to get an RPO of zero, 694 00:38:36,889 --> 00:38:42,689 now, now I will say, I will put a caveat that, wait until we talk about snapshots, 695 00:38:42,699 --> 00:38:45,029 we will come back to this specific point, 696 00:38:46,474 --> 00:38:46,854 Right. 697 00:38:47,284 --> 00:38:54,074 There, There, are, there are back backup data protection based systems 698 00:38:54,074 --> 00:38:57,094 that use replication at their core. 699 00:38:58,114 --> 00:38:59,404 And don't have this problem. 700 00:38:59,424 --> 00:39:01,524 This is just, just replication, right? 701 00:39:01,524 --> 00:39:03,544 It's like, why don't we use raid for everything? 702 00:39:03,544 --> 00:39:04,584 And then we don't need backup. 703 00:39:04,594 --> 00:39:06,844 Well, same exact reasons, right? 704 00:39:08,209 --> 00:39:08,529 Exactly. 705 00:39:09,024 --> 00:39:14,454 Uh, raid does help with media failure and equipment failure. 706 00:39:14,464 --> 00:39:15,644 And, um. 707 00:39:16,224 --> 00:39:24,454 Site failure and power failure and, and, and, and, but it is completely defenseless 708 00:39:24,454 --> 00:39:27,334 against cyber attacks and stupidity. 709 00:39:29,289 --> 00:39:30,299 Or logic issues. 710 00:39:31,684 --> 00:39:33,864 Well, I'm just, you're being nice. 711 00:39:34,034 --> 00:39:35,324 See, this is why this is, 712 00:39:35,439 --> 00:39:38,419 Well, I was thinking software bugs, not user logic. 713 00:39:38,434 --> 00:39:39,184 Oh, okay. 714 00:39:39,264 --> 00:39:40,454 Well, that's still stupidity. 715 00:39:40,454 --> 00:39:42,279 It's just, you know, Different 716 00:39:42,359 --> 00:39:42,639 Yes. 717 00:39:43,449 --> 00:39:45,119 person who made the bug. 718 00:39:45,629 --> 00:39:48,249 Um, well, this has been fun. 719 00:39:48,649 --> 00:39:56,969 Uh, but yeah, this whole thing of, um, this idea that replication is where 720 00:39:56,969 --> 00:39:58,859 we're continuously updating the data. 721 00:39:58,889 --> 00:40:04,419 Now, now that you see like this idea of, of, um, you know, why we were wrestling 722 00:40:04,419 --> 00:40:05,829 over the word continuous, right? 723 00:40:05,829 --> 00:40:06,529 Because. 724 00:40:06,884 --> 00:40:08,824 Is asynchronous continuous? 725 00:40:08,984 --> 00:40:11,014 I think it's still a continuous process. 726 00:40:11,014 --> 00:40:16,994 It's just continuous with an asterisk, continuous with, with, with a buffer. 727 00:40:17,494 --> 00:40:26,454 Um, and I think that, well, in fact, I know that today is. 728 00:40:26,839 --> 00:40:28,929 Way better than it was back in the day. 729 00:40:28,939 --> 00:40:33,999 You back in the day, you had to have the same vendor on both sides. 730 00:40:33,999 --> 00:40:37,159 It, it, it sold a lot of EMC, right? 731 00:40:37,529 --> 00:40:41,909 You had to have the same vendor because the replication was based on the box. 732 00:40:42,149 --> 00:40:45,069 And now there are a number of products. 733 00:40:46,054 --> 00:40:47,624 one of which we've had on here, right? 734 00:40:47,624 --> 00:40:52,284 We had Datacore on here, which, which does replication between, you know, 735 00:40:53,284 --> 00:40:55,804 uh, disparate, different architectures. 736 00:40:55,814 --> 00:40:59,544 You can have a very expensive primary system. 737 00:40:59,814 --> 00:41:01,944 And a less expensive target system. 738 00:41:01,944 --> 00:41:06,894 You can use it as a way to upgrade and move your technology. 739 00:41:06,894 --> 00:41:11,274 You can move your older systems to be the target system, knowing that if you 740 00:41:11,284 --> 00:41:17,434 need to use it in a disaster, you will suffer a performance loss, but you 741 00:41:17,434 --> 00:41:19,714 don't have to, like you did back in the 742 00:41:19,714 --> 00:41:19,984 day. 743 00:41:19,984 --> 00:41:23,454 You don't, you know, when you primer, you don't have to have the same, you know, 744 00:41:23,624 --> 00:41:25,364 and so you get, you could cost savings. 745 00:41:25,784 --> 00:41:28,394 You don't have to do it that way, but it gives you the flexibility. 746 00:41:29,619 --> 00:41:34,329 And I think that modern day replication systems are much more 747 00:41:34,449 --> 00:41:41,229 forgiving of things like You know, outages and, and things like that. 748 00:41:41,259 --> 00:41:41,679 Right. 749 00:41:41,779 --> 00:41:51,679 Um, and, but, you know, but they still don't protect you from, you know, mistakes 750 00:41:51,719 --> 00:41:57,169 and cyber attacks, which is why we have to talk about the alternatives, which we'll 751 00:41:57,169 --> 00:42:03,739 do on later episodes, but, uh, so you were, you were unusually, not unusually, 752 00:42:03,739 --> 00:42:09,079 you were excessively argumentative in this episode, but I thank you anyway. 753 00:42:09,184 --> 00:42:13,744 that, that, I try, I basically spent all of my, almost all of my career 754 00:42:13,854 --> 00:42:15,964 working on replication technology, so. 755 00:42:17,499 --> 00:42:17,519 Yeah. 756 00:42:17,529 --> 00:42:21,099 And I, I, yeah, you worked at a company that was like, it was trying 757 00:42:21,099 --> 00:42:23,949 to say, well, there's asynchronous and there's near synchronous. 758 00:42:23,949 --> 00:42:25,929 And I'm like, those are two words for asynchronous. 759 00:42:26,539 --> 00:42:29,929 As I was editing this episode, I realized that. 760 00:42:30,739 --> 00:42:35,689 I was being a little too pedantic about continuous or not continuous. 761 00:42:36,379 --> 00:42:40,819 The thing with replication that really sets it apart from other data 762 00:42:40,819 --> 00:42:46,579 protection technologies, is , one is that the copy is an actual copy. 763 00:42:46,579 --> 00:42:51,139 It is a, it looks exactly like the original, unlike what we do in the 764 00:42:51,139 --> 00:42:55,129 backup world, where we tend to put stuff in a container or something like that. 765 00:42:55,609 --> 00:42:57,409 Um, that's one big thing. 766 00:42:57,409 --> 00:43:01,849 That's separate separates replication from other backup technologies. 767 00:43:02,389 --> 00:43:07,429 And then also the idea is that it is, it is incrementally updating that. 768 00:43:07,759 --> 00:43:12,769 Whenever we do it, whether it's continuous asynchronous or even periodic. 769 00:43:13,399 --> 00:43:19,699 I really forgot about how, like there are vendors like NetApp. 770 00:43:19,999 --> 00:43:23,239 That actually do periodic replication. 771 00:43:23,479 --> 00:43:25,699 There's nothing wrong with periodic replication. 772 00:43:25,729 --> 00:43:27,229 It's still replication. 773 00:43:27,619 --> 00:43:31,609 Um, so you've got continuous asynchronous and then periodic 774 00:43:31,939 --> 00:43:36,379 that, what, what sets replication apart from everything else is this. 775 00:43:36,619 --> 00:43:39,769 Whenever we do the next replication. 776 00:43:40,009 --> 00:43:45,109 What we're doing is we're transferring the, the, the things, whether it's 777 00:43:45,109 --> 00:43:49,729 database records or blocks, we're transferring the things that have changed 778 00:43:49,729 --> 00:43:51,829 since the last time we replicated. 779 00:43:52,189 --> 00:43:53,899 So I hope that. 780 00:43:54,589 --> 00:43:56,299 Helps Muddy the waters. 781 00:43:56,569 --> 00:43:57,649 Just a little bit. 782 00:43:57,806 --> 00:44:01,356 You're either synchronous or you're not just like in. 783 00:44:01,751 --> 00:44:03,381 In the following episode, we will be talking about a 784 00:44:11,141 --> 00:44:18,131 term near continuous, which I actually coined, but, uh, a lot 785 00:44:18,131 --> 00:44:19,361 of people think isn't a thing. 786 00:44:20,551 --> 00:44:21,151 I don't know 787 00:44:21,151 --> 00:44:21,261 if 788 00:44:21,311 --> 00:44:23,701 think, they're like, you can't have... 789 00:44:23,991 --> 00:44:26,591 Then again, they'll say that continuous is a... 790 00:44:27,571 --> 00:44:31,461 Um, is, is, is a binary, uh, condition. 791 00:44:31,471 --> 00:44:37,061 So anyway, well, um, I want to again, uh, say thank you to our listeners. 792 00:44:37,071 --> 00:44:38,421 You are why we do this. 793 00:44:38,471 --> 00:44:42,681 Remember, this is an independent podcast and the opinions that you hear are ours 794 00:44:42,681 --> 00:44:44,651 I hope this episode has been helpful. 795 00:44:44,951 --> 00:44:45,711 That's a wrap.