1 00:00:00,081 --> 00:00:04,491 Listeners of this podcast have heard why snapshots aren't backup. 2 00:00:05,001 --> 00:00:08,721 You've also learned why replication isn't backup either. 3 00:00:09,111 --> 00:00:13,551 But what if I make a snapshot on one array and replicate it to another array? 4 00:00:13,821 --> 00:00:15,021 Is that a backup? 5 00:00:15,321 --> 00:00:16,971 A lot of people would say yes. 6 00:00:17,331 --> 00:00:21,321 We'll also need things like reporting and cataloging, of course, but I would 7 00:00:21,321 --> 00:00:26,151 argue that snap and replicate also known as near CDP is one of the most 8 00:00:26,151 --> 00:00:29,001 efficient ways we have of protecting data. 9 00:00:29,781 --> 00:00:32,631 Hi, I'm Debbie Curtis, press and AKA Mr. 10 00:00:32,631 --> 00:00:37,941 Backup, and each episode of this podcast, dives deep into a backup related topic. 11 00:00:38,391 --> 00:00:42,891 We turn unappreciated backup admins into cyber recovery heroes. 12 00:00:43,161 --> 00:00:45,411 This is the backup wrap up. 13 00:00:59,980 --> 00:01:00,760 Welcome to the show. 14 00:01:01,780 --> 00:01:03,070 Thanks for listening today. 15 00:01:03,130 --> 00:01:06,940 I am your host, w Curtis Preston, and I have with me the guy that 16 00:01:06,940 --> 00:01:09,040 made me wait for him today. 17 00:01:09,500 --> 00:01:11,570 Prasanna Malaiyandi 18 00:01:11,590 --> 00:01:12,850 I am good, Curtis. 19 00:01:12,850 --> 00:01:15,640 I am so sorry for making you wait. 20 00:01:16,660 --> 00:01:18,580 and, and why did I wait again? 21 00:01:18,640 --> 00:01:24,490 So you could finish the last few minutes of a series that you have already 22 00:01:24,805 --> 00:01:27,955 Well, it's, and it's not even the entire series, it is just 23 00:01:27,955 --> 00:01:29,365 the episode that I was on. 24 00:01:29,725 --> 00:01:33,355 Now, granted, I'm near the end of the show, so it is sort of getting 25 00:01:33,355 --> 00:01:38,455 to the cliffhanger phases, but I was enjoying my lunch while watching 26 00:01:38,460 --> 00:01:40,465 the last bits of a show, and 27 00:01:41,050 --> 00:01:41,680 Yeah. 28 00:01:41,935 --> 00:01:44,185 then Curtis, and I was like, Curtis, I need five minutes. 29 00:01:44,185 --> 00:01:45,835 And then I was like, no, I need seven minutes because 30 00:01:45,835 --> 00:01:46,975 there's still six minutes left. 31 00:01:47,875 --> 00:01:48,025 Well. 32 00:01:48,550 --> 00:01:50,560 It is time for the news of the week. 33 00:01:55,242 --> 00:01:59,587 the first news of the week falls into one of my favorite news categories. 34 00:01:59,617 --> 00:02:00,847 Do you know what category that is? 35 00:02:00,847 --> 00:02:04,207 Things that you should be backing up that people don't 36 00:02:04,207 --> 00:02:05,917 realize until the data's gone. 37 00:02:06,268 --> 00:02:08,188 Yeah, I was just gonna say, I told you so. 38 00:02:10,903 --> 00:02:12,283 So what do do you wanna do? 39 00:02:12,283 --> 00:02:14,203 You wanna jump right in on our first news 40 00:02:14,293 --> 00:02:14,503 yeah. 41 00:02:14,503 --> 00:02:18,703 So this is actually something that I ran into on Reddit, which 42 00:02:18,733 --> 00:02:20,773 I for some reason get cis admin. 43 00:02:21,313 --> 00:02:27,733 Subreddit, uh, articles in my feed and it was like, Hey, did anyone notice that 44 00:02:27,823 --> 00:02:30,193 they have data missing from Google Drive? 45 00:02:30,913 --> 00:02:33,013 And I was like, oh man, what is this? 46 00:02:33,018 --> 00:02:34,633 And then it slowly started picking up. 47 00:02:34,638 --> 00:02:37,243 I think the register carried it. 48 00:02:37,243 --> 00:02:39,198 Bleeping computer and other folks as well, but. 49 00:02:40,228 --> 00:02:43,738 Basically what happened is people realized all of a sudden that some 50 00:02:43,738 --> 00:02:49,348 of their data was gone and that they didn't have any of their files and 51 00:02:49,348 --> 00:02:51,808 other changes since May of this year. 52 00:02:52,673 --> 00:02:57,683 Since May of this year, and this is being recorded in the end of November, 53 00:02:57,688 --> 00:02:59,833 so that is a long amount of time 54 00:03:00,463 --> 00:03:03,223 and, and Google has officially responded. 55 00:03:03,793 --> 00:03:09,253 And what they're saying as I was looking at these, these instructions and, 56 00:03:09,253 --> 00:03:15,283 and it basically said like, um, don't mess around with your drive right now. 57 00:03:15,383 --> 00:03:15,763 Right. 58 00:03:15,973 --> 00:03:18,223 So they were, they're saying don't disconnect. 59 00:03:18,223 --> 00:03:20,533 Don't do any structural changes to your drive. 60 00:03:20,743 --> 00:03:26,413 And to me what that says is their pro, that there was a suggestion that maybe 61 00:03:26,413 --> 00:03:30,193 somebody did a rollback of some snapshot. 62 00:03:30,223 --> 00:03:30,493 Is that 63 00:03:30,658 --> 00:03:33,718 Yeah, and I think we should be clear, this isn't just general 64 00:03:33,718 --> 00:03:37,138 Google Drive, so if you just access it through the web portal, right? 65 00:03:37,408 --> 00:03:38,968 All of that stuff still works fine. 66 00:03:38,968 --> 00:03:39,688 That has all your data. 67 00:03:39,718 --> 00:03:44,668 This only specifically affected customers who were using Google 68 00:03:44,673 --> 00:03:47,548 Drive for desktop to connect. 69 00:03:47,608 --> 00:03:49,498 So that I, I gotta 70 00:03:49,618 --> 00:03:50,553 Oh, is that no longer 71 00:03:50,698 --> 00:03:50,908 I. 72 00:03:52,078 --> 00:03:57,388 I'm seeing comments from the, that was what we thought a few days ago, but if 73 00:03:57,388 --> 00:04:02,548 you follow some comments, and again, it we're, we're, we're coming this from, 74 00:04:02,608 --> 00:04:06,388 you know, from the outside and we're not personally being impacted, but 75 00:04:06,388 --> 00:04:10,108 there are people who are saying that they've never used the desktop version 76 00:04:10,198 --> 00:04:12,118 and they're experiencing the problem. 77 00:04:13,318 --> 00:04:16,618 Those people may be wrong, it's just a couple of people. 78 00:04:16,678 --> 00:04:20,968 Um, but they're saying that they're experiencing the problem, but. 79 00:04:21,463 --> 00:04:22,423 So I, whoa. 80 00:04:22,423 --> 00:04:24,883 Which is in, yeah, that's news because I was worried about 81 00:04:24,883 --> 00:04:25,873 that, so I went and looked. 82 00:04:25,873 --> 00:04:31,873 And Curtis, I know we do, we use OBS as a backup for us recording this podcast 83 00:04:31,873 --> 00:04:33,613 and we upload that to Google Drive. 84 00:04:33,733 --> 00:04:36,913 And I did go and check to make sure, because we just uploaded one a couple 85 00:04:36,913 --> 00:04:38,953 of weeks ago, and that still exists. 86 00:04:38,953 --> 00:04:42,703 So I don't know if whatever we had shared it with, it looks like 87 00:04:42,703 --> 00:04:44,953 not everyone is affected, but. 88 00:04:45,458 --> 00:04:45,808 right. 89 00:04:46,063 --> 00:04:50,113 It looks like there are some random set of folks who somehow, 90 00:04:50,113 --> 00:04:53,953 some reason are affected by having some of their data gone. 91 00:04:55,288 --> 00:04:59,398 Yeah, so it looks like, uh, I don't remember exactly where I read it, 92 00:04:59,403 --> 00:05:04,168 but the idea is that someone rolled, basically rolled the entire drive or, or 93 00:05:04,438 --> 00:05:11,338 a section of this entire drive back to, uh, essentially the end of April and. 94 00:05:11,968 --> 00:05:15,748 So, and that's consistent with what they're saying of like, don't do, 95 00:05:15,778 --> 00:05:20,248 don't do any work in this right now and don't do any structural changes. 96 00:05:20,248 --> 00:05:24,238 'cause what I think they're going to try to do is to basically undo that 97 00:05:24,243 --> 00:05:29,908 action, which would then put the, all of those same customers back to what 98 00:05:29,913 --> 00:05:32,128 happened before all of this happened. 99 00:05:32,458 --> 00:05:35,548 And if you're making any changes in there right now, those changes 100 00:05:35,598 --> 00:05:38,418 will be undone by that change. 101 00:05:38,838 --> 00:05:43,428 What's a little disconcerting is that there isn't, there's no, you know, we, 102 00:05:43,428 --> 00:05:49,613 we talk a lot about how companies respond and Google isn't doing those things. 103 00:05:50,358 --> 00:05:50,568 It's. 104 00:05:50,733 --> 00:05:53,193 very, very little information out there about this. 105 00:05:54,168 --> 00:05:57,978 Yeah, there's just this one page that it basically said, Hey, don't do anything. 106 00:05:57,978 --> 00:06:00,888 There isn't, I haven't seen any updated stories I checked before 107 00:06:00,888 --> 00:06:05,058 we recorded this, and I'm a little, a little concerned about that 108 00:06:05,058 --> 00:06:06,738 I'm also surprised that. 109 00:06:08,118 --> 00:06:13,218 They gave service engineering or whoever else the capability to even roll back 110 00:06:13,218 --> 00:06:19,458 production to a snapshot that far back without checks and balances in place. 111 00:06:19,458 --> 00:06:21,468 Now, I don't know the what happened, right? 112 00:06:21,468 --> 00:06:24,558 This is all just assumption, but it's a little scary that someone 113 00:06:24,558 --> 00:06:25,818 had that sort of capability. 114 00:06:27,303 --> 00:06:28,383 It's a lot scary. 115 00:06:28,653 --> 00:06:34,833 Uh, imagine if you're a company that is using this, you know, you've 116 00:06:34,838 --> 00:06:37,863 got all sorts of stuff stored in there and you just rolled it back. 117 00:06:38,493 --> 00:06:42,363 Uh, yeah, I, I, I hope that there's an update on this. 118 00:06:42,403 --> 00:06:46,063 I hope we know more than we know right now, but, uh, if you're, if you're 119 00:06:46,063 --> 00:06:48,793 a Google user, it's time to just double check what's going on in your 120 00:06:48,968 --> 00:06:49,258 Yeah. 121 00:06:49,363 --> 00:06:52,093 And this is one of the other reasons why you should back up 122 00:06:52,093 --> 00:06:53,713 your data, even if you use Google 123 00:06:53,998 --> 00:06:55,738 Yes, yes. 124 00:06:55,738 --> 00:06:59,263 This is, this is why I put it in the, I told you So category, you know, the, 125 00:06:59,338 --> 00:07:04,138 the Google, you know, the, the cloud is, is a magical place, but it's not magic. 126 00:07:04,188 --> 00:07:07,488 So, um, let's take a look at this other story. 127 00:07:07,488 --> 00:07:12,568 And it has to do with a ransomware attack on a hospital chain in 128 00:07:12,568 --> 00:07:14,458 Nashville, Tennessee, and they've got. 129 00:07:15,073 --> 00:07:19,483 30 hospitals and 200 care sites around the country. 130 00:07:19,843 --> 00:07:23,443 Oklahoma, Texas, New Jersey, New Mexico, Idaho, and Kansas. 131 00:07:24,313 --> 00:07:31,133 And they were forced to divert patients from a, a number of ERs and one of 132 00:07:31,133 --> 00:07:35,473 the other things was that people weren't able to book appointments 133 00:07:35,563 --> 00:07:39,973 at, um, you know, their usual doctor because the patient portal was down. 134 00:07:41,053 --> 00:07:42,223 I just wanna say. 135 00:07:42,778 --> 00:07:44,248 It wasn't that long ago. 136 00:07:44,248 --> 00:07:47,518 Do you remember when the ransomware groups, they specifically 137 00:07:47,518 --> 00:07:50,308 didn't target healthcare? 138 00:07:50,608 --> 00:07:53,458 Um, because it tend, you know, people can 139 00:07:53,458 --> 00:07:55,468 die, but that is 140 00:07:55,828 --> 00:07:57,028 clearly gone. 141 00:07:57,133 --> 00:08:02,053 And remember there was the case in Germany, I think, where a patient died 142 00:08:02,053 --> 00:08:06,283 because an ER was closed and they had to re reroute them to a different one. 143 00:08:06,883 --> 00:08:10,633 And that's, I think when it came out where ransomware actors were like, 144 00:08:10,633 --> 00:08:12,628 yeah, maybe we will avoid hospitals. 145 00:08:14,608 --> 00:08:16,438 Yeah, but clearly not here. 146 00:08:16,498 --> 00:08:16,798 Right. 147 00:08:16,828 --> 00:08:21,063 They targeted this group and, the only update that I've seen is that. 148 00:08:21,863 --> 00:08:25,193 They, they are starting to restore some services. 149 00:08:25,583 --> 00:08:28,553 The, the company said that they did notify law enforcement. 150 00:08:28,553 --> 00:08:32,873 It did say that they, um, that they contracted a cybersecurity firm. 151 00:08:32,903 --> 00:08:33,893 These are all good things. 152 00:08:33,893 --> 00:08:35,453 These are the things that we like to hear. 153 00:08:35,753 --> 00:08:37,523 These are what people should be doing. 154 00:08:38,183 --> 00:08:43,733 Um, but we don't yet know if they were able to restore services 155 00:08:43,733 --> 00:08:45,293 or if they paid the ransom. 156 00:08:45,713 --> 00:08:47,663 Uh, we don't, you know, we don't know yet. 157 00:08:47,663 --> 00:08:53,243 And I think the other big thing is these are your medical records, right? 158 00:08:53,248 --> 00:08:57,088 And another unintended consequence is some of these particular 159 00:08:57,088 --> 00:09:02,398 facilities provide specialized care for certain types of, uh, ailments. 160 00:09:02,818 --> 00:09:04,378 And if they're. 161 00:09:04,688 --> 00:09:06,878 They're providing that specialized care and then they're down. 162 00:09:06,878 --> 00:09:09,788 It's not like they can just divert that care to some other place. 163 00:09:10,328 --> 00:09:12,308 So yeah, this is a real mess. 164 00:09:12,338 --> 00:09:17,048 Um, you know, I just, the, the thing I think we can take away from this is what 165 00:09:17,408 --> 00:09:18,908 it's again, what, what I've already said. 166 00:09:18,908 --> 00:09:20,648 I like that they contacted the law enforcement. 167 00:09:20,648 --> 00:09:23,138 I like that they contracted with the cybersecurity professional. 168 00:09:23,528 --> 00:09:27,128 The key there is that you want to start having those conversations. 169 00:09:27,128 --> 00:09:30,968 Now you want to identify a cybersecurity firm that you can 170 00:09:31,268 --> 00:09:33,158 contract with, that you can work with. 171 00:09:33,518 --> 00:09:37,598 One of the ways to do this is to con, is to talk to a cybersecurity. 172 00:09:37,898 --> 00:09:43,778 Uh, like if you, if you have cybersecurity insurance, to talk to them, uh, and see 173 00:09:43,778 --> 00:09:49,088 if they can put you in touch with somebody now so that you can prepare, uh, you know. 174 00:09:49,348 --> 00:09:54,988 Rather than, um, going to Google and saying cybersecurity first, 175 00:09:56,438 --> 00:09:56,738 Yeah. 176 00:09:56,878 --> 00:09:58,378 the middle of your, uh, ransomware 177 00:09:58,378 --> 00:09:58,738 attack. 178 00:09:58,738 --> 00:10:00,890 So that's, uh, that's hopefully what we, yeah. 179 00:10:00,890 --> 00:10:01,760 A little bit too late. 180 00:10:01,925 --> 00:10:04,205 All right, well, that is the news of the week, 181 00:10:08,700 --> 00:10:09,000 All right. 182 00:10:09,000 --> 00:10:15,120 This week on the backup wrap up, we have another backup to basics 183 00:10:16,020 --> 00:10:23,730 topic, and I wanted to talk this week about near CDP and which is 184 00:10:23,735 --> 00:10:25,470 near continuous data protection. 185 00:10:25,860 --> 00:10:30,240 And I, I think in order to do that we have to sort of back up a little bit and 186 00:10:30,240 --> 00:10:33,330 talk about the things that we've talked about that have led up to this point. 187 00:10:34,290 --> 00:10:36,960 Uh, these are modern backup and recovery methods. 188 00:10:36,960 --> 00:10:40,620 Basically things that have been birthed in the last 20 years, 189 00:10:40,620 --> 00:10:42,150 basically in the 21st century. 190 00:10:42,990 --> 00:10:47,010 Before we talk about near CDP, I think we need to talk about the 191 00:10:47,010 --> 00:10:48,690 things that have led up to this point. 192 00:10:49,230 --> 00:10:53,820 And, uh, we're gonna talk about replication, snapshots, and what 193 00:10:53,820 --> 00:10:55,740 we call continuous data protection. 194 00:10:56,070 --> 00:10:59,130 So let's talk about replication first. 195 00:10:59,135 --> 00:10:59,765 Do you wanna take that on? 196 00:11:00,200 --> 00:11:05,360 Yeah, so replication is basically you're taking data in one system and 197 00:11:05,360 --> 00:11:06,830 replicating it to the other system. 198 00:11:06,830 --> 00:11:10,370 So the second system is an exact copy of the first system. 199 00:11:11,045 --> 00:11:14,645 And in the case of synchronous, there's no data loss, right? 200 00:11:14,765 --> 00:11:17,255 So your RPO is zero. 201 00:11:18,365 --> 00:11:21,245 And yeah, so it is in sync. 202 00:11:21,245 --> 00:11:22,625 It's basically a mirror. 203 00:11:22,625 --> 00:11:26,675 And that also means you don't have multiple versions on that secondary side. 204 00:11:27,065 --> 00:11:32,675 So if you have a logical corruption or you have a user error on the primary, 205 00:11:33,065 --> 00:11:35,945 it's just gonna replicate it blindly to the other side, and that's what you get. 206 00:11:36,335 --> 00:11:36,755 Exactly. 207 00:11:36,760 --> 00:11:39,995 It makes your stupidity just more effective is what the way I, the way I 208 00:11:39,995 --> 00:11:44,105 like to say it, and it doesn't matter whether you're, I mean, I suppose 209 00:11:44,105 --> 00:11:48,245 maybe if you had an asynchronous replication, you could, may, maybe 210 00:11:48,245 --> 00:11:51,215 there's a big enough buffer that maybe you could stop a disaster if 211 00:11:51,215 --> 00:11:52,535 you did something really stupid. 212 00:11:52,535 --> 00:11:55,385 But you'd really have to be on the ball, I would think, 213 00:11:55,445 --> 00:11:57,395 uh, to, to do that in general. 214 00:11:58,540 --> 00:12:00,425 The, the, the replication. 215 00:12:00,875 --> 00:12:04,925 Replication will be great for Dr when your site blows up, but 216 00:12:04,925 --> 00:12:07,925 it will be really worthless if you're the one that blew it up, 217 00:12:08,705 --> 00:12:08,925 Yep. 218 00:12:08,975 --> 00:12:12,425 If, if you had dropped a table or, or you got a ransomware attack, 219 00:12:12,430 --> 00:12:15,245 which I think we can all agree is. 220 00:12:15,725 --> 00:12:18,425 Uh, a big deal, right, right now, 221 00:12:18,710 --> 00:12:19,100 Oh yeah. 222 00:12:19,445 --> 00:12:21,970 Uh, and by the way, each of these that we're summarizing have their 223 00:12:21,970 --> 00:12:23,740 own episodes back before the episode. 224 00:12:23,740 --> 00:12:28,120 So, so if you don't, if you're not familiar with these topics, these, 225 00:12:28,180 --> 00:12:29,470 this is just a review of them. 226 00:12:29,500 --> 00:12:30,880 They, they each have their own episodes. 227 00:12:31,375 --> 00:12:31,615 Yeah. 228 00:12:31,825 --> 00:12:36,595 So I think next in the list of topics, I think we talked about CDP next. 229 00:12:37,315 --> 00:12:38,995 So do you wanna talk about continuous. 230 00:12:39,925 --> 00:12:40,105 Yeah. 231 00:12:40,105 --> 00:12:44,965 So basically continuous data of protection is replication with a back button, right? 232 00:12:44,970 --> 00:12:50,245 It, it, it, it works very similar to replication except that the way it 233 00:12:50,245 --> 00:12:55,135 stores the data on the other end, it does it in such a way that you can bring. 234 00:12:55,585 --> 00:12:59,305 The, you know, the destination back from the bad thing, right? 235 00:12:59,355 --> 00:13:02,925 The great thing about replication is that it's incremental, right? 236 00:13:02,925 --> 00:13:06,855 That it's block level and it, and, and it, you know, it can keep up with, you 237 00:13:06,855 --> 00:13:11,175 know, relatively speaking, real time of what's going on in your production site. 238 00:13:11,715 --> 00:13:14,955 The bad thing about replication is the exact same thing, right? 239 00:13:15,255 --> 00:13:20,205 So, so CDP gives you the ability to go back in time. 240 00:13:20,795 --> 00:13:25,145 If you did something stupid, like drop a table, get a ransomware attack, have 241 00:13:25,145 --> 00:13:28,505 some sort of logical corruption, it gives you the ability to go back in time. 242 00:13:28,685 --> 00:13:30,815 It has a couple of different ways that it does that. 243 00:13:31,325 --> 00:13:32,225 Um. 244 00:13:32,265 --> 00:13:32,775 amazing. 245 00:13:32,775 --> 00:13:34,275 Curtis, why isn't everyone using 246 00:13:34,425 --> 00:13:38,685 Yeah, it wa if, if we were having this conversation, say 20 years 247 00:13:38,685 --> 00:13:40,755 ago, everybody was gonna do CDP. 248 00:13:41,145 --> 00:13:44,085 Uh, the only problem is it's, it is expensive af right? 249 00:13:44,115 --> 00:13:48,405 Uh, not just the cost of the software itself, it's also the cost of all of the 250 00:13:48,405 --> 00:13:52,540 IO and all of the storage required to restore essentially every single change. 251 00:13:53,640 --> 00:13:58,530 From, you know, during the entire recovery continuum that you are, uh, 252 00:13:58,650 --> 00:14:05,760 trying to be able to support and, uh, the, and, and so there are very few 253 00:14:06,120 --> 00:14:08,790 actual, I think, true CDP products. 254 00:14:08,795 --> 00:14:11,850 There are some that are very specific, like Zerto, I think, 255 00:14:12,240 --> 00:14:13,800 uh, would be a CDP product. 256 00:14:14,160 --> 00:14:18,000 The, there are some, uh, the EMC recover point. 257 00:14:18,000 --> 00:14:22,230 I know that a couple of the other products that I tracked have now been 258 00:14:22,230 --> 00:14:27,120 acquired by other companies and they're just a product on their portfolio. 259 00:14:27,750 --> 00:14:33,480 The, um, but the, basically the problem is it's just too dang expensive, especially 260 00:14:33,480 --> 00:14:34,710 if we're gonna use it for everything. 261 00:14:35,280 --> 00:14:35,730 Right. 262 00:14:36,120 --> 00:14:39,990 Um, and then we have snapshots. 263 00:14:39,990 --> 00:14:41,760 Now you used to work at a company that. 264 00:14:42,120 --> 00:14:43,830 Did a snapshot or two. 265 00:14:43,920 --> 00:14:49,140 And by snapshots we mean storage snapshots, not the ones up in 266 00:14:49,140 --> 00:14:51,300 AWS, which are entirely different. 267 00:14:51,900 --> 00:14:52,230 Yeah. 268 00:14:52,635 --> 00:14:58,155 So storage snapshots let you take a virtual copy of a particular volume 269 00:14:58,160 --> 00:15:02,865 file system, et cetera, and keep it there so you can quickly go back to it. 270 00:15:03,255 --> 00:15:08,145 If you need to restore really rapidly, it's all stored locally, which is great. 271 00:15:08,540 --> 00:15:11,990 And some companies, actually, I would probably say most companies these 272 00:15:11,990 --> 00:15:15,110 days allow users to browse snapshots. 273 00:15:15,440 --> 00:15:17,810 So they don't need to call up the IT help desk and be like, Hey, 274 00:15:17,810 --> 00:15:20,480 can you restore this file for me that I accidentally deleted? 275 00:15:20,870 --> 00:15:22,760 It's already there in the system. 276 00:15:22,765 --> 00:15:25,460 They can manually browse it, they can pull the data out themselves, 277 00:15:25,460 --> 00:15:26,810 self service, it's awesome. 278 00:15:26,810 --> 00:15:29,780 Saves the backup team a bunch of time having to do restores. 279 00:15:30,650 --> 00:15:34,850 The downside of snapshots though, is it's on the local system. 280 00:15:35,775 --> 00:15:39,855 And when we talk about backups and the purpose of backups, you wanna 281 00:15:39,855 --> 00:15:42,615 make sure you have a copy that's independent from that primary copy. 282 00:15:43,185 --> 00:15:46,935 When you have a snapshot, if something happens to that system, if someone deletes 283 00:15:46,935 --> 00:15:52,965 that volume, then that snapshot is gone and you've lost your quote unquote backup. 284 00:15:53,415 --> 00:15:56,055 So a snapshot is not a backup. 285 00:15:56,085 --> 00:15:58,785 And I will caveat that with what Curtis said earlier. 286 00:15:59,640 --> 00:16:06,270 Snapshots have changed their names based on what the vendor decides to implement. 287 00:16:06,600 --> 00:16:12,630 So an EBS snapshot isn't really the same as what I've just been talking about. 288 00:16:12,630 --> 00:16:14,040 It is completely different. 289 00:16:14,040 --> 00:16:19,260 They actually make a copy into AWS S3 that is independent from the production, 290 00:16:19,650 --> 00:16:23,370 and therefore it doesn't follow what we've been calling snapshots, 291 00:16:24,120 --> 00:16:25,950 even though AWS calls it a snapshot. 292 00:16:26,670 --> 00:16:30,690 Yeah, exactly, and, and I think they're not the only cloud vendor to do that. 293 00:16:31,170 --> 00:16:35,220 I also know, for example, our previous employer calls their backups. 294 00:16:35,220 --> 00:16:38,280 They call them snapshots, which I didn't like it when I worked there and 295 00:16:38,280 --> 00:16:39,540 I don't like, I still don't like it. 296 00:16:39,870 --> 00:16:43,260 But yeah, so when we're talking about snapshots here, we're talking about 297 00:16:43,265 --> 00:16:47,370 storage snapshots, like what you would see in a NetApp or, uh, and there 298 00:16:47,370 --> 00:16:48,660 are different kinds of snapshots. 299 00:16:48,660 --> 00:16:49,500 There's copy on, right? 300 00:16:49,505 --> 00:16:50,675 There's redirect on, right. 301 00:16:50,850 --> 00:16:52,650 And again, there is a whole separate. 302 00:16:54,180 --> 00:16:56,850 Episode just on that topic. 303 00:16:57,510 --> 00:17:03,510 So my memory is that I coined the term near CDP back in the day. 304 00:17:04,020 --> 00:17:07,320 They just, they just called it snapshots and replication. 305 00:17:07,590 --> 00:17:10,770 And as you may recall, CDP was all the rage. 306 00:17:11,190 --> 00:17:13,470 And I remember thinking that. 307 00:17:14,310 --> 00:17:15,960 CDP was very expensive. 308 00:17:16,080 --> 00:17:20,775 And because of that, very few people are going to use it. 309 00:17:20,835 --> 00:17:25,305 They might use it for their severely, like tier one applications, but they're not 310 00:17:25,305 --> 00:17:29,235 gonna use it for regular every day data. 311 00:17:29,355 --> 00:17:35,535 And what was more common back in that time was that most people would use. 312 00:17:36,030 --> 00:17:38,280 NetApps for that type of data. 313 00:17:38,640 --> 00:17:42,270 I mean, at that time, NetApp was kind of, you know, ruling the roost 314 00:17:42,270 --> 00:17:44,070 of the, of the NA world, right? 315 00:17:44,100 --> 00:17:48,300 Network attached storage, and they were very big on snapshots and 316 00:17:48,300 --> 00:17:50,520 then replicated snapshots, and they 317 00:17:50,520 --> 00:17:51,090 and replicate. 318 00:17:51,660 --> 00:17:51,690 I. 319 00:17:52,080 --> 00:17:55,320 Um, you know, you could do multiple tiers of that. 320 00:17:55,320 --> 00:17:57,265 They were happy and you could, you could 321 00:17:57,420 --> 00:17:57,810 Yep. 322 00:17:57,870 --> 00:17:59,760 Replicate the data all around the world. 323 00:18:00,090 --> 00:18:00,780 exactly. 324 00:18:00,785 --> 00:18:01,410 Exactly. 325 00:18:02,070 --> 00:18:05,850 And I liked the term near continuous. 326 00:18:05,850 --> 00:18:11,430 And I remember, um, one of the folks that I interfaced with was, um, uh, 327 00:18:11,430 --> 00:18:14,250 storage Zilla, which is, uh, mark Toomey. 328 00:18:14,610 --> 00:18:16,560 Uh, he lives over there in Cork. 329 00:18:16,935 --> 00:18:22,725 And, uh, that was my, that was my attempt to do a cor for anyone who listens there. 330 00:18:23,295 --> 00:18:26,865 And I remember he just, he just really hated my term. 331 00:18:26,895 --> 00:18:32,625 Like, he's like, continuous is a binary term, you know, like, like immutable. 332 00:18:32,715 --> 00:18:33,795 It's a binary term. 333 00:18:33,800 --> 00:18:35,235 It's either continuous or it's not. 334 00:18:35,385 --> 00:18:37,065 You can't be near continuous. 335 00:18:37,335 --> 00:18:40,005 Like, like it's like saying you're near pregnant, right? 336 00:18:40,275 --> 00:18:41,775 Pregnant is a binary term. 337 00:18:41,955 --> 00:18:45,165 And I'm like, yes, but we do use the word like nearly dead. 338 00:18:45,355 --> 00:18:46,496 Right there. 339 00:18:46,675 --> 00:18:54,055 There aren't times when we do put the word near next to a binary term, and I 340 00:18:54,055 --> 00:19:00,505 just felt that this was a world that was much closer to continuous than it 341 00:19:00,505 --> 00:19:02,455 was to what we thought of as backup. 342 00:19:02,815 --> 00:19:07,105 Backup at that time, and honestly, even to today. 343 00:19:07,920 --> 00:19:09,600 I think, I don't know. 344 00:19:09,660 --> 00:19:12,000 This is one of those, like, I don't know for a fact, but I'm 345 00:19:12,000 --> 00:19:15,210 pretty darn sure that most people still just back up every night. 346 00:19:15,975 --> 00:19:16,275 Yep. 347 00:19:16,710 --> 00:19:17,130 Right. 348 00:19:17,355 --> 00:19:22,665 It's like if your RPO is 24 hours or less, you are probably doing some 349 00:19:22,665 --> 00:19:28,095 form of, I'm just gonna use quote unquote replication, which is all the 350 00:19:28,100 --> 00:19:29,325 stuff we just talked about, right? 351 00:19:29,330 --> 00:19:34,905 Which includes Async sync, CDP, near CDP, which by the way, I also don't like 352 00:19:34,905 --> 00:19:36,735 the word near CDP, but that's just me. 353 00:19:37,590 --> 00:19:39,420 Well, you just have to get over it 'cause you're on, you're 354 00:19:39,420 --> 00:19:40,890 on the podcast now, buddy. 355 00:19:41,220 --> 00:19:45,210 Yeah, but, and then everything beyond 24 hours is probably backup. 356 00:19:45,210 --> 00:19:49,560 And I know as technologies change and everyone was like, Hey, database backups. 357 00:19:49,560 --> 00:19:51,600 I wanna do it more frequently than every 24 hours. 358 00:19:51,600 --> 00:19:54,240 Let me do log backups and all the rest of that stuff. 359 00:19:54,240 --> 00:19:59,130 That's when things sort of backup, sort of started reducing the RPO 360 00:19:59,730 --> 00:20:00,150 Right? 361 00:20:00,210 --> 00:20:04,260 and started moving down into that near CDP space. 362 00:20:04,695 --> 00:20:08,505 And, and again, if you're not familiar with the terms Rt, o and RPO, you 363 00:20:08,505 --> 00:20:11,805 really should be recovery time objective, recovery point, objective. 364 00:20:12,060 --> 00:20:15,225 It, it literally drives all backup design, right? 365 00:20:15,255 --> 00:20:20,325 Recovery time objective is how, how long have, have, you know, us and 366 00:20:20,325 --> 00:20:22,935 the, the, the, what do you call 'em? 367 00:20:22,935 --> 00:20:25,125 The, um, sorry, the stakeholders. 368 00:20:25,935 --> 00:20:29,775 What, what have we and the stakeholders agreed that it is an acceptable time 369 00:20:29,775 --> 00:20:31,995 for the recovery to take, right? 370 00:20:32,235 --> 00:20:36,255 We, we have to be able to bring the data back in four hours, right? 371 00:20:36,495 --> 00:20:41,625 And then our PO is how much time, how much data we've agreed 372 00:20:41,625 --> 00:20:43,485 that we are allowed to lose. 373 00:20:44,235 --> 00:20:48,345 By a measurement of time, not, you know, we could lose 10 gigabytes of data. 374 00:20:48,350 --> 00:20:52,365 It's, we could lose one hour or four hours or 24 hours worth of data. 375 00:20:52,365 --> 00:20:56,235 That's what RPO and those two things drive backup design 376 00:20:56,690 --> 00:21:00,645 Yeah, and I would say that it's also useful beyond backup design. 377 00:21:00,645 --> 00:21:01,905 I think anytime you're talking about. 378 00:21:02,355 --> 00:21:06,225 Data protection, disaster recovery, backup, all of these things 379 00:21:06,225 --> 00:21:07,785 always take into consideration. 380 00:21:07,785 --> 00:21:08,595 RTO and RPO. 381 00:21:09,120 --> 00:21:09,420 Yeah. 382 00:21:09,720 --> 00:21:11,730 Uh, no one cares about backup window anymore. 383 00:21:11,730 --> 00:21:16,200 It used to be that was that, that drove a lot of backup, uh, design. 384 00:21:16,200 --> 00:21:19,380 But, uh, you know, luckily we, we've, I think we've tackled the backup 385 00:21:19,385 --> 00:21:23,760 window problem, so you would probably call what we're about to talk about 386 00:21:23,760 --> 00:21:25,590 snapshots and replication instead 387 00:21:25,650 --> 00:21:26,790 Snap and replicate. 388 00:21:26,820 --> 00:21:32,580 And actually when we went back to the replication issue or replication 389 00:21:32,580 --> 00:21:37,500 episode, I would actually call async replication snap and replicate. 390 00:21:37,560 --> 00:21:41,640 But that's because of how I entered the storage space and 391 00:21:41,640 --> 00:21:43,440 the technology with NetApp. 392 00:21:44,160 --> 00:21:47,310 So that's what I, when I think of async replication, I 393 00:21:47,310 --> 00:21:48,300 think of snap and replicate. 394 00:21:48,765 --> 00:21:49,395 Interesting. 395 00:21:49,425 --> 00:21:52,545 Um, obviously it doesn't have to be snap and replicate. 396 00:21:52,595 --> 00:21:55,445 Ay replication could just have a buffer. 397 00:21:55,595 --> 00:21:56,735 Right, right. 398 00:21:56,900 --> 00:21:59,090 And a lag is just a snapshot. 399 00:21:59,095 --> 00:21:59,390 Right. 400 00:21:59,690 --> 00:22:01,550 So every six hours I do that. 401 00:22:01,555 --> 00:22:02,385 That's my lag. 402 00:22:02,990 --> 00:22:03,980 Gotcha, gotcha. 403 00:22:04,280 --> 00:22:05,720 Yeah, I, I would say that. 404 00:22:06,470 --> 00:22:10,940 Snap and replicate would be a way to do a sync replication for sure. 405 00:22:11,630 --> 00:22:16,490 And the, I, I think the more common way people would probably 406 00:22:16,490 --> 00:22:20,030 just use this term, uh, snap and replicate, and I'm fine with that. 407 00:22:20,420 --> 00:22:24,560 Uh, this is one where I, where I, I'm not going to battle for the term. 408 00:22:24,560 --> 00:22:28,010 I do like the term because I think it's a lot closer to continuous. 409 00:22:28,460 --> 00:22:29,030 What's that? 410 00:22:29,465 --> 00:22:29,705 Is it 411 00:22:29,810 --> 00:22:31,220 not, it's not trademarked. 412 00:22:31,460 --> 00:22:32,600 Feel free to use it. 413 00:22:32,850 --> 00:22:37,050 There are some systems where you don't make the snapshot on the primary system. 414 00:22:37,500 --> 00:22:40,200 You replicate the data, and then you make the snapshot over there. 415 00:22:40,200 --> 00:22:45,690 My problem with that is that when you're making the snapshot, you often have to. 416 00:22:46,335 --> 00:22:50,355 Interface with the thing that's writing the data to the snapshot, right? 417 00:22:50,355 --> 00:22:52,995 So you want to put Oracle in backup mode. 418 00:22:53,145 --> 00:22:57,585 Take a VSS snapshot, take a VMware snapshot, whatever it is, do the, 419 00:22:57,585 --> 00:23:01,580 do the thing that you need to do to get the data to be consistent. 420 00:23:01,940 --> 00:23:04,550 Then we take a snapshot, then we replicate that snapshot. 421 00:23:04,550 --> 00:23:05,600 I don't like replicating 422 00:23:05,615 --> 00:23:08,105 You don't, you don't, you know how people deal with that. 423 00:23:08,795 --> 00:23:11,495 I'm laughing at it because I've actually worked with groups and 424 00:23:11,495 --> 00:23:12,965 products that actually do that. 425 00:23:13,880 --> 00:23:14,300 Right, 426 00:23:14,735 --> 00:23:20,495 so, uh, one way you can solve what you're asking Curtis, is when you 427 00:23:20,495 --> 00:23:26,585 take your snapshot, you are queing the application and you issue the 428 00:23:26,590 --> 00:23:28,295 snapshot command to the target. 429 00:23:30,830 --> 00:23:36,470 But, but the problem with that is that we need to make sure that the bits are 430 00:23:37,175 --> 00:23:38,075 By QCing. 431 00:23:38,105 --> 00:23:38,405 Yep. 432 00:23:38,900 --> 00:23:40,220 I find, I find that very. 433 00:23:40,880 --> 00:23:41,960 I find that messy. 434 00:23:41,960 --> 00:23:42,650 I don't like it. 435 00:23:42,710 --> 00:23:42,800 I'm 436 00:23:42,965 --> 00:23:44,135 I It's not clean. 437 00:23:44,140 --> 00:23:44,825 Yeah, it's not 438 00:23:44,840 --> 00:23:45,860 Yeah, it's not as clean. 439 00:23:45,935 --> 00:23:46,970 I, I like clean. 440 00:23:47,330 --> 00:23:52,670 So when we're talking about, you know, near CDP or snapshots of replication, 441 00:23:53,000 --> 00:23:57,500 the really nice thing about it is that you can take essentially as many 442 00:23:57,500 --> 00:24:01,370 snapshots as you'd like to take within the limits of your storage system. 443 00:24:01,910 --> 00:24:05,000 I, I don't know what, do you know what ONTAP is up to these days? 444 00:24:06,170 --> 00:24:08,330 I am guessing probably a thousand. 445 00:24:08,840 --> 00:24:10,460 Yeah, that's a lot of snapshots, 446 00:24:11,180 --> 00:24:11,540 Yeah. 447 00:24:12,080 --> 00:24:14,780 You could take a snapshot every minute for the first hour. 448 00:24:14,780 --> 00:24:18,675 You could take a snapshot every hour after that, et cetera, et cetera, et you can 449 00:24:18,680 --> 00:24:20,300 take the snapshots as much as you want. 450 00:24:20,300 --> 00:24:24,440 And then basically what you're doing is you're replicating the changes that are 451 00:24:24,440 --> 00:24:26,480 contained within that snapshot, right? 452 00:24:26,960 --> 00:24:28,550 Um, and 453 00:24:28,575 --> 00:24:32,335 it's much more efficient because the storage array itself is 454 00:24:32,575 --> 00:24:35,725 keeping track computing those differences and sending 'em out. 455 00:24:35,995 --> 00:24:40,915 So it's much, much faster at doing that than reading the data out, figuring 456 00:24:40,915 --> 00:24:42,175 out the differences and sending it. 457 00:24:42,950 --> 00:24:43,400 Yeah. 458 00:24:43,400 --> 00:24:48,170 The challenge, I think, is that it is a storage level solution, 459 00:24:49,010 --> 00:24:53,630 which means that you need to do the interfacing up to the application. 460 00:24:53,930 --> 00:24:56,450 Sometimes the storage vendor can help you with that. 461 00:24:56,450 --> 00:24:58,040 Sometimes you're on your own. 462 00:24:58,565 --> 00:25:00,665 I've been in both scenarios. 463 00:25:01,835 --> 00:25:07,205 But at today though, Curtis, I wanna say most backup vendors 464 00:25:07,505 --> 00:25:10,925 integrate with most storage vendors. 465 00:25:11,405 --> 00:25:15,095 Or, and it may not be a hundred percent, but if you're picking like the major 466 00:25:15,095 --> 00:25:20,285 common ones, I'm guessing that most backup vendors have API integration 467 00:25:20,285 --> 00:25:24,995 with the storage vendors APIs in order to be able to trigger that snapshot. 468 00:25:26,540 --> 00:25:28,070 Yes, you can. 469 00:25:28,340 --> 00:25:32,690 So the question is, do they both interface with the application and with 470 00:25:32,690 --> 00:25:34,700 the storage snapshot at the same time? 471 00:25:35,810 --> 00:25:38,960 All I'm saying is you need to look into that, right? 472 00:25:39,110 --> 00:25:43,580 If you're taking a snapshot, you need to do your best to make sure 473 00:25:43,585 --> 00:25:50,000 that that snapshot is, is application consistent, um, ver versus the 474 00:25:50,000 --> 00:25:52,220 alternative, which is crash consistent. 475 00:25:52,685 --> 00:25:53,135 Right. 476 00:25:53,195 --> 00:25:56,705 And, and by the way, let, let me just, yeah, let me just use that, lemme just 477 00:25:56,705 --> 00:25:58,025 talk about that term for a minute. 478 00:25:58,295 --> 00:25:59,345 So if you are not. 479 00:26:00,395 --> 00:26:06,185 Making a snapshot with the, in, in partnership with an application, 480 00:26:06,635 --> 00:26:09,485 you're creating what's called a crash consistent snapshot. 481 00:26:10,025 --> 00:26:14,255 It's called that because it is as consistent as a crash. 482 00:26:14,735 --> 00:26:18,695 You, you're essentially like, it's like you flip the power switch off 483 00:26:18,815 --> 00:26:22,835 on an, on an operational storage array and you get what you get. 484 00:26:23,345 --> 00:26:23,885 Yes. 485 00:26:23,915 --> 00:26:26,135 Nothing is moving, but. 486 00:26:27,455 --> 00:26:28,595 Stuff was moving. 487 00:26:29,015 --> 00:26:31,120 So your mileage will vary. 488 00:26:31,970 --> 00:26:36,500 Well, nothing that was committed to DI or committed by the storage array. 489 00:26:36,500 --> 00:26:40,460 Any rights that were committed by a storage array has been preserved. 490 00:26:40,790 --> 00:26:44,420 Anything that was in flight may not have been committed. 491 00:26:44,930 --> 00:26:48,710 And as an application, you might have to do some recovery steps once 492 00:26:48,715 --> 00:26:50,990 a storage array comes back because you don't know what the state is 493 00:26:51,470 --> 00:26:51,760 Yeah, 494 00:26:52,100 --> 00:26:53,900 because some of those in-flight rights might have been 495 00:26:53,900 --> 00:26:54,950 committed, some may not have. 496 00:26:55,690 --> 00:27:00,470 And there are those who say, look, you know it works 99% of the time. 497 00:27:00,470 --> 00:27:01,880 You just take more snapshots. 498 00:27:01,880 --> 00:27:05,420 And if this snapshot doesn't work, maybe the previous snapshot will be, 499 00:27:05,540 --> 00:27:10,850 I'm just, I just, I try to avoid crash consistent snapshots whenever I can. 500 00:27:11,510 --> 00:27:11,990 Right. 501 00:27:12,995 --> 00:27:13,535 I would. 502 00:27:13,625 --> 00:27:14,795 I, I agree. 503 00:27:15,455 --> 00:27:20,585 For the most part, but there are cases where you could use a crash 504 00:27:20,585 --> 00:27:24,695 consistent snapshot at a more frequent basis and do like an application 505 00:27:24,700 --> 00:27:26,555 consistent snapshot, say once a day. 506 00:27:27,545 --> 00:27:30,995 So even though, so you can potentially 507 00:27:31,025 --> 00:27:32,735 have that as your backup of your 508 00:27:32,975 --> 00:27:33,245 Yeah. 509 00:27:33,815 --> 00:27:34,175 Yes. 510 00:27:34,355 --> 00:27:35,525 As a backup of your backup. 511 00:27:36,215 --> 00:27:36,545 Right. 512 00:27:36,545 --> 00:27:36,875 And that 513 00:27:36,875 --> 00:27:37,115 why? 514 00:27:37,145 --> 00:27:37,955 Why would you do that? 515 00:27:37,955 --> 00:27:40,295 I'm guessing the answer to that question would be, I. 516 00:27:40,610 --> 00:27:46,460 Perhaps if doing an application consistent snapshot has an impact on 517 00:27:46,460 --> 00:27:48,590 the performance of the application. 518 00:27:49,160 --> 00:27:52,220 Uh, I know in the case of Oracle, for example, when you put it in backup 519 00:27:52,220 --> 00:27:54,950 mode, it changes how it stores the redo logs, which could, which can 520 00:27:54,950 --> 00:27:56,660 have a minor impact on performance. 521 00:27:56,960 --> 00:27:59,720 And so perhaps you only do that once a day when nobody's using the 522 00:27:59,720 --> 00:28:01,310 database and then you do the crash. 523 00:28:01,310 --> 00:28:05,210 Consistent snapshots more often than that, I, I don't have a problem with that. 524 00:28:05,945 --> 00:28:06,245 Yeah. 525 00:28:06,995 --> 00:28:07,175 Yeah. 526 00:28:07,175 --> 00:28:10,775 But just relying on, yeah, and then you just take that snapshot 527 00:28:10,775 --> 00:28:11,855 and then replicate it off. 528 00:28:12,770 --> 00:28:19,220 Right, and the, the beautiful thing I think of snapshots and replication 529 00:28:19,225 --> 00:28:24,410 or near CDP, is that what you have? 530 00:28:24,740 --> 00:28:30,410 I'm glad that you find that term so amusing, what you have at the um, 531 00:28:30,620 --> 00:28:33,230 I think that's why I can say that I coined this term 'cause nobody 532 00:28:33,230 --> 00:28:36,260 else seems to want to use it, so I must have coined it and I love it. 533 00:28:36,680 --> 00:28:43,250 Um, so the, um, and it's in at least two books, two that I wrote. 534 00:28:43,460 --> 00:28:48,200 I don't know if it's anywhere, I don't know if it's in anywhere else, but, 535 00:28:48,230 --> 00:28:49,700 uh, I don't care what you'd call it. 536 00:28:49,730 --> 00:28:51,680 We're just talking about snapshots and replication. 537 00:28:51,800 --> 00:28:52,340 Just don't, 538 00:28:52,385 --> 00:28:53,945 the 15 years that I worked, 539 00:28:54,440 --> 00:29:00,680 don't call near C-D-P-C-D-P because NetApp definitely tried that one. 540 00:29:01,220 --> 00:29:01,640 Right? 541 00:29:01,700 --> 00:29:03,230 It is not continuous. 542 00:29:03,890 --> 00:29:07,850 The, the reason I was laughing is yeah, the 15 years that I worked 543 00:29:07,850 --> 00:29:13,040 in the storage industry, I'd never come across near CDP ever in the 544 00:29:13,045 --> 00:29:14,000 way that you're talking about it. 545 00:29:14,960 --> 00:29:15,200 Yeah. 546 00:29:15,650 --> 00:29:16,550 Yeah, yeah. 547 00:29:16,670 --> 00:29:17,090 And I'm fine. 548 00:29:17,120 --> 00:29:17,930 I'm fine with that. 549 00:29:18,230 --> 00:29:22,640 So again, I'm still taking credit for coining it, even if nobody uses it but me. 550 00:29:23,540 --> 00:29:25,940 It's not like the 3, 2, 1 rule or anything like that. 551 00:29:26,420 --> 00:29:27,140 Um, 552 00:29:27,330 --> 00:29:30,030 One other thing I wanted to mention about Snap and replicate that I don't 553 00:29:30,030 --> 00:29:33,390 think you covered yet is there are some vendors when you're doing Snap 554 00:29:33,390 --> 00:29:38,490 and replicate, you may not always have to have the same snapshot retention on 555 00:29:38,495 --> 00:29:40,740 your source array and your target array. 556 00:29:41,400 --> 00:29:45,300 You might, for instance, decide I'm only gonna keep 30 days worth of 557 00:29:45,300 --> 00:29:47,190 snapshots on my production system. 558 00:29:47,850 --> 00:29:51,540 And on my secondary system, I'm gonna keep 90 days worth of backup, uh, 559 00:29:51,540 --> 00:29:53,100 worth of snapshots so I can go back. 560 00:29:53,400 --> 00:29:58,740 Some systems allow you to set different retentions for snapshots on both sides. 561 00:29:59,040 --> 00:29:59,790 Some may not. 562 00:29:59,820 --> 00:30:03,060 So you should also, once again, look at your vendor, see what's possible. 563 00:30:03,360 --> 00:30:06,900 But I know for some folks, instead of having to go beyond that 30 days and 564 00:30:06,900 --> 00:30:10,140 say, okay, now I have to go to my backup infrastructure and pull data off of 565 00:30:10,140 --> 00:30:11,880 it, they might be able to say, okay. 566 00:30:12,025 --> 00:30:14,605 If it's not in production because it's beyond the 30 days, let me go 567 00:30:14,605 --> 00:30:16,645 check my secondary storage system. 568 00:30:17,065 --> 00:30:17,635 Okay? 569 00:30:17,635 --> 00:30:18,895 I have 90 days worth of snapshot. 570 00:30:18,895 --> 00:30:20,035 Can I restore the data from there? 571 00:30:20,925 --> 00:30:21,285 Right. 572 00:30:21,285 --> 00:30:21,555 Yeah. 573 00:30:21,555 --> 00:30:23,085 I, I, I love that idea, right? 574 00:30:23,115 --> 00:30:28,275 'cause it, one of the, one of the nice things about this idea is that you 575 00:30:28,280 --> 00:30:32,025 could have, maybe have a more expensive primary storage array and you can have 576 00:30:32,025 --> 00:30:35,175 a less expensive storage array that's based on Sada, for example, as you're. 577 00:30:36,270 --> 00:30:37,860 As your a backup system. 578 00:30:38,430 --> 00:30:43,620 And another thing, by the way, that you can do with a near CDP setup is that 579 00:30:43,980 --> 00:30:51,450 you can use that secondary site to give, I'll coin a new term near C DP plus. 580 00:30:52,005 --> 00:30:58,440 So, so near CDP plus is snap, replicate then back up, right? 581 00:30:58,440 --> 00:31:01,170 Use that snapshot that's on that. 582 00:31:01,770 --> 00:31:08,250 On that target and then back that up with some other method that isn't 'cause one 583 00:31:08,250 --> 00:31:13,470 of the downsides that some people pick on, uh, snapshot and replication is that 584 00:31:13,470 --> 00:31:19,770 your entire, basically storage and backup infrastructure are all within one vendor. 585 00:31:20,160 --> 00:31:24,990 And the, the worry is about this idea of a rolling bug that somehow 586 00:31:24,990 --> 00:31:27,120 takes out all of ONTAP one day. 587 00:31:27,690 --> 00:31:30,960 And it takes some, it takes everybody's primary, uh, and their 588 00:31:30,960 --> 00:31:32,880 secondaries along with it, so. 589 00:31:33,765 --> 00:31:41,055 The other issue also with that just snap and replicate, is if you say, have a 590 00:31:41,055 --> 00:31:46,635 backup proxy, so you're backing up your NASS system, you're using a proxy, which 591 00:31:46,635 --> 00:31:52,305 is basically a backup client to mount that snapshot and copy the data off. 592 00:31:52,755 --> 00:31:56,385 One of the challenges you have is when you mount it. 593 00:31:56,745 --> 00:31:58,155 To the storage array. 594 00:31:58,485 --> 00:32:01,905 That backup client looks no different than any other production client, 595 00:32:02,775 --> 00:32:08,385 and so when it ends up reading the data, it could cause performance impact 596 00:32:08,390 --> 00:32:11,565 because it has to read the entire file system on the source to figure out 597 00:32:11,565 --> 00:32:13,065 what's different and move the data off. 598 00:32:13,665 --> 00:32:18,165 This, of course, isn't integrating with the native snapshot storage APIs that the 599 00:32:18,165 --> 00:32:21,495 storage vendor provides, but is actually just reading it like a normal file system. 600 00:32:21,915 --> 00:32:24,495 When you do snap and replicate, you can actually mount the 601 00:32:24,495 --> 00:32:26,385 snapshot on the target system. 602 00:32:27,300 --> 00:32:30,810 And do your backup off of that, and therefore you're not affecting your 603 00:32:30,810 --> 00:32:34,950 production application because you're not impacting the IO on that system. 604 00:32:36,165 --> 00:32:43,965 Or you could use our friend Steven's favorite thing, the NDMP, 605 00:32:44,730 --> 00:32:45,120 Yep. 606 00:32:45,390 --> 00:32:46,320 You could use NDMP 607 00:32:46,515 --> 00:32:48,765 the network data management protocol. 608 00:32:48,765 --> 00:32:50,745 Which was, which was another solution. 609 00:32:50,745 --> 00:32:54,735 This is like to, this is technically off topic at this point, but there was this 610 00:32:54,735 --> 00:32:57,315 other way to back up, uh, NAS systems. 611 00:32:57,315 --> 00:32:58,035 Well, it's still around. 612 00:32:58,530 --> 00:33:01,050 Is that you can back up essentially to tape. 613 00:33:01,200 --> 00:33:05,430 DMP is generally meant to go to tape, uh, or to virtual tape. 614 00:33:05,520 --> 00:33:12,060 And, uh, it was meant to solve the issue that you mentioned because 615 00:33:12,600 --> 00:33:16,230 it would recognize it as a backup process and then deprioritize it. 616 00:33:16,860 --> 00:33:17,910 Uh, nice. 617 00:33:17,910 --> 00:33:18,090 It, 618 00:33:18,120 --> 00:33:18,300 I. 619 00:33:18,630 --> 00:33:19,050 Yep. 620 00:33:19,830 --> 00:33:22,650 There's another use case I wanna talk about with SNAP and Replicate, and it's 621 00:33:22,650 --> 00:33:29,100 not necessarily backup related, but there are many companies who have a distributed 622 00:33:29,100 --> 00:33:31,650 environment and they need performance. 623 00:33:32,115 --> 00:33:36,555 And so what they sometimes do is they will snap and replicate to multiple 624 00:33:36,555 --> 00:33:42,555 systems as kind of a fan, as kind of a fan out, and then they would have 625 00:33:42,555 --> 00:33:46,185 clients read from those target systems because they're consistent at some 626 00:33:46,185 --> 00:33:50,145 point, and use that as, uh, read. 627 00:33:50,970 --> 00:33:55,680 Optimization rather than all these systems trying to hit a single production system. 628 00:33:55,800 --> 00:33:59,520 And these secondary systems could be in the same building. 629 00:33:59,520 --> 00:34:01,110 It could be spread across the world. 630 00:34:01,115 --> 00:34:05,160 So you're now sort of doing read load balancing and you're leveraging 631 00:34:05,160 --> 00:34:09,510 the snap and replicate technology in order to move a copy of the 632 00:34:09,510 --> 00:34:11,520 data to close to the clients. 633 00:34:12,270 --> 00:34:15,450 Yeah, that, uh, by the way, that's, we, we, I don't think we really mentioned 634 00:34:15,450 --> 00:34:18,600 this before, but that's one of the best things here, is that that secondary 635 00:34:18,600 --> 00:34:22,830 target, and maybe even a tertiary target could be very far away because 636 00:34:22,830 --> 00:34:26,340 you're doing asynchronous replication, so you shouldn't be impacting the 637 00:34:26,340 --> 00:34:28,590 performance of the, of the primary array. 638 00:34:28,980 --> 00:34:30,390 Uh, at least not much anyway. 639 00:34:30,840 --> 00:34:35,310 Um, but that, that's, we can put that generally speaking as far 640 00:34:35,310 --> 00:34:36,570 as we want to from the primary. 641 00:34:37,070 --> 00:34:37,290 Yep. 642 00:34:38,050 --> 00:34:42,220 So I'd say the final thing that we would say about snapshots and 643 00:34:42,220 --> 00:34:47,290 replication is that that which we've already sort of alluded to, and that 644 00:34:47,290 --> 00:34:53,530 is that your backup vendor may support this as just another way to backup. 645 00:34:55,045 --> 00:34:55,945 Production data. 646 00:34:56,005 --> 00:34:56,395 Right. 647 00:34:56,965 --> 00:35:02,395 Most of the popular NAS vendors, especially nas, uh, are gonna 648 00:35:02,400 --> 00:35:04,105 have something like this. 649 00:35:04,435 --> 00:35:08,935 And then, uh, the more popular they are as a NAS product, the greater 650 00:35:08,935 --> 00:35:12,535 the possibility that they will integrate with a, a backup app. 651 00:35:12,595 --> 00:35:12,925 Right. 652 00:35:13,495 --> 00:35:20,995 So, um, this is just another way to backup up, especially your on-prem storage, 653 00:35:21,045 --> 00:35:24,825 although some of these vendors are now starting to offer actually for quite some 654 00:35:24,830 --> 00:35:29,775 time now, are offering cloud versions of these typically on-prem products. 655 00:35:30,525 --> 00:35:34,965 Um, so anything, can you think of anything else that we should talk about? 656 00:35:35,115 --> 00:35:35,595 Persona, 657 00:35:35,805 --> 00:35:38,235 I think that covers it all quite a 658 00:35:38,250 --> 00:35:44,100 it's just a, yeah, it's, it's, it's a great way, I think to have a very tight 659 00:35:44,610 --> 00:35:48,120 RPOA ver a really tight RTO, right? 660 00:35:48,120 --> 00:35:49,440 The RTO is really small. 661 00:35:49,470 --> 00:35:53,250 'cause basically you just start using the snapshot that, that you, 662 00:35:53,255 --> 00:35:54,840 that, that there's no restore. 663 00:35:55,350 --> 00:36:00,480 You can start using like the replicated snapshot immediately while you're 664 00:36:00,480 --> 00:36:02,100 restoring the primary snapshot. 665 00:36:02,130 --> 00:36:02,340 Right? 666 00:36:02,340 --> 00:36:04,260 That, you know, that's sort of the beautiful thing of, that. 667 00:36:04,260 --> 00:36:05,040 You might get a. 668 00:36:05,340 --> 00:36:06,870 Reduced performance. 669 00:36:07,410 --> 00:36:13,200 Um, but so, so the RTO, it can, you can meet a really tight RTO, you 670 00:36:13,200 --> 00:36:15,000 could do snapshots very frequently. 671 00:36:15,005 --> 00:36:19,560 So you can also meet a, uh, a really tight RPO, um, 672 00:36:20,295 --> 00:36:23,565 I did have one thing to add since you were just talking about it. 673 00:36:24,405 --> 00:36:26,955 So one thing we didn't talk about, which I think is. 674 00:36:28,575 --> 00:36:32,325 Super awesome about snapshots is we mentioned previously that snapshots 675 00:36:32,325 --> 00:36:35,805 are read only, which is great if you wanna pull some piece of data out 676 00:36:35,805 --> 00:36:37,335 of it or something else like that. 677 00:36:37,340 --> 00:36:41,355 But if you have applications where you need to actually do some recovery process, 678 00:36:41,955 --> 00:36:46,605 you can actually take a snapshot, which is read only, and most storage vendors allow 679 00:36:46,635 --> 00:36:52,845 you to clone it into a read write volume that you can then mount and connect to 680 00:36:52,845 --> 00:36:55,155 your and do your recovery process again. 681 00:36:55,515 --> 00:36:58,455 Again, without occupying the full amount of space, because it's all 682 00:36:58,455 --> 00:37:03,285 based on the snapshot, spins up a copy, allows you to do the recovery process. 683 00:37:03,285 --> 00:37:04,065 It's read, write. 684 00:37:04,065 --> 00:37:06,855 You could do all your testing, your restore verification, which 685 00:37:06,855 --> 00:37:10,185 we always talk about on the podcast is go restore your backups. 686 00:37:11,000 --> 00:37:14,150 And once you're done with that and you validate, you can quickly toss 687 00:37:14,150 --> 00:37:15,950 it away, and then you're good to go. 688 00:37:15,950 --> 00:37:20,360 So that's another benefit of sort of snap and replicate, is you can 689 00:37:20,365 --> 00:37:23,780 do all this verification on your secondary system without once 690 00:37:23,780 --> 00:37:24,980 again impacting your production. 691 00:37:25,440 --> 00:37:25,800 Right. 692 00:37:25,800 --> 00:37:30,930 There are a lot of advantages to the snap and replicate style of, 693 00:37:31,260 --> 00:37:32,790 you know, I'm calling it backup. 694 00:37:32,790 --> 00:37:33,150 Right. 695 00:37:33,630 --> 00:37:37,740 And, uh, this is one of them is, is that, you know, the, basically that the. 696 00:37:38,730 --> 00:37:42,930 The, the replicated copy stays in native format, and that leads, that 697 00:37:42,930 --> 00:37:44,730 leads to all sorts of possibilities. 698 00:37:44,730 --> 00:37:48,690 One of which I think probably the best of which is, is all of this you, you 699 00:37:48,690 --> 00:37:50,700 can do automated recovery testing. 700 00:37:51,105 --> 00:37:51,465 Right. 701 00:37:51,645 --> 00:37:54,225 Automated cloning and then, uh, tested recovery. 702 00:37:54,225 --> 00:37:57,645 And that way you're, you're validating the actual snapshot that 703 00:37:57,645 --> 00:37:59,085 you would like to use for recovery. 704 00:37:59,085 --> 00:38:04,755 So yeah, I, it's, it's a really great way, it's a really great way that I think 705 00:38:04,935 --> 00:38:06,705 maybe not enough people take advantage of. 706 00:38:06,705 --> 00:38:08,865 So hopefully, um. 707 00:38:09,125 --> 00:38:10,805 You know, you've learned a thing or two. 708 00:38:11,195 --> 00:38:14,165 And, uh, with that, I wanna say thank you for, uh, joining 709 00:38:14,165 --> 00:38:15,815 us and of course, persona. 710 00:38:15,995 --> 00:38:18,065 This was one where you really shined, I think. 711 00:38:18,065 --> 00:38:18,905 'cause you, you know, your, 712 00:38:19,725 --> 00:38:21,315 This is, this is what I lift and breathed. 713 00:38:21,465 --> 00:38:21,765 Yeah. 714 00:38:21,785 --> 00:38:23,105 Yeah, yeah, exactly. 715 00:38:23,105 --> 00:38:23,735 Exactly. 716 00:38:23,975 --> 00:38:27,215 So, uh, uh, great, great having you on again today. 717 00:38:28,125 --> 00:38:33,105 And I promise I won't harp on the near CDP term as much. 718 00:38:34,660 --> 00:38:35,770 It's gonna take off. 719 00:38:35,830 --> 00:38:37,390 Uh, we'll see. 720 00:38:37,420 --> 00:38:37,930 We'll see. 721 00:38:38,140 --> 00:38:42,400 Maybe I'll, maybe I'll do it in Spanish and then, uh, it'll be, it'll be better. 722 00:38:43,060 --> 00:38:45,550 Uh, and, uh, so thanks to the listeners. 723 00:38:45,550 --> 00:38:49,120 Thanks for, thanks for listening because, uh, that's really the 724 00:38:49,120 --> 00:38:50,320 only reason that we do this. 725 00:38:50,465 --> 00:38:51,065 That's a wrap.