1 00:00:00,050 --> 00:00:03,229 There are dozens of things that people do to protect their data 2 00:00:03,229 --> 00:00:07,219 from loss, but many of them are worthless when you actually need them. 3 00:00:07,879 --> 00:00:13,159 In this episode, we'll learn what turns a copy into a backup so that 4 00:00:13,159 --> 00:00:17,060 you can make sure that anything you think is a backup actually is one. 5 00:00:17,569 --> 00:00:20,599 We'll also talk about some important backup concepts like 6 00:00:20,599 --> 00:00:25,099 multiplexing, incremental backups, block-level incremental backups 7 00:00:25,340 --> 00:00:27,420 and source side deduplication. 8 00:00:27,979 --> 00:00:29,009 Hi, I'm W. 9 00:00:29,030 --> 00:00:31,220 Curtis Preston, AKA Mister backup. 10 00:00:31,490 --> 00:00:35,810 And I've been specializing in backup and disaster recovery for over 30 years. 11 00:00:36,109 --> 00:00:41,030 My podcast turns unappreciated backup admins into cyber recovery heroes. 12 00:00:41,359 --> 00:00:43,609 This is the backup wrap up. 13 00:01:04,407 --> 00:01:05,667 . Hi and welcome to the show. 14 00:01:05,688 --> 00:01:10,478 and I have with me a guy who I think is super jelly of the new 15 00:01:10,578 --> 00:01:12,598 toy that I put in yesterday. 16 00:01:12,938 --> 00:01:14,518 Prasanna Malaiyandi. 17 00:01:14,538 --> 00:01:15,428 How's it going, Prasanna? 18 00:01:15,428 --> 00:01:21,398 I'm good Curtis, and yes, I am jealous of your toy, but I will have to start 19 00:01:21,398 --> 00:01:26,445 sending you a bill for consulting fees, when you inevitably, or if 20 00:01:26,445 --> 00:01:28,135 you inevitably run into issues. 21 00:01:29,785 --> 00:01:30,255 Huh? 22 00:01:30,285 --> 00:01:35,385 Yeah, because as you recall, I didn't, I purchased this like without even talking 23 00:01:35,385 --> 00:01:37,825 to you, which is rather atypical of me. 24 00:01:38,395 --> 00:01:43,175 because I, we talk about so much and, and basically what we're talking about 25 00:01:43,205 --> 00:01:49,775 is a Firewalla, which I've had my eye on for a while and then after I realized, 26 00:01:49,785 --> 00:01:53,385 so I've switched internet service providers and now they're telling me 27 00:01:53,385 --> 00:01:56,795 that I'm hitting the bandwidth limit already and which is highly possible 28 00:01:56,795 --> 00:02:01,525 given that I do, this, I realized that I had no bandwidth monitoring tools. 29 00:02:01,525 --> 00:02:04,335 I have this really nice, mesh router system. 30 00:02:04,345 --> 00:02:11,505 Wire, the wire, the wifi mesh, but that's put been put an access 31 00:02:11,505 --> 00:02:15,545 point mode, which then of course offers no bandwidth monitoring. 32 00:02:15,975 --> 00:02:19,555 And then I had this Cox router, which offered me nothing. 33 00:02:19,745 --> 00:02:26,255 And so I replaced the Cox router with the Firewallet Purple SE and man. 34 00:02:26,465 --> 00:02:28,155 Super simple to put in there. 35 00:02:28,155 --> 00:02:31,095 And now I have these like super, stats. 36 00:02:31,845 --> 00:02:35,945 And I get these, I'm going to, at some point I'm going to have to disable 37 00:02:35,945 --> 00:02:41,275 the notifications because it's like Curtis is playing games on his phone. 38 00:02:42,450 --> 00:02:49,900 Curtis is watching YouTube videos on MacBook Pro A, right? 39 00:02:49,900 --> 00:02:52,600 It's literally, it's like Curtis has downloaded 3. 40 00:02:52,600 --> 00:02:57,690 56 gigabytes of video on his, and I'm like, okay, this 41 00:02:57,700 --> 00:02:58,815 is going to get old pretty 42 00:02:58,940 --> 00:02:59,830 I have two questions for you. 43 00:03:01,010 --> 00:03:01,410 Yeah, 44 00:03:01,430 --> 00:03:05,735 The first question is, Did you figure out what was consuming 45 00:03:05,735 --> 00:03:07,475 your data cap or data usage cap? 46 00:03:08,710 --> 00:03:09,560 not yet. 47 00:03:09,560 --> 00:03:14,120 Cause it's only, it hasn't even been 24 hours, but I do have a pretty good guess 48 00:03:14,130 --> 00:03:15,610 and I think it's right in front of me. 49 00:03:19,230 --> 00:03:21,170 we'll see what is weird. 50 00:03:21,170 --> 00:03:24,410 And again, I didn't want to talk about this too much, but what is weird is I 51 00:03:24,410 --> 00:03:31,190 get these, some of the notifications it's, Mac book pro uploaded 3. 52 00:03:31,190 --> 00:03:33,370 5 megabytes of data to LinkedIn. 53 00:03:34,315 --> 00:03:36,005 At 3 45 a. 54 00:03:36,005 --> 00:03:36,305 m. 55 00:03:36,815 --> 00:03:42,905 And I'm like, what, like, why is my laptop uploading three and a half 56 00:03:42,915 --> 00:03:49,325 megabytes of anything while it's just sitting here and I'm sleeping somewhere? 57 00:03:49,535 --> 00:03:50,165 that's weird. 58 00:03:51,765 --> 00:03:52,185 weird. 59 00:03:52,405 --> 00:03:52,695 Yeah. 60 00:03:52,695 --> 00:03:54,805 So anyway, so yeah, go ahead. 61 00:03:54,835 --> 00:03:55,195 Yeah. 62 00:03:56,795 --> 00:04:00,285 since you've decided to get rid of the Cox router, can you not just 63 00:04:00,285 --> 00:04:02,315 use your Wi Fi mesh as a router? 64 00:04:04,645 --> 00:04:07,805 I could have, but then I would have to completely redo my 65 00:04:07,805 --> 00:04:11,415 network architecture, which as you recall, was a really big thing. 66 00:04:12,635 --> 00:04:13,085 That's true. 67 00:04:13,345 --> 00:04:16,585 And I actually really liked the firewall features of this. 68 00:04:16,615 --> 00:04:18,825 That's, that was what would, what really drew me to it. 69 00:04:18,825 --> 00:04:22,255 And I'd been thinking about it and this was that final excuse to get it. 70 00:04:22,685 --> 00:04:25,415 and, I'm really enjoying the security aspects 71 00:04:25,480 --> 00:04:25,830 glad. 72 00:04:26,070 --> 00:04:28,280 So there, for people, if Mr. 73 00:04:28,280 --> 00:04:31,860 Backup can learn networking and firewalls, so can you. 74 00:04:34,595 --> 00:04:34,765 Yeah. 75 00:04:34,765 --> 00:04:36,905 It's certainly not my, my forte. 76 00:04:37,375 --> 00:04:40,515 but I want to talk, it's time for the news of the week. 77 00:04:42,635 --> 00:04:47,665 , the big news, I think, of the entire IG world, everybody seems to be 78 00:04:47,675 --> 00:04:50,505 talking about it, is this MGM hack. 79 00:04:51,475 --> 00:04:53,185 I can't, can you imagine? 80 00:04:53,235 --> 00:04:58,440 if you've been living in a hole, They shut down MGM and Caesars and all 81 00:04:58,440 --> 00:05:03,310 of the hotels attached to MGM and Caesars, which is like half the strip. 82 00:05:03,920 --> 00:05:08,530 And they shut down like card keys, slot machines, 83 00:05:08,530 --> 00:05:09,240 ATMs. 84 00:05:09,710 --> 00:05:10,620 everything. 85 00:05:10,870 --> 00:05:11,870 ATMs, 86 00:05:12,330 --> 00:05:15,390 So for, so for our listeners, Who may not know about this, 87 00:05:15,390 --> 00:05:17,510 MGM is a hotel chain, right? 88 00:05:17,510 --> 00:05:19,460 They have a bunch of things as well, right? 89 00:05:19,460 --> 00:05:24,730 Like various hotels like Caesars and MGM, and they are in Las Vegas 90 00:05:24,760 --> 00:05:26,780 and there are casinos, right? 91 00:05:26,780 --> 00:05:29,150 So you can stay there, you can gamble there, right? 92 00:05:29,180 --> 00:05:31,220 They make lots and lots and lots and lots of money. 93 00:05:32,610 --> 00:05:35,060 but not in the last week or so, 94 00:05:35,500 --> 00:05:39,070 And they got hit by a cyber attack, on the week of September 95 00:05:39,100 --> 00:05:41,310 20th or so, I'm guessing. 96 00:05:41,770 --> 00:05:49,830 yeah, and The I think that's the saddest part about this and by the way as of 97 00:05:49,830 --> 00:05:56,875 today There's been half a dozen lawsuits attached because there's, threat of a, 98 00:05:57,085 --> 00:05:59,275 PII leak, personal information leak. 99 00:05:59,945 --> 00:06:03,325 And so there's been all sorts of worries about that. 100 00:06:03,325 --> 00:06:05,485 So there's, a half a dozen, what do you call it? 101 00:06:05,485 --> 00:06:07,555 Class action or lawsuits that are attempting. 102 00:06:08,025 --> 00:06:11,505 To achieve class action status that have been filed. 103 00:06:11,945 --> 00:06:16,175 I think the saddest part here and the way I like and we'll put the 104 00:06:16,175 --> 00:06:21,245 link to this particular article in the show description, the 105 00:06:21,245 --> 00:06:23,725 heading here targeting layer eight. 106 00:06:24,435 --> 00:06:28,935 I've heard of the seven layer networking model again With my extensive 107 00:06:28,935 --> 00:06:30,965 networking experience, the OSI model. 108 00:06:31,485 --> 00:06:33,235 What is Layer 8, 109 00:06:34,195 --> 00:06:34,695 People? 110 00:06:35,015 --> 00:06:35,845 it's people. 111 00:06:35,885 --> 00:06:36,345 Yes. 112 00:06:36,725 --> 00:06:42,465 So layer 8 is people, which is probably the weakest part 113 00:06:42,475 --> 00:06:44,375 of the entire stack, I'd say. 114 00:06:45,085 --> 00:06:45,525 Yeah. 115 00:06:45,705 --> 00:06:46,825 You are the weakest link! 116 00:06:50,015 --> 00:06:51,565 Yeah, so what, how did they get in? 117 00:06:51,815 --> 00:06:55,651 So they basically targeted an employee, right? 118 00:06:55,651 --> 00:07:03,611 Who had the right level of access and They basically were able to gain access into 119 00:07:03,651 --> 00:07:06,321 their Okta environment as a super admin. 120 00:07:06,465 --> 00:07:07,815 But how did they do that? 121 00:07:08,235 --> 00:07:08,575 That's the 122 00:07:08,775 --> 00:07:10,175 Oh, so how did they do that? 123 00:07:10,185 --> 00:07:12,800 They basically tripped, tricked their IT help desk? 124 00:07:14,315 --> 00:07:16,935 That is so bad, right? 125 00:07:17,005 --> 00:07:18,245 they somehow got... 126 00:07:19,510 --> 00:07:21,380 Access to a privileged account, right? 127 00:07:21,380 --> 00:07:25,100 according to the powers that be that they stole a password or they 128 00:07:25,100 --> 00:07:27,260 hacked Active Directory somehow. 129 00:07:27,260 --> 00:07:32,691 So they were able to attempt to log in, but they were stopped by MFA 130 00:07:32,761 --> 00:07:35,580 which is a good thing, Okta, but then 131 00:07:35,630 --> 00:07:38,480 They were able to convince the help desk that they were the person in 132 00:07:38,480 --> 00:07:41,160 question and get them to reset MFA. 133 00:07:41,958 --> 00:07:42,728 Now here's a question. 134 00:07:42,728 --> 00:07:45,778 Do you think that employee is still there at the company? 135 00:07:47,388 --> 00:07:47,578 And 136 00:07:47,658 --> 00:07:48,198 is one of those 137 00:07:48,248 --> 00:07:49,668 you be blaming the person 138 00:07:51,418 --> 00:07:54,688 so I'm going to fast forward like 30 years. 139 00:07:54,828 --> 00:07:55,318 Okay. 140 00:07:55,738 --> 00:07:58,068 so 20, what would that be? 141 00:07:58,098 --> 00:07:59,468 2053. 142 00:08:00,038 --> 00:08:02,468 There's a guy he's going to be called Mr. 143 00:08:02,468 --> 00:08:09,888 MFA and he's going to have a podcast dedicated to security because like my 144 00:08:09,888 --> 00:08:12,678 career started with a screw up of this. 145 00:08:12,688 --> 00:08:15,988 not quite this magnitude, but my career started with this. 146 00:08:16,008 --> 00:08:21,883 And so I, My personal opinion, I don't know if this person is, has been fired. 147 00:08:23,073 --> 00:08:27,313 I think they should only be fired if they didn't follow the processes that had been, 148 00:08:27,498 --> 00:08:28,458 established and they 149 00:08:28,503 --> 00:08:29,313 set out for them. 150 00:08:29,323 --> 00:08:31,093 Potentially they should be disciplined. 151 00:08:31,103 --> 00:08:32,143 I don't know if firing, if. 152 00:08:32,533 --> 00:08:34,983 If termination is the appropriate, they should be disciplined. 153 00:08:35,373 --> 00:08:38,753 If they followed the procedures that had been laid out for 154 00:08:38,753 --> 00:08:41,893 them, process, people, right? 155 00:08:41,903 --> 00:08:42,993 Then technology. 156 00:08:43,013 --> 00:08:45,813 If they had been, we just had a podcast about that. 157 00:08:46,503 --> 00:08:48,343 If they followed the procedures. 158 00:08:48,713 --> 00:08:49,933 have been given to them. 159 00:08:49,943 --> 00:08:54,183 Then I think some massive leniency, then you update your procedures, 160 00:08:54,183 --> 00:08:55,203 et cetera, et cetera, et cetera. 161 00:08:55,503 --> 00:09:01,983 I think of a massive, outage that was caused at a major, software 162 00:09:02,263 --> 00:09:03,963 vendor that I worked with. 163 00:09:03,963 --> 00:09:09,253 I'm trying to be, I'm trying to be very cagey here, where the backup 164 00:09:09,343 --> 00:09:16,088 operator followed his Procedure that they had two parts of the app 165 00:09:16,108 --> 00:09:19,438 that had to be shut down in order to do a backup because they couldn't 166 00:09:19,438 --> 00:09:21,898 synchronize the two backup systems. 167 00:09:22,458 --> 00:09:27,718 And so every two weeks they would shut down these apps and, 168 00:09:27,828 --> 00:09:29,508 and then do a backup offline. 169 00:09:30,088 --> 00:09:31,498 And this person. 170 00:09:31,868 --> 00:09:36,828 The backup operator just did what they were told to do and shut down these 171 00:09:36,828 --> 00:09:42,748 apps at the most critical time of the year when the apps were needed, right? 172 00:09:42,958 --> 00:09:44,418 The person was just doing their job. 173 00:09:44,448 --> 00:09:45,698 That person should not be fired. 174 00:09:45,698 --> 00:09:48,953 That person should be You know, you changed the procedure. 175 00:09:49,123 --> 00:09:50,593 So I don't know what happened here. 176 00:09:50,633 --> 00:09:50,853 Yeah. 177 00:09:50,853 --> 00:09:51,373 You train. 178 00:09:51,373 --> 00:09:51,673 Yeah. 179 00:09:52,293 --> 00:09:55,143 I hope some leniency was there. 180 00:09:55,243 --> 00:09:58,523 if the person was fired and, I'd love to have them on the podcast. 181 00:10:01,013 --> 00:10:04,188 But anyway, what could we learn from this, from this news here? 182 00:10:04,188 --> 00:10:04,393 Prasanna? 183 00:10:05,003 --> 00:10:11,973 basically that, one is even if you have the greatest technologies in 184 00:10:11,983 --> 00:10:16,363 place and the greatest processes in place, people will always exist 185 00:10:18,273 --> 00:10:20,933 never underestimate the power of people to do dumb things. 186 00:10:22,233 --> 00:10:27,503 I do think that perhaps what's in order here is an update to process. 187 00:10:27,783 --> 00:10:31,423 And the process should be when, cause you have to be able to reset MFA. 188 00:10:32,463 --> 00:10:36,983 When resetting MFA, it should require many more, bells and whistles 189 00:10:36,983 --> 00:10:38,483 and levels of authentication. 190 00:10:38,483 --> 00:10:42,103 And we need to identify, we need to identify that this person who 191 00:10:42,133 --> 00:10:45,563 calls in that says that they're Steve, we need a way to identify 192 00:10:45,573 --> 00:10:47,033 that Steve is actually Steve. 193 00:10:48,118 --> 00:10:51,978 so you create a process around that, that really verifies that someone who they are, 194 00:10:52,165 --> 00:10:52,865 and especially, 195 00:10:53,040 --> 00:10:54,050 you reset MFA. 196 00:10:54,185 --> 00:10:58,515 and especially when it's someone of, with that level of privilege. 197 00:10:59,540 --> 00:11:02,640 Especially, super especially, that's not a word, but yeah, 198 00:11:02,730 --> 00:11:06,850 that, oh, I feel for these guys. 199 00:11:06,860 --> 00:11:12,860 keep, abreast of, this story because it is going to get worse before it gets better. 200 00:11:13,600 --> 00:11:15,850 And that's the news for this week. 201 00:11:18,010 --> 00:11:22,960 So what I thought we would talk about this week and the backup to basic series is, 202 00:11:23,370 --> 00:11:29,445 I've got it defined as, backup methods that support a traditional restore. 203 00:11:29,725 --> 00:11:33,015 So basically the backup methods that I grew up with that are still, 204 00:11:33,385 --> 00:11:33,645 in 205 00:11:33,860 --> 00:11:34,340 Relevant. 206 00:11:34,410 --> 00:11:34,750 Yeah. 207 00:11:34,815 --> 00:11:36,605 in, yeah, right? 208 00:11:37,575 --> 00:11:39,725 we like to live in a world where everybody's using the 209 00:11:39,725 --> 00:11:42,315 latest and greatest, right? 210 00:11:42,735 --> 00:11:46,075 And nobody's doing this old, full and incremental backups and stuff. 211 00:11:46,115 --> 00:11:46,885 Nobody's doing that. 212 00:11:48,245 --> 00:11:50,505 And that's just not right. 213 00:11:50,505 --> 00:11:55,105 So we need to talk about these, these methods and see what we can get out there. 214 00:11:55,745 --> 00:12:00,445 the first thing, I just have to, again, I'm, I'm, we're doing this based 215 00:12:00,445 --> 00:12:04,585 on, my book, Modern Data Protection, There's a cover for those of you 216 00:12:04,585 --> 00:12:09,415 watching via video, all, all three listeners that are watching via video. 217 00:12:10,040 --> 00:12:11,080 I think it's 10. 218 00:12:12,345 --> 00:12:13,135 There's maybe 10. 219 00:12:13,565 --> 00:12:15,865 the number's actually gone up since we've been putting them on YouTube. 220 00:12:15,900 --> 00:12:16,590 Oh, there you go. 221 00:12:18,175 --> 00:12:21,435 the, I've got this thing in here. 222 00:12:21,485 --> 00:12:24,555 so this is from chapter nine and talking about backup and 223 00:12:24,555 --> 00:12:25,685 recovery software methods. 224 00:12:25,685 --> 00:12:28,225 And the first thing I had in there was, is everything backup? 225 00:12:28,685 --> 00:12:31,395 So there was a time when backup was well defined. 226 00:12:31,610 --> 00:12:35,100 Backup was copy something to tape and then put that tape in a box, 227 00:12:35,100 --> 00:12:35,370 right? 228 00:12:35,721 --> 00:12:37,011 It was so simple back then. 229 00:12:37,686 --> 00:12:39,256 Yeah, it was so simple back then. 230 00:12:39,286 --> 00:12:39,796 Yes. 231 00:12:40,526 --> 00:12:44,156 so I, as quote, Mr. 232 00:12:44,156 --> 00:12:49,156 Backup, I see backup a lot broader than I think a lot of people do. 233 00:12:49,296 --> 00:12:51,986 A lot of people, when they say backup, they go, Oh, this isn't backup. 234 00:12:51,986 --> 00:12:56,076 This is, to me, backup is anything really that protects the data, the 235 00:12:56,076 --> 00:12:57,916 way backup protects data, right? 236 00:12:57,916 --> 00:13:02,936 And so I'm defining backup rather broadly as anything that is a copy of data 237 00:13:02,936 --> 00:13:04,726 stored separately from the original. 238 00:13:04,946 --> 00:13:08,186 that can be used to restore the original if it is damaged. 239 00:13:08,361 --> 00:13:12,061 There's a lot of things that qualify for backup as backup under that 240 00:13:12,376 --> 00:13:16,126 so let me just give you some examples and see if you think they qualify. 241 00:13:17,026 --> 00:13:17,486 Okay. 242 00:13:17,576 --> 00:13:19,196 So take a copy on tape, 243 00:13:20,586 --> 00:13:21,216 Yes. 244 00:13:21,326 --> 00:13:23,376 a copy in AWS S3. 245 00:13:23,596 --> 00:13:27,256 A copy of the data that's in S3, which is separate from 246 00:13:28,491 --> 00:13:28,621 The 247 00:13:28,646 --> 00:13:29,456 your not. 248 00:13:30,146 --> 00:13:30,526 Yeah. 249 00:13:30,536 --> 00:13:31,146 yes. 250 00:13:31,171 --> 00:13:31,541 okay? 251 00:13:31,961 --> 00:13:36,121 a copy replicated from one storage system to another storage 252 00:13:36,121 --> 00:13:37,491 system from the same vendor. 253 00:13:37,925 --> 00:13:39,265 as long as... 254 00:13:39,365 --> 00:13:43,495 there's a caveat here, because you used the word replication. 255 00:13:44,175 --> 00:13:49,725 I need the ability, is it replicated in such a way that if 256 00:13:49,725 --> 00:13:51,315 I damage production, so 257 00:13:51,585 --> 00:13:54,385 that doesn't qualify as being stored separately. 258 00:13:54,390 --> 00:13:58,800 Replicated with separate retention of the copies on the destination. 259 00:13:59,675 --> 00:14:00,205 Okay. 260 00:14:00,235 --> 00:14:01,185 Yes, I would call that a 261 00:14:01,340 --> 00:14:05,360 Okay, snapshots on a production system, on a production storage 262 00:14:05,380 --> 00:14:09,030 array that does not include AWS S3, 263 00:14:10,765 --> 00:14:13,845 thank you for, yeah, so snapshots on the same array. 264 00:14:15,465 --> 00:14:19,795 no, End of story, not a backup until it's copied somewhere 265 00:14:20,060 --> 00:14:22,740 Okay, and then doing what you were recently doing when 266 00:14:23,000 --> 00:14:25,040 editing the podcast, right? 267 00:14:25,050 --> 00:14:29,780 Downloading a copy from the cloud onto your local system, copying it 268 00:14:29,790 --> 00:14:32,810 to a different directory, and then copying it to yet a third directory. 269 00:14:34,490 --> 00:14:35,510 On your local system. 270 00:14:35,520 --> 00:14:38,053 Is that local system considered backups, each of those copies? 271 00:14:39,815 --> 00:14:42,545 again, we're storing the data in a separate place that 272 00:14:42,545 --> 00:14:44,455 has a separate risk profile. 273 00:14:45,265 --> 00:14:45,965 Etc. 274 00:14:46,015 --> 00:14:46,605 yes, 275 00:14:46,690 --> 00:14:48,510 As long as the copy, the original 276 00:14:48,520 --> 00:14:49,400 copy was in the, cloud. 277 00:14:49,780 --> 00:14:52,755 it's also about, the purpose of why I'm doing it, right? 278 00:14:52,775 --> 00:14:59,505 If the purpose of downloading that is to serve as possibly a backup, right? 279 00:14:59,705 --> 00:15:02,095 Because there's a lot of times that we download data That 280 00:15:02,255 --> 00:15:04,015 is not for backup purposes. 281 00:15:04,015 --> 00:15:07,325 Now, it could accidentally become a backup if it's the only 282 00:15:07,325 --> 00:15:08,625 copy that you have available. 283 00:15:08,645 --> 00:15:11,625 But, just because I copy doesn't necessarily make it a backup. 284 00:15:12,035 --> 00:15:13,015 It might be an archive. 285 00:15:13,090 --> 00:15:14,010 And then the last example. 286 00:15:14,900 --> 00:15:19,460 taking pictures on your iPhone and using iCloud to sync 287 00:15:19,490 --> 00:15:22,625 your copies to iCloud photos. 288 00:15:23,795 --> 00:15:25,045 Not a backup. 289 00:15:26,075 --> 00:15:26,665 Because, 290 00:15:26,825 --> 00:15:27,445 is that? 291 00:15:27,705 --> 00:15:29,155 for two reasons. 292 00:15:29,165 --> 00:15:30,945 One, which is really the primary. 293 00:15:30,955 --> 00:15:36,415 And that is specifically in terms of Apple iCloud. 294 00:15:36,990 --> 00:15:39,210 But the biggest thing is that it's synchronized. 295 00:15:39,270 --> 00:15:39,930 that's the key. 296 00:15:40,140 --> 00:15:46,080 That's, you're, you asked earlier, you delete a picture in your phone or some 297 00:15:46,290 --> 00:15:49,920 app, delete, some like ransomware deletes a bunch of pictures in your phone. 298 00:15:50,130 --> 00:15:54,300 It synchronizes that deletion up in the cloud and they go byebye, right? 299 00:15:54,300 --> 00:15:57,270 It is a synchronized copy, not a backup. 300 00:15:57,815 --> 00:16:02,935 it is stored separately, but if you delete it here and it gets deleted 301 00:16:02,935 --> 00:16:04,665 there, that's not a backup, right? 302 00:16:04,755 --> 00:16:06,345 Just like we were talking, before. 303 00:16:06,925 --> 00:16:12,135 And that's one really important reason, possibly the most important reason. 304 00:16:12,475 --> 00:16:17,035 But the other is that there's a feature in iPhone that... 305 00:16:17,535 --> 00:16:21,805 It says we can store low res copies on the phone and the high res copies in 306 00:16:21,805 --> 00:16:26,505 the cloud, which means that not only is it a synchronized copy, the only true 307 00:16:26,505 --> 00:16:28,265 copy of your photo is in the cloud. 308 00:16:28,265 --> 00:16:32,145 It's only one copy, which means you need to be backing up iCloud. 309 00:16:32,650 --> 00:16:36,190 and by extension also, Google photos if you're an Android 310 00:16:36,190 --> 00:16:38,390 person, so yeah, not a backup, 311 00:16:38,665 --> 00:16:39,205 okay, no, 312 00:16:39,350 --> 00:16:41,870 which we had a whole podcast episode about that. 313 00:16:41,970 --> 00:16:43,970 How to properly back up your iCloud account. 314 00:16:44,950 --> 00:16:45,240 yeah, 315 00:16:45,335 --> 00:16:46,055 were good examples. 316 00:16:46,055 --> 00:16:48,115 I think those are a lot of things, like you said, right? 317 00:16:48,115 --> 00:16:51,745 It's not always easy to say, is it a backup or not? 318 00:16:51,755 --> 00:16:54,935 Unless you dive into the next level of questions and ask, okay, is it really a 319 00:16:55,030 --> 00:16:55,360 yeah, 320 00:16:56,195 --> 00:16:56,955 Does it meet these 321 00:16:57,030 --> 00:16:57,360 I think. 322 00:16:57,515 --> 00:16:57,695 or not? 323 00:16:58,755 --> 00:17:02,205 I think you did a good job of, the different categories, like that 324 00:17:02,205 --> 00:17:06,405 thing of, if it's fully synchronized, whether synchronous or asynchronous, 325 00:17:06,715 --> 00:17:09,975 if it's fully synchronized and if I delete the production and 326 00:17:09,975 --> 00:17:11,735 it deletes the data, the copy, 327 00:17:12,095 --> 00:17:13,325 that, That's not a backup. 328 00:17:13,655 --> 00:17:13,985 right? 329 00:17:14,525 --> 00:17:18,075 unless that copy has the ability to undo that. 330 00:17:18,505 --> 00:17:20,745 If it does, then, I would change my answer, right? 331 00:17:20,745 --> 00:17:25,395 And so like a NetApp synchronized filer, I would consider that 332 00:17:25,395 --> 00:17:28,345 other copy, that would be backup, 333 00:17:28,595 --> 00:17:33,615 other things that are not a backup, one that you didn't mention would be, 334 00:17:34,005 --> 00:17:36,875 the recycle bin in your Microsoft 365. 335 00:17:37,800 --> 00:17:39,450 That is not a backup, right? 336 00:17:39,460 --> 00:17:40,670 It's not stored separately. 337 00:17:40,750 --> 00:17:44,780 it's just, records in a database that have been flagged as deleted. 338 00:17:44,960 --> 00:17:46,080 They haven't gone anywhere. 339 00:17:46,110 --> 00:17:48,070 They're sitting right next to the production data. 340 00:17:48,410 --> 00:17:49,300 So yeah, 341 00:17:49,550 --> 00:17:49,860 Okay. 342 00:17:50,020 --> 00:17:52,900 And then the other one is, 343 00:17:55,975 --> 00:18:03,495 So in your opinion, does backup require you to always be able to go 344 00:18:03,495 --> 00:18:10,605 back to a point in time that could plausibly have existed in the system? 345 00:18:12,445 --> 00:18:16,215 And the reason I'm asking this is if I look at, I know email archiving comes 346 00:18:16,215 --> 00:18:19,265 up a lot and sometimes people are like, oh, that's the same as backup. 347 00:18:20,115 --> 00:18:22,825 But with email archive, you're just getting all the data that's there, 348 00:18:22,825 --> 00:18:26,035 whether or not your mailbox actually looked like that, your inbox looked 349 00:18:26,035 --> 00:18:27,625 like that or not at any point in time. 350 00:18:29,020 --> 00:18:29,640 Yeah. 351 00:18:30,330 --> 00:18:33,110 So backup. 352 00:18:34,095 --> 00:18:37,035 requires restore, right? 353 00:18:37,445 --> 00:18:41,415 For it to be a backup, you need to be able to restore it to the way it 354 00:18:41,435 --> 00:18:45,665 looked at some point in time, right? 355 00:18:45,715 --> 00:18:47,905 yeah, that's a really good question, Prasanna. 356 00:18:48,915 --> 00:18:53,525 it's one thing to say a file, but, if you cannot, if you cannot bring 357 00:18:54,465 --> 00:19:01,065 the thing that's been damaged back to its You know, back to before it 358 00:19:01,065 --> 00:19:06,125 was damaged and that it comes back to the same way as it was before it was 359 00:19:06,125 --> 00:19:08,665 damaged, then you don't have a backup. 360 00:19:09,725 --> 00:19:12,170 You copy of the data, right? 361 00:19:12,900 --> 00:19:15,280 And an email archive is a perfect example of that. 362 00:19:15,280 --> 00:19:18,230 You have a copy of the data, but it was stored for a different purpose. 363 00:19:18,230 --> 00:19:25,185 It was stored for archive, which means it wasn't designed to be put back into the, 364 00:19:25,385 --> 00:19:26,165 the state it was in, 365 00:19:27,035 --> 00:19:28,295 yeah, the state that it was in, 366 00:19:28,295 --> 00:19:28,505 right? 367 00:19:28,505 --> 00:19:31,005 so you might be able to restore all the email, but you won't be able to 368 00:19:31,005 --> 00:19:33,315 restore folders and things like that. 369 00:19:33,365 --> 00:19:38,295 A good backup should bring the thing back to the way it was before it was damaged, 370 00:19:38,305 --> 00:19:43,285 however it let's go back to a time when tape drive started getting, so here, 371 00:19:43,325 --> 00:19:49,095 we're going to talk about a feature that is now for many people, passe, right? 372 00:19:49,105 --> 00:19:54,165 it's not really necessary because they no longer use tape as their primary target 373 00:19:54,275 --> 00:19:56,125 or their initial target of backups. 374 00:19:57,225 --> 00:19:59,175 and that is this concept of multiplexing. 375 00:19:59,645 --> 00:20:03,275 And it goes back to, there was a time when we 376 00:20:03,280 --> 00:20:05,320 Way back in the days. 377 00:20:05,975 --> 00:20:07,065 right back in the day. 378 00:20:07,365 --> 00:20:11,335 So multiplexing, do you want to define multiplexing or explain it? 379 00:20:11,390 --> 00:20:12,100 Yeah, multiplexing. 380 00:20:12,100 --> 00:20:16,590 Yeah, I, let me attempt to, I know I wasn't aware of this before we started 381 00:20:16,600 --> 00:20:20,200 doing the podcast and you explained everything about tape and I know we've 382 00:20:20,200 --> 00:20:26,030 had a bunch of folks, tape experts on the podcast as well, but multiplexing is... 383 00:20:26,575 --> 00:20:34,265 to solve an issue where tape requires you to write at a certain speed. 384 00:20:34,275 --> 00:20:35,585 If you don't, it's bad. 385 00:20:36,035 --> 00:20:39,715 And tapes got faster and faster, but the problem was pumping data into the tape 386 00:20:39,875 --> 00:20:45,415 device itself wasn't going as quickly as the tape speeds were increasing. 387 00:20:45,415 --> 00:20:50,110 And so in order to solve that, what they decided to do was say, okay, Let's have 388 00:20:50,120 --> 00:20:55,030 multiple clients feed data into the tape device at the same time, and we will 389 00:20:55,050 --> 00:20:58,470 multiplex or basically write all those streams into the tape drive at the same 390 00:20:58,470 --> 00:21:00,660 time, keeping the tape device happy. 391 00:21:01,025 --> 00:21:03,035 While still being able to do all the backups. 392 00:21:04,095 --> 00:21:06,455 Yeah, another word for it would be interleaving. 393 00:21:06,475 --> 00:21:07,075 You did great. 394 00:21:07,515 --> 00:21:10,155 basically putting all, chopping them up into pieces and then 395 00:21:10,155 --> 00:21:14,135 putting together into one, turning a bunch of streams into one stream. 396 00:21:14,695 --> 00:21:19,545 And when we first started, we used multiplexing settings of four 397 00:21:20,695 --> 00:21:21,565 Which means four different 398 00:21:21,665 --> 00:21:21,955 turn and. 399 00:21:22,910 --> 00:21:25,730 Yeah, four different clients being combined into a stream to 400 00:21:25,730 --> 00:21:28,760 make a tape drive happy, but tape drives got faster and faster. 401 00:21:29,000 --> 00:21:30,720 The clients didn't get faster. 402 00:21:31,230 --> 00:21:36,150 And so by the time I left, by the time I used my last tape drive in 403 00:21:36,150 --> 00:21:39,890 production, we were up to 36, right? 404 00:21:39,900 --> 00:21:45,230 We were up to 36 streams together to, to make an individual tape drive happy. 405 00:21:45,710 --> 00:21:47,590 And the reason, 406 00:21:47,810 --> 00:21:48,770 I was gonna ask why. 407 00:21:48,830 --> 00:21:49,160 Yeah. 408 00:21:49,160 --> 00:21:50,780 Why were clients not fast enough 409 00:21:51,825 --> 00:21:52,135 yeah. 410 00:21:52,135 --> 00:21:59,375 So the reason that this was bad is that, what, why is the only reason we back up, 411 00:22:00,040 --> 00:22:00,790 to restore 412 00:22:01,595 --> 00:22:01,965 right? 413 00:22:02,265 --> 00:22:02,975 So when you 414 00:22:02,975 --> 00:22:03,245 go to 415 00:22:03,245 --> 00:22:04,285 do a restore, 416 00:22:04,375 --> 00:22:04,670 Yeah. 417 00:22:05,305 --> 00:22:05,695 yeah. 418 00:22:05,905 --> 00:22:10,325 When you go to do a restore, you have to read all 36 streams 419 00:22:10,525 --> 00:22:12,545 and throw 35 of them away. 420 00:22:13,525 --> 00:22:19,595 So your tape drive, the speed of your restore is going to be 1 35th. 421 00:22:20,285 --> 00:22:23,725 Of what it could potentially be if it hadn't been multiplexed, 422 00:22:25,080 --> 00:22:27,840 But if you're never doing restore tests, it doesn't really matter. 423 00:22:27,840 --> 00:22:29,880 Until you actually need to restore the data. 424 00:22:31,195 --> 00:22:36,925 yeah, if you're You're killing me you're killing me yeah, so it was one 425 00:22:36,925 --> 00:22:43,995 of these things where it was a Cut your nose off to to spite your face, right? 426 00:22:44,165 --> 00:22:50,170 So We felt that it was But it was a necessary evil. 427 00:22:50,210 --> 00:22:54,160 We, you could only restore if you've got backups done and we could only get 428 00:22:54,170 --> 00:22:59,040 backups done reliably if we were using multiplexing, but we knew that it was 429 00:22:59,040 --> 00:23:03,470 creating this problem and ultimately this was the undoing of tape from 430 00:23:03,470 --> 00:23:05,300 a backup and recovery perspective. 431 00:23:05,350 --> 00:23:07,940 We switched to destaging and. 432 00:23:08,230 --> 00:23:11,490 these other things to undo this, necessary evil. 433 00:23:11,760 --> 00:23:13,420 But, it, it was a mess. 434 00:23:13,420 --> 00:23:14,850 But that's what multiplexing is. 435 00:23:14,850 --> 00:23:18,060 So if you've heard about multiplexing, you don't need to do multiplexing 436 00:23:18,070 --> 00:23:19,190 if you're backing up to disk. 437 00:23:19,560 --> 00:23:23,160 Because disk can write at whatever speed you tell it to write at. 438 00:23:23,230 --> 00:23:25,770 And it can write a bunch of things at the same time. 439 00:23:26,540 --> 00:23:30,510 And you can give it 36 streams and it can write them all at the same time in 440 00:23:30,510 --> 00:23:33,950 separate places of the disk in such a way that when you go to do a restore, 441 00:23:33,950 --> 00:23:36,600 you don't, you're not, you don't have to read all of them to read one of them. 442 00:23:39,770 --> 00:23:40,080 What? 443 00:23:41,390 --> 00:23:44,190 That was my yes. 444 00:23:44,620 --> 00:23:47,270 disk is fast enough, but 445 00:23:48,620 --> 00:23:49,040 Yeah. 446 00:23:49,250 --> 00:23:49,940 Well, it's not, 447 00:23:50,000 --> 00:23:50,400 a disk 448 00:23:50,400 --> 00:23:51,620 drive has a certain 449 00:23:51,620 --> 00:23:53,550 number of IOPS it could handle. 450 00:23:53,550 --> 00:23:56,900 And therefore, as long as your system is big enough. 451 00:23:57,635 --> 00:23:58,875 To handle all of them in peril. 452 00:23:58,980 --> 00:23:59,520 yes. 453 00:23:59,580 --> 00:24:04,310 they're, disk drives are not, Unlimited bandwidth, unlimited IO, 454 00:24:04,360 --> 00:24:05,330 et cetera, et cetera, et cetera. 455 00:24:05,330 --> 00:24:05,760 Yes. 456 00:24:06,310 --> 00:24:10,150 but the point of the way that it lays the data, you don't have to lay the, 457 00:24:10,490 --> 00:24:13,150 you can lay the data however you want and then read it however you want. 458 00:24:13,740 --> 00:24:18,090 there are, again, there are limits to everything depending on how 459 00:24:18,090 --> 00:24:20,700 much you fragment the data and all that kind of stuff, right? 460 00:24:20,730 --> 00:24:23,690 But it's still way better than tape from that perspective. 461 00:24:24,700 --> 00:24:26,760 All right, next one's a whole lot easier. 462 00:24:27,685 --> 00:24:28,405 What comes next? 463 00:24:28,415 --> 00:24:29,565 What's the first type of, what's 464 00:24:29,610 --> 00:24:30,340 let you tackle 465 00:24:30,555 --> 00:24:32,395 what, no, I'll let you tackle this, Curtis. 466 00:24:32,405 --> 00:24:34,835 So what's the, what is it? 467 00:24:34,885 --> 00:24:38,695 The first type of backup that everyone should cut their teeth on. 468 00:24:40,285 --> 00:24:41,585 what a full backup? 469 00:24:41,745 --> 00:24:42,005 Is that 470 00:24:42,435 --> 00:24:42,915 Yeah. 471 00:24:43,015 --> 00:24:43,605 what you're saying? 472 00:24:44,525 --> 00:24:44,905 Yeah. 473 00:24:45,215 --> 00:24:47,465 so basically we're just going to talk about this concept of 474 00:24:47,465 --> 00:24:48,715 full and incremental backups. 475 00:24:49,315 --> 00:24:55,425 And probably everybody knows this, but this is a backup to basic series. 476 00:24:55,435 --> 00:24:59,125 So a full backup backs up everything, an incremental backup 477 00:24:59,435 --> 00:25:02,555 backs up things that have changed. 478 00:25:02,845 --> 00:25:07,065 And the, there are different types of incremental backups, right? 479 00:25:07,165 --> 00:25:12,965 And different people have different names for these different types, right? 480 00:25:13,405 --> 00:25:17,955 terms you've probably heard, incremental, differential, cumulative incremental. 481 00:25:18,055 --> 00:25:21,915 For a lot of people, cumulative incremental and 482 00:25:21,915 --> 00:25:23,345 differential are the same thing. 483 00:25:23,990 --> 00:25:29,220 for people that got stuck in Windows land, not necessarily so what's the 484 00:25:29,220 --> 00:25:32,000 difference between an incremental and these other two things? 485 00:25:32,000 --> 00:25:33,150 A cumulative incremental. 486 00:25:34,075 --> 00:25:41,355 So an incremental is basically, Typically, Sunday you do a full backup, right? 487 00:25:41,635 --> 00:25:43,325 Monday you need to do another backup. 488 00:25:43,365 --> 00:25:47,275 Now, you don't want to do necessarily the entire full backup again, 489 00:25:47,655 --> 00:25:50,715 because maybe that's too much data, you don't have enough time, etc. 490 00:25:50,715 --> 00:25:54,175 So you'll do an incremental, which is basically whatever has 491 00:25:54,175 --> 00:25:55,695 changed since the last full. 492 00:25:56,095 --> 00:25:56,905 So since Sunday. 493 00:25:57,335 --> 00:25:59,355 Sorry, since the last time you did a backup, I should say. 494 00:25:59,955 --> 00:26:02,005 exactly, whatever's changed since the last time you did a 495 00:26:02,275 --> 00:26:06,325 Yeah, so in that case, it was Sunday, so then Monday you get the incrementals, 496 00:26:06,355 --> 00:26:09,635 now Tuesday you're going to do backup, and so you do another incremental, which 497 00:26:09,635 --> 00:26:11,265 is whatever has changed since Monday, 498 00:26:12,925 --> 00:26:13,495 Exactly, 499 00:26:13,525 --> 00:26:15,585 and we just keep doing that, right? 500 00:26:15,815 --> 00:26:16,885 Yeah, and 501 00:26:17,045 --> 00:26:20,855 then if it's, yeah, if it's Sunday, right? 502 00:26:20,935 --> 00:26:24,715 And now it's Saturday, how many tapes do I need to do a restore? 503 00:26:25,495 --> 00:26:26,015 do you need... 504 00:26:26,590 --> 00:26:29,690 The previous Sunday, plus the Monday, plus the Tuesday, plus 505 00:26:29,690 --> 00:26:31,280 the Wednesday, Thursday, Friday. 506 00:26:32,410 --> 00:26:33,610 You basically need to replay 507 00:26:33,760 --> 00:26:37,400 by the way, by the way, I really, I really channeled the old Curtis there. 508 00:26:37,400 --> 00:26:40,020 I did it without even meaning to, I said tapes, right? 509 00:26:40,020 --> 00:26:40,180 Cause 510 00:26:40,180 --> 00:26:42,230 that was the problem back then. 511 00:26:42,230 --> 00:26:45,500 We literally had to grab for seven tapes, right? 512 00:26:46,320 --> 00:26:48,320 Nowadays, we don't have to grab for seven tapes, but, 513 00:26:48,800 --> 00:26:50,690 but you still have to do all those restores though, right? 514 00:26:50,810 --> 00:26:56,270 So even in the case of, if a file existed Sunday, and then was deleted Monday, 515 00:26:56,880 --> 00:27:01,260 and then came back on Tuesday, you would still end up having to do all of those 516 00:27:01,880 --> 00:27:05,820 data, like basically you're replaying like a log, all the data that would 517 00:27:05,820 --> 00:27:07,260 have existed on each of those days. 518 00:27:08,155 --> 00:27:08,705 right. 519 00:27:08,725 --> 00:27:12,325 The real problem is a file that was changed every single day. 520 00:27:13,025 --> 00:27:16,245 You would actually restore that file seven times. 521 00:27:16,325 --> 00:27:17,655 It's a lot of wasted effort. 522 00:27:17,665 --> 00:27:21,375 That's just the idea of a increment or regular incremental. 523 00:27:21,675 --> 00:27:24,595 Then we have a differential or a cumulative incremental. 524 00:27:25,045 --> 00:27:27,865 And the difference between that is that it's going to, it's going to do 525 00:27:27,865 --> 00:27:30,735 the thing that you said earlier, which is it's going to back up everything 526 00:27:30,735 --> 00:27:32,135 that's changed since the fall. 527 00:27:32,795 --> 00:27:36,755 And so what some people do is that they've stopped, they stopped doing 528 00:27:36,755 --> 00:27:40,845 incrementals and they switched to differentials or cumulative incrementals 529 00:27:41,125 --> 00:27:46,355 every day, and that way at the end of the week, I would need at most two tapes. 530 00:27:46,885 --> 00:27:53,185 Right now, this whole thing has pretty much gone away in the world of. 531 00:27:53,810 --> 00:27:55,320 disk based backups, right? 532 00:27:55,320 --> 00:27:59,310 Because the whole reason that we did backups this way, is 533 00:27:59,320 --> 00:28:01,080 that, first off, let me back up. 534 00:28:01,130 --> 00:28:03,870 We used to do weekly fulls followed by daily incrementals. 535 00:28:04,230 --> 00:28:10,050 Then we switched for, because when we went to automated tape libraries, 536 00:28:10,080 --> 00:28:14,390 the whole process of managing the different tapes wasn't as a big. 537 00:28:14,565 --> 00:28:15,285 Big of a deal. 538 00:28:15,285 --> 00:28:18,885 So we went to monthly folds followed by daily incrementals or maybe 539 00:28:18,885 --> 00:28:20,825 a weekly cumulative and right? 540 00:28:21,125 --> 00:28:25,915 So you'd still need a maximum of seven tapes to do a restore But when 541 00:28:25,915 --> 00:28:30,445 we switched to this this whole thing just became Kind of silly and moot and 542 00:28:30,445 --> 00:28:34,826 whatever and you could back up, however, you wanted to back up and dedupe, 543 00:28:34,856 --> 00:28:38,636 which we're going to talk about in a minute, dedupe really changed the game. 544 00:28:39,256 --> 00:28:43,226 And, because it didn't matter whether you backed up full or incremental or whatever, 545 00:28:43,276 --> 00:28:45,146 you still stored the same amount of data. 546 00:28:45,826 --> 00:28:45,936 go 547 00:28:46,161 --> 00:28:53,291 before we jump though, one thing that I think people might also hear in addition 548 00:28:53,291 --> 00:28:59,931 to fulls, incrementals, differentials, and cumulative incrementals is also levels. 549 00:29:00,091 --> 00:29:01,731 So maybe you could talk about levels. 550 00:29:01,731 --> 00:29:03,801 I know sometimes it's specific to like Oracle. 551 00:29:04,381 --> 00:29:06,001 And some databases, but maybe it might 552 00:29:06,036 --> 00:29:06,856 no, that's a good point. 553 00:29:06,916 --> 00:29:08,346 Yeah, thanks. 554 00:29:08,396 --> 00:29:13,576 so the concept of a backup level, literally, this goes 555 00:29:13,596 --> 00:29:16,076 back to the days of dump, right? 556 00:29:16,136 --> 00:29:19,146 which was the command to backup Unix file systems. 557 00:29:20,076 --> 00:29:26,166 A level zero was a full, a level one, And if you wanted to do increment, if you 558 00:29:26,166 --> 00:29:29,696 want to do what we call the incremental backups, the way we, you would do a zero 559 00:29:29,706 --> 00:29:33,216 followed by a one, followed by a two, followed by a three, followed by a four. 560 00:29:34,096 --> 00:29:39,296 And, it got interesting because if you then lowered the number. 561 00:29:40,126 --> 00:29:41,336 It would behave like a, 562 00:29:41,336 --> 00:29:43,316 cumulative incremental, right? 563 00:29:43,706 --> 00:29:48,726 so like you could do a zero and then you do a one. 564 00:29:49,486 --> 00:29:53,586 If you then did another one, if you kept doing ones, you would get a differential. 565 00:29:53,596 --> 00:29:55,766 You would get a cumulative incremental every day. 566 00:29:56,526 --> 00:30:02,206 If you did a 0, a 1, and then a 2, and then a 1 again, it's just, it 567 00:30:02,316 --> 00:30:08,226 basically, it always pointed back to the number that was the most recent 568 00:30:08,236 --> 00:30:12,536 number that was lower than itself, and so it got complicated, and so 569 00:30:12,536 --> 00:30:14,016 there were actually some people that 570 00:30:14,396 --> 00:30:15,216 Is it they prefer 571 00:30:15,421 --> 00:30:16,431 called Towers of 572 00:30:16,431 --> 00:30:22,071 Hanoi, Yeah, which is based on the game, and I've got it in the book, 573 00:30:22,071 --> 00:30:30,531 the Towers of Hanoi progressive thing, but I can't, it's like 0, 3, 2, 4, so 574 00:30:30,531 --> 00:30:34,961 basically every backup, without doing cumulative incrementals, every backup, 575 00:30:34,991 --> 00:30:39,391 every file that was changed would end up being on two tapes, which was just 576 00:30:39,391 --> 00:30:43,026 an interesting way to, To minimize tape, again, this is all because we're doing 577 00:30:43,036 --> 00:30:44,516 tapes, but nobody has tapes anymore. 578 00:30:44,526 --> 00:30:45,256 So nobody cares. 579 00:30:45,526 --> 00:30:46,806 But that's what levels were. 580 00:30:46,816 --> 00:30:48,036 It was all the way up to nine. 581 00:30:48,736 --> 00:30:52,386 and they still have this concept in, in things like Oracle Backup. 582 00:30:53,666 --> 00:30:56,326 So the next thing to talk about is this concept called file 583 00:30:56,326 --> 00:30:58,106 level incremental forever. 584 00:30:58,606 --> 00:31:05,066 And the company that really put this out there was IBM with their product TSM. 585 00:31:06,076 --> 00:31:07,468 And back in the day, 586 00:31:07,641 --> 00:31:08,391 has been renamed, 587 00:31:08,496 --> 00:31:08,906 idea is you 588 00:31:08,906 --> 00:31:10,276 do one full, what's that? 589 00:31:10,281 --> 00:31:11,351 Hasn't it been renamed? 590 00:31:12,541 --> 00:31:15,631 It has, but I'm just saying they came out with it when they 591 00:31:15,631 --> 00:31:16,861 came out, it was called TSM. 592 00:31:17,111 --> 00:31:23,291 It's now like IBM spectrum protect, but, the idea was you do one full and then 593 00:31:23,291 --> 00:31:25,681 everything is an incremental forever. 594 00:31:25,841 --> 00:31:30,171 we never again do a full and this really saved a lot of 595 00:31:30,181 --> 00:31:31,765 bandwidth and saved a lot of tape. 596 00:31:32,236 --> 00:31:41,446 It came with a mess and that was over time and again, tape over time, 597 00:31:41,886 --> 00:31:47,686 you could end up needing hundreds of tapes to restore a single file system. 598 00:31:48,266 --> 00:31:51,606 you would need just one file from this tape and one file from that tape. 599 00:31:51,606 --> 00:31:54,656 And since the hardest part of a tape is like, it was like 600 00:31:54,676 --> 00:31:58,286 two and a half minutes just to get a tape in and, get it loaded and seek 601 00:31:58,286 --> 00:32:00,581 to So the average point in a tape. 602 00:32:01,481 --> 00:32:08,961 So I was not a fan of doing backups this way when we were talking about tape. 603 00:32:09,161 --> 00:32:11,041 Was there a reason? 604 00:32:11,241 --> 00:32:13,701 what was the use case at the time for that? 605 00:32:13,761 --> 00:32:15,511 it was about saving tape, saving 606 00:32:15,671 --> 00:32:16,301 storage. 607 00:32:16,311 --> 00:32:17,511 It was about saving bandwidth. 608 00:32:17,541 --> 00:32:20,181 the idea, there's nothing wrong with the idea of incremental forever. 609 00:32:20,551 --> 00:32:22,711 It's just that their implementation. 610 00:32:23,271 --> 00:32:27,491 Back in the day when it was all tape, even when they had disk staging. 611 00:32:27,501 --> 00:32:29,011 So they would stage the disk. 612 00:32:29,011 --> 00:32:31,901 So they wouldn't multiplex, by the way, they wouldn't multiplex. 613 00:32:31,901 --> 00:32:35,521 They would stage the disk and then they would, do the backups to tape. 614 00:32:36,651 --> 00:32:39,041 And this only applied to file system backups. 615 00:32:39,041 --> 00:32:41,181 It didn't apply to database backups. 616 00:32:41,381 --> 00:32:46,411 And, but literally you would need hundreds and hundreds of tapes 617 00:32:46,701 --> 00:32:48,171 to restore a single file system. 618 00:32:48,171 --> 00:32:51,341 And it just, I was never a fan of doing backups that way. 619 00:32:52,051 --> 00:32:57,131 As long as we were backing up to tape and they had ways to they had, co location 620 00:32:57,131 --> 00:33:01,701 and these various, and this thing called reclamation, because when you're doing 621 00:33:01,711 --> 00:33:07,091 backups that way, you end up with a lot of tapes that have files on them that have 622 00:33:07,091 --> 00:33:11,561 expired that are no longer needed, but you have other files on there that are needed. 623 00:33:12,121 --> 00:33:15,411 And so you'd have to copy forward. 624 00:33:15,411 --> 00:33:15,821 Yeah. 625 00:33:15,871 --> 00:33:18,201 so that you could reclaim that whole tape and then reuse it. 626 00:33:18,731 --> 00:33:19,091 And 627 00:33:19,276 --> 00:33:20,036 That sounds like a 628 00:33:20,046 --> 00:33:21,136 management nightmare. 629 00:33:21,546 --> 00:33:23,676 An interesting engineering problem, but... 630 00:33:24,836 --> 00:33:28,046 yeah, I was never a fan of doing backups that way. 631 00:33:28,186 --> 00:33:32,576 and I'm even less of a fan now that we don't have to worry about tape. 632 00:33:33,036 --> 00:33:35,746 Now we can just do incremental forever and just do it without all that 633 00:33:35,746 --> 00:33:37,906 co location and reclamation stuff. 634 00:33:37,956 --> 00:33:41,326 Cause on disk, to reclaim, you just delete a file, right? 635 00:33:41,326 --> 00:33:43,456 On tape, you delete a file in the middle of a tape. 636 00:33:43,456 --> 00:33:45,256 You have to reclaim the tape. 637 00:33:45,411 --> 00:33:48,851 so that's file level incremental forever. 638 00:33:49,151 --> 00:33:54,311 And then, with the advent of backing up to disk, Which finally 639 00:33:54,311 --> 00:33:57,881 happened, I don't know, 20 years ago. 640 00:33:58,091 --> 00:33:59,031 It's so funny. 641 00:33:59,031 --> 00:34:01,931 We, we say the advent of something that happened 20 years ago. 642 00:34:02,311 --> 00:34:07,271 When we finally started doing it, and once everybody finally went to, and by 643 00:34:07,271 --> 00:34:10,121 the way, everybody still is not backing up the desk, it's still, there's still 644 00:34:10,121 --> 00:34:13,561 a small contingent of people to back up the tape, so those people will really 645 00:34:13,561 --> 00:34:15,361 enjoy the first half of this episode. 646 00:34:16,191 --> 00:34:19,691 Now we have this concept of block level incremental forever. 647 00:34:19,701 --> 00:34:21,621 Would you like to explain that? 648 00:34:21,876 --> 00:34:31,226 Yeah, with block level incremental, I guess where I think of block level 649 00:34:31,226 --> 00:34:33,676 incremental, I know there's various places you can think about it, is 650 00:34:33,676 --> 00:34:38,186 when it applies to virtual machines and other sort of larger objects. 651 00:34:39,031 --> 00:34:45,901 where it doesn't make sense, to back up an entire VM, doing full, or, incremental 652 00:34:45,911 --> 00:34:49,521 backups away, if you think about how you would have done file level backups, right? 653 00:34:50,041 --> 00:34:50,551 Why would I 654 00:34:50,606 --> 00:34:51,776 Now, what, why would that be? 655 00:34:52,111 --> 00:34:57,291 because I have a file which represents a disk, the entire file 656 00:34:57,321 --> 00:34:59,831 doesn't change every time, right? 657 00:34:59,871 --> 00:35:00,931 Parts of the file 658 00:35:01,136 --> 00:35:06,986 it's, so we're talking to a VMDK file or VDK, For, for, 659 00:35:06,986 --> 00:35:08,966 Hyper V, VDDK, that can't say VDDK. 660 00:35:10,171 --> 00:35:11,211 I think it's VDDK. 661 00:35:11,381 --> 00:35:11,671 Yeah, 662 00:35:12,426 --> 00:35:13,156 I think you're right. 663 00:35:13,946 --> 00:35:16,456 so you're saying if anything changes on there, 664 00:35:16,491 --> 00:35:17,791 you're backing up the entire whole 665 00:35:17,796 --> 00:35:19,816 do an incremental, exactly. 666 00:35:19,826 --> 00:35:19,926 You're going 667 00:35:19,941 --> 00:35:21,501 it's the entire file change, right? 668 00:35:21,501 --> 00:35:23,591 So you're backing up the entire thing, but that doesn't make sense when 669 00:35:23,591 --> 00:35:29,761 you have files which are say 10, 50, 100, 200 gigabytes and you're backing 670 00:35:29,761 --> 00:35:34,061 that up every single time and so with block level incrementals What they 671 00:35:34,061 --> 00:35:41,021 basically have done is say, okay What blocks have changed in this VMDK? 672 00:35:41,031 --> 00:35:43,281 Let me just back those up, right? 673 00:35:43,301 --> 00:35:47,231 Oracle also for databases, they do something similar, right? 674 00:35:47,231 --> 00:35:52,281 Where it's hey Let me only back up the blocks within an Oracle data 675 00:35:52,281 --> 00:35:56,091 file that have changed rather than backing up the entire Oracle database. 676 00:35:57,066 --> 00:36:01,046 And how does the backup product know which blocks have changed? 677 00:36:01,981 --> 00:36:04,801 Usually you have to rely on that vendor to tell you. 678 00:36:05,491 --> 00:36:08,301 So in the case of Oracle, right? 679 00:36:08,301 --> 00:36:12,561 You're usually integrating with Oracle RMAN via SBT or some other 680 00:36:12,561 --> 00:36:16,871 mechanism where Oracle knows, okay, I keep track of the database blocks. 681 00:36:16,871 --> 00:36:18,051 I know which ones are new. 682 00:36:18,241 --> 00:36:20,321 Here is a list of blocks that you need to care about. 683 00:36:20,321 --> 00:36:26,951 Same thing with VMware, when you have their, what is their SDK called? 684 00:36:27,031 --> 00:36:27,701 VADP. 685 00:36:28,861 --> 00:36:29,221 Yeah. 686 00:36:29,241 --> 00:36:30,001 they've changed 687 00:36:30,001 --> 00:36:30,441 the name. 688 00:36:31,151 --> 00:36:31,521 Yeah. 689 00:36:31,581 --> 00:36:36,261 They've changed the name, but basically they're, they have an API to talk to, 690 00:36:36,641 --> 00:36:39,701 and they maintain a bitmap, right? 691 00:36:39,791 --> 00:36:44,261 And then they just give you, here's a map of the bits that you need to go get. 692 00:36:44,271 --> 00:36:45,781 These are the bits that have changed. 693 00:36:46,081 --> 00:36:47,501 They maintain that. 694 00:36:47,501 --> 00:36:51,711 And then the, there's an API for asking for those blocks, 695 00:36:52,041 --> 00:36:56,841 now this is great for disk based systems because if you think about these are 696 00:36:56,891 --> 00:37:02,641 all random spots in a file and so you can dump it out now It's up to figure 697 00:37:02,641 --> 00:37:06,191 out like how you want to do this and I know we'll talk a little bit later 698 00:37:06,191 --> 00:37:10,381 about deduplicated storage, but In the case of Oracle, typically you would just 699 00:37:10,401 --> 00:37:14,291 dump it out as incremental blocks, and just dump it into a file, and now you 700 00:37:14,301 --> 00:37:16,481 have all those blocks captured together. 701 00:37:16,931 --> 00:37:19,261 In the case of VMware, they started doing that. 702 00:37:19,261 --> 00:37:24,451 A lot of back up vendors would just dump it out as raw blocks, which makes sense. 703 00:37:25,146 --> 00:37:30,366 but then, there are other optimizations you can do to do smarter things with 704 00:37:30,366 --> 00:37:34,536 it, because with incremental block based backups, you still have to 705 00:37:34,926 --> 00:37:39,806 restore from multiple files in order to stitch together the final actual image. 706 00:37:41,041 --> 00:37:41,481 Yeah. 707 00:37:41,481 --> 00:37:43,491 And you still have that problem. 708 00:37:44,281 --> 00:37:48,761 That we talked about earlier where you may restore an individual block multiple 709 00:37:48,761 --> 00:37:50,991 times if it changes multiple times, right? 710 00:37:51,691 --> 00:37:54,211 the advantage is it's incredibly efficient. 711 00:37:55,121 --> 00:38:00,801 And the, like when we talk about backing up VMs, I agree with you. 712 00:38:00,821 --> 00:38:02,391 That's where this really shines. 713 00:38:02,847 --> 00:38:08,397 Because back in the day, if we backed up VMs, And we just pretended they were, 714 00:38:08,497 --> 00:38:12,077 physical machines and we were running full and incremental backups on them. 715 00:38:12,077 --> 00:38:13,637 We were beating the crap out of these VMs. 716 00:38:13,647 --> 00:38:19,477 So this is much more IO friendly, to the VMs, right? 717 00:38:19,477 --> 00:38:21,457 So it's much friendlier on the VMs. 718 00:38:21,707 --> 00:38:25,407 That's why we want to talk to the VMware API and get just 719 00:38:25,407 --> 00:38:26,567 the blocks that have changed. 720 00:38:27,427 --> 00:38:31,707 And it doesn't really come with any major downside compared to. 721 00:38:32,092 --> 00:38:34,602 The alternative is because we're storing the data on disk. 722 00:38:35,567 --> 00:38:35,987 Can I 723 00:38:36,107 --> 00:38:37,057 ask one 724 00:38:37,102 --> 00:38:37,322 yeah, 725 00:38:37,322 --> 00:38:37,682 sure. 726 00:38:38,807 --> 00:38:44,437 So we've talked about using block level incrementals for VMware, for databases. 727 00:38:45,487 --> 00:38:48,897 Is there a reason it hasn't really caught on for files? 728 00:38:50,742 --> 00:38:55,912 Because if I take a file and kind of split it up into blocks, right? 729 00:38:56,832 --> 00:38:58,262 Could I get the same benefit? 730 00:38:58,282 --> 00:39:00,542 Or is there a reason that it makes a lot more sense for 731 00:39:00,542 --> 00:39:02,652 like VMs or virtual machines? 732 00:39:04,012 --> 00:39:08,842 the benefit will be relative to the size of the file, right? 733 00:39:08,862 --> 00:39:11,522 The bigger the file, the bigger the benefit that you're going to get. 734 00:39:12,052 --> 00:39:17,322 And I would say that the reason it hasn't caught on is because of the next 735 00:39:17,322 --> 00:39:19,752 thing we're going to discuss, right? 736 00:39:19,792 --> 00:39:21,102 That solved that problem. 737 00:39:21,462 --> 00:39:27,082 But yeah, I think about like files like PST files or maybe a big access 738 00:39:27,082 --> 00:39:29,202 database or backing up like MySQL. 739 00:39:29,212 --> 00:39:30,172 That's not file. 740 00:39:30,422 --> 00:39:32,842 I mean, it is a file, but it's, it's actually a database. 741 00:39:32,842 --> 00:39:33,072 Right. 742 00:39:33,409 --> 00:39:40,629 I'd say the reason they didn't put a lot of effort is deduplication, which, 743 00:39:40,649 --> 00:39:42,039 why don't we just talk about that now? 744 00:39:42,469 --> 00:39:45,769 I know we've covered dedupe, just really quickly for those that don't 745 00:39:45,769 --> 00:39:50,519 understand what dedupe is, the idea is that we're going to identify duplicate 746 00:39:50,969 --> 00:39:58,189 segments of the data, and duplicate means that we've seen this data before. 747 00:39:58,529 --> 00:40:02,909 we've done a full backup or we've done an incremental backup and we've 748 00:40:02,909 --> 00:40:05,129 seen this part of the data before. 749 00:40:05,509 --> 00:40:09,439 And for it to be truly considered ddu, you've gotta look at, 750 00:40:09,529 --> 00:40:10,969 it's gotta be subfile, right? 751 00:40:10,969 --> 00:40:13,729 It's gotta be part of, like we were talking about the V M D K 752 00:40:14,029 --> 00:40:17,149 or the V D D K or a P S T file. 753 00:40:17,149 --> 00:40:21,289 We've gotta be looking inside the file, slicing that up into chunks, 754 00:40:21,619 --> 00:40:22,999 and then deciding this chunk. 755 00:40:22,999 --> 00:40:26,899 We've seen it before, this chunk, we have not, And so there are two 756 00:40:26,899 --> 00:40:28,719 different places that dedupe happens. 757 00:40:28,879 --> 00:40:33,719 One is at the target, which is, like a box, like a data domain 758 00:40:33,719 --> 00:40:35,549 or a quantum box or ExaGrid. 759 00:40:35,839 --> 00:40:37,779 these boxes are target dedupe. 760 00:40:39,039 --> 00:40:41,989 And then there's this thing called source dedupe, which. 761 00:40:42,184 --> 00:40:46,094 really took off from a company that was called Avamar. 762 00:40:46,114 --> 00:40:49,414 That company got sold to EMC, which I know you spent a little 763 00:40:49,414 --> 00:40:50,914 time with, back in the day. 764 00:40:51,734 --> 00:40:56,584 And, both of our previous employer did a source side deduplication. 765 00:40:56,634 --> 00:41:01,434 Yeah, so with the target site is great because you could take it and 766 00:41:01,434 --> 00:41:03,934 plug it in and place anywhere, right? 767 00:41:03,934 --> 00:41:09,064 Because as long as it supports whatever the protocol your client is using, right? 768 00:41:09,074 --> 00:41:12,214 You could just ingest the data and you get all the benefits of deduplication. 769 00:41:12,224 --> 00:41:14,504 So data domain was. 770 00:41:15,069 --> 00:41:19,809 Very popular initially for in virtual tape libraries, right? 771 00:41:19,809 --> 00:41:21,129 So you had tapes, right? 772 00:41:21,229 --> 00:41:23,589 People are constantly doing fulls and incremental backups. 773 00:41:23,589 --> 00:41:24,979 That's perfect to deduplicate. 774 00:41:25,409 --> 00:41:29,559 you plug in a data domain, it emulates the tape interface. 775 00:41:29,589 --> 00:41:32,739 And now you just, your clients still continue writing to there and then all 776 00:41:32,739 --> 00:41:34,699 your data gets deduplicated, right? 777 00:41:34,739 --> 00:41:39,839 And so it doesn't matter if it's NFS or if it's SMB or if it's tape, right? 778 00:41:39,839 --> 00:41:40,649 It just works. 779 00:41:41,819 --> 00:41:43,939 yeah, it's like that firewalla box that I 780 00:41:43,939 --> 00:41:44,539 bought, right? 781 00:41:44,539 --> 00:41:47,569 It just, it just, it goes in and then it just works, right? 782 00:41:47,569 --> 00:41:49,039 You didn't have to change anything. 783 00:41:49,369 --> 00:41:52,859 With source dedupe, the idea is that, there's three parts 784 00:41:52,859 --> 00:41:54,589 of the deduplication process. 785 00:41:54,599 --> 00:41:57,029 There's the slicing and dicing, right? 786 00:41:57,139 --> 00:41:58,569 There's the creation of a hash. 787 00:41:58,569 --> 00:42:04,714 You run the chunk of data through Some sort of cryptographic algorithm, like SHA, 788 00:42:04,804 --> 00:42:08,134 something, and then that gives you a value 789 00:42:08,404 --> 00:42:11,724 and then that value, you have to look up that value in some 790 00:42:11,724 --> 00:42:12,984 sort of hash table, right? 791 00:42:13,484 --> 00:42:17,314 with target deduplication, all three of those actions happen on the 792 00:42:17,314 --> 00:42:19,134 target, which is why it works so well. 793 00:42:19,134 --> 00:42:21,724 You just send the backups the way you're used to sending them, 794 00:42:21,944 --> 00:42:23,064 and then it does the magic. 795 00:42:23,064 --> 00:42:26,864 It slices and dices, it hashes, and it does the lookup, and it figures out which 796 00:42:26,864 --> 00:42:29,044 chunks of data are new based on that hash. 797 00:42:30,344 --> 00:42:34,064 Source side, the first two happen on the source, right? 798 00:42:34,114 --> 00:42:36,654 We slice up the data before we back it up. 799 00:42:36,684 --> 00:42:40,944 We slice up the data We create a hash of the data, and then we ask 800 00:42:41,104 --> 00:42:46,404 some magic person in the cloud, has this hash been seen before? 801 00:42:46,884 --> 00:42:50,484 And the decision is made on the other end. 802 00:42:50,704 --> 00:42:53,854 Yes, we've seen this, or we haven't seen this, and then we 803 00:42:53,864 --> 00:42:57,199 send Or don't send the data. 804 00:42:58,249 --> 00:43:02,809 To me, source dedupe is much more efficient than target dedupe. 805 00:43:03,259 --> 00:43:08,559 The difficulty is that it is a much, it's a little bit baby in 806 00:43:08,559 --> 00:43:10,349 a bathwater situation, right? 807 00:43:10,349 --> 00:43:11,419 Because in order to get it. 808 00:43:11,839 --> 00:43:13,659 You've got to do a forklift upgrade. 809 00:43:13,699 --> 00:43:19,269 You've got to stop using, let's say, again, this is things have changed, but 810 00:43:19,279 --> 00:43:24,039 back in the day, you had to stop using NetBackup and start using Avamar, right? 811 00:43:24,049 --> 00:43:28,469 Stop using Networker or TSM and switch to, Druva, right? 812 00:43:28,699 --> 00:43:31,819 You had to change your backup product to get this done. 813 00:43:32,519 --> 00:43:34,649 Things change a little bit over time, right? 814 00:43:34,799 --> 00:43:37,419 A lot of these products now support source dedupe. 815 00:43:38,104 --> 00:43:41,794 But that was the main downside or still is the main downside. 816 00:43:41,834 --> 00:43:44,634 If you want source dedupe, you've got to change your backup product, 817 00:43:45,244 --> 00:43:49,394 uh, or you've got to change how you use your backup product, 818 00:43:49,394 --> 00:43:50,544 assuming it starts supporting 819 00:43:50,609 --> 00:43:55,399 yeah, and I would say at this point, probably a good chunk of products 820 00:43:55,399 --> 00:44:00,859 either have their own source ID deduplication mechanism or they 821 00:44:00,859 --> 00:44:04,259 work with deduplicated targets which allow for source ID deduplication. 822 00:44:04,814 --> 00:44:11,734 for instance, integrating with ExaGrid or Data Domain from like TSM, Veeam, 823 00:44:11,774 --> 00:44:12,404 Exactly. 824 00:44:12,924 --> 00:44:18,294 Yeah, there are some that criticize it saying that, the slicing and 825 00:44:18,294 --> 00:44:21,104 dicing and the creation of the hash puts a load on the client. 826 00:44:21,404 --> 00:44:26,794 I have always argued that if done properly, that load created by the 827 00:44:26,794 --> 00:44:31,674 slicing and dicing and hashing is offset by the significant reduction 828 00:44:31,694 --> 00:44:36,544 of the load of transporting or not transporting 99 percent of the data, 829 00:44:36,744 --> 00:44:37,074 right? 830 00:44:37,534 --> 00:44:37,884 Yeah. 831 00:44:38,014 --> 00:44:43,444 Other critiques of it have been that the restore speed wasn't great because of 832 00:44:43,444 --> 00:44:45,244 how the data was stored on the other end. 833 00:44:45,244 --> 00:44:47,744 And I would argue that's a implementation problem. 834 00:44:48,084 --> 00:44:49,464 it's not a problem with the concept. 835 00:44:49,924 --> 00:44:51,474 It's a problem with the implementation of the 836 00:44:51,794 --> 00:44:55,334 And then the other thing to also mention about source side deduplication is 837 00:44:55,664 --> 00:44:58,884 typically these are also using proprietary protocols, so you don't end up with a 838 00:44:58,884 --> 00:45:02,874 lot of security issues you have around, say, having a target dedupe appliance 839 00:45:02,904 --> 00:45:05,904 with NFS or SMB open to the world. 840 00:45:07,124 --> 00:45:07,414 Yep. 841 00:45:07,584 --> 00:45:07,884 Yep. 842 00:45:07,924 --> 00:45:08,344 Agreed. 843 00:45:08,374 --> 00:45:08,794 Yes. 844 00:45:08,824 --> 00:45:13,204 Agreed that there is a security advantage to having the data sliced 845 00:45:13,204 --> 00:45:17,864 and diced way before and then encrypted before you send it to the other 846 00:45:17,864 --> 00:45:21,284 system instead of doing it over an unsecured protocol like NFS or SMB. 847 00:45:21,284 --> 00:45:21,774 Exactly. 848 00:45:22,794 --> 00:45:23,164 All right. 849 00:45:23,174 --> 00:45:26,244 this episode, I think, got a little longer than we had intended for it to 850 00:45:26,304 --> 00:45:29,464 get, but we covered a lot. 851 00:45:29,534 --> 00:45:31,124 We covered a lot in this episode. 852 00:45:31,234 --> 00:45:33,204 so basically, we learned about. 853 00:45:33,499 --> 00:45:35,019 what is and is not a backup. 854 00:45:35,019 --> 00:45:38,409 We learned about, multiplexing, full and incremental backups, 855 00:45:38,829 --> 00:45:42,309 file level incremental backups, and source side deduplication. 856 00:45:43,389 --> 00:45:45,319 Uh, it's a big episode. 857 00:45:45,689 --> 00:45:46,289 what do you think? 858 00:45:46,334 --> 00:45:51,004 Yeah, no, that covers a lot of what everyone talks about when you... 859 00:45:51,644 --> 00:45:54,314 Do you ever refer to backup and restore, You gotta know these backup 860 00:45:54,314 --> 00:45:56,694 technologies in order to be able to restore and protect your company. 861 00:45:57,789 --> 00:45:59,509 These are things that you need to know. 862 00:46:00,039 --> 00:46:00,599 All right. 863 00:46:00,679 --> 00:46:05,269 And with that, I once again want to thank our listeners. 864 00:46:05,359 --> 00:46:07,249 you are why we do this in Prasanna. 865 00:46:07,539 --> 00:46:08,279 Once again. 866 00:46:08,609 --> 00:46:11,499 great at your insights and questions as well. 867 00:46:11,834 --> 00:46:12,564 Thank you, sir. 868 00:46:12,594 --> 00:46:13,464 Thank you, sir. 869 00:46:14,839 --> 00:46:15,799 Keeping me honest. 870 00:46:15,829 --> 00:46:20,149 And, remember this show, the backup wrap up is an independent podcast and 871 00:46:20,149 --> 00:46:22,099 the opinions that you hear are ours. 872 00:46:22,109 --> 00:46:26,669 Not anyone else's, and also this is a production of BackupCentral. 873 00:46:26,679 --> 00:46:30,559 com and, uh, produced and edited by yours truly. 874 00:46:30,894 --> 00:46:32,734 And I just want to say, that's a wrap.