Hi, everyone. Welcome back to our quarterly Drive Stats report. My name is Stephanie Doyle, and I am the Senior Manager of Market Intelligence and keeper of stats. Joining me today is David Johnson, who is going to walk through this quarter's Drive Stats report, as well as we are going to get into a discussion of some of the drive technologies on the rise in existence that are bringing the industry to what it is today and will be tomorrow. David, you want to introduce yourself? Yeah. Thanks, Stephanie. It is a pleasure to be here today. I have followed Drive Stats for a very long time. I have been in tech for a while now, so it has just been like a backbone to me. I think we are in our 13th year of Drive Stats, I believe, so we are still kicking strong. Yeah, it is 13 plus. We started tracking the data, and then we did our first report with a little bit of a gap. If you look at the full data set, I think we are not quite at 14. But if you look at where the report started, we are at 13 solidly. So it is a data set that only keeps on growing, and definitely keeps on giving. Always fun to do these reports. A little housekeeping for folks who have joined us before or for joining us for the first time today, webinar is being recorded. Of course, please ask questions, and there will be attachments that we add at the end, including the slide deck from today. You can always catch the blog and all that other good stuff on our website. We will have links to those at the end of this slide deck as well. This is the project. Of course, since 2013, David, you and I just talked about how long it has been around. We have collected, curated, and published- Yeah raw device metrics, and then transformed that into annualized failure rates and related statistics from hard disk drives and solid-state drives in our data centers. Each quarter, we publish this open source data set, which can be downloaded on the Drive Stats page. Check that out at backblaze.com/drivestats. We do try to keep up an Iceberg version of this data set on our GitHub, so you can find that as well linked. This is a top-line snapshot. I always find interesting our drive count up and only going up, as they say. Drive days, of course, is how many days all of our drives had to date. Drive failures is just the raw count of numbers there. Drive population by manufacturer, of course, we had WDC purchase HGST. From that perspective, we're at about a third in drive manufacturers, which is always helpful when we're looking at numbers. Certainly not ones to play favorites. There's a lot of great drives out there, and so we like to have everything nice and balanced. Yeah, and that's the benefit of our platform. It allows us to be able to use a good amount of these drives from different manufacturers and be able to have very efficient software and infrastructure that can help run it all. Yeah. It's that software layer on top of commodity hard drive, driving all the value there, of course. This is the Q2 2026 data. As always, incredibly difficult to read the full table. We always encourage you to dig in on the blog itself. You can see here at the bottom that our annualized failure rate for this quarter was 1.73, and this is a marked rise in quarterly AFRs. Why? First thing that I always do when I see a quarterly rise is to run an outlier test. Before we get there, let's talk about drives that had zero failures. Clean sweep from the Seagates this month. We had zero failures on the 8 TB, 12 TB, and 14 TB Seagates, these models identified here, and one on this 16 TB Seagate. We also saw the retirement of some very old drives in our system, so that would be the 4 TB HGST, 8 TB HGST as well, clocking in at nine and eight years old. Then a little bit of curiosity here. No new drive models. We certainly had new deployments, but they were all of existing drive models. I flagged last quarter that it is actually quite rare for us to not have a new drive model, I think in the last three years or something like that. It has only happened once. So to get two quarters in a row feels a bit odd. But it is nothing to say there. It is really just that we are getting the same models deployed in our system at about the same volume. Do you think that speaks to just efficiency of where we are at nowadays? It could be a number of things, but it seems like it is a good thing that we are sticking with the same models. Yeah, I think the biggest thing is that it is not that our growth of platform has not slowed down. I think it is the biggest reason I really wanted to talk about it. It is just that when you are deploying vaults, as much as possible, you want them to be really identical. So if we can get our hands on the same models and those models are functioning well within our system, why wouldn't we continue with the drives that are already qualified? Of course, there is work on multiple ends of the spectrum there. Qualifying drives also means you have more capacity to swap in and out if you have failures, all that good stuff. So, in terms of creating a happy system, it certainly helps to have similar models, especially if they are functioning well. I think we did not pull our review of the outliers, but you can certainly go check out the blog for that. But let us go back to the table for just a minute, and you can see here that there is a couple of models. This one up here is 7.63%, and then you have got 8.26% here. A third with, excuse me, I am losing it here, 9.33% on the Seagate 10 TB. So those three are, from a statistical standpoint, outliers. They did have very normal reasons for potentially reaching this high a failure rate. So, in one case, or actually in two cases, you had drives that were quite old, so more than seven years. Then in two other cases, so that would include one of those quite old drives, you had drives with a very low drive count. That means that if you get a raw number of drive failures, like looking at the Seagate 14 TB with the 8.26% failure rate, it's really only 25 failures. But when you only have 1,200 drives, that makes more of a difference in your AFR at the end of the day. Two of them that were quite old, two of them that had very low drive counts, and for that, those are all pretty normal indicators that they're actually already being cycled out of our system. Not a huge amount of worry even though the AFR did seem high on the surface. Let's talk lifetime data. Again, you've got the full table here. The AFR down here at 1.41%. That's very consistent actually. The AFR for the lifetime data, for understandable reasons, tends to not fluctuate as much as the quarterly. I think it's usually 1.39, 1.40, 1.41. I feel a little bit like a broken record when we review the data on this one. Which once again speaks to the fact that we are a managed system. Somebody's trying to make sure we're within good and healthy ranges there. Yeah. It's always a good thing Yes when things kind of stay the same. Yes. It means things are working. Yes Nothing's going bad. We want consistency. We want a low failure rate. We've got them. There's always going to be some variability, things you can't account for, but certainly, over time it tends to come out in the wash. Four models didn't make the cut to the lifetime table. This means that they've dropped below your total drive count. Interestingly, several of these were also our zero failures, David Johnson. I always find that quite interesting because we've said for a long time drives are getting better, lasting longer, and you still have to migrate things out. I find it's always a question from our readership where it's like, "Why are you retiring the drive if it's still going so well?" It's like, well, you have to do risk mitigation at a certain point, but if you're looking for longevity of drives, readership, sometimes these things happen, which is pretty cool. Yeah. It's very interesting to look at all of the Yeah data that I've seen over the years where we see this trend moving, where we're cutting out some smaller drives, putting in those larger drives, and seeing how the failure rates track against those. I know just doing some math off the top of my head, I think it's like nearly a quarter of our fleet now is approaching the 20 TB mark in drives. So I'm really interested to see that same kind of bathtub curve almost as we get into these larger drives. Yeah. I think it's important to note, and we did get this question on, I believe, our Reddit platform, do we see inherently a larger failure rate for larger, smaller drives? I think the mix of capacity within our system really is indicative of industry trends over preference, although there is a little bit of a preference to maximize how much density you have per rack. So if you put 20, 6 TB drives into one server, it doesn't store as much as 20, 20 TB drives per server, of course. But we haven't really seen higher failure rates in the population as correlated to age, and that's something that analysis we did most recently in 2025, sort of separated out our drives by introduction point as well. But I will say that it's a bit early to make that call, because the 20 TB drives are still quite young Yeah and I think our oldest one in the system is maybe coming up on two years. So, certainly something to pay attention to over time, especially as we talk about new storage technologies. I brought this forward in our Drive Stats report this time around, because I think that it's probably one of the biggest questions I've been getting at my last couple speaking engagements. Let's just start with CMR, I'd say, and then talk SMR. David, do you want to walk people through what CMR is and what it would mean to a consumer in terms of what a hard drive is itself? Yeah. CMR, it's what we've been running with for- Yeah a while now. I don't know exactly know how long we've been running with them, but it's- Kind of your normal been the standard we've been with. Yeah. Yeah. It's your normal. They're predictable, they're proven performance. It led us to a lot of good innovations over time. But as we're getting to the point where we're seeing more performant workloads with sequential things, we start to see some of the limitations of CMR drives. And I think that's where the industry is now moving into the SMR side of things, which starts to solve some of those issues, and also give us some greater capacities. Yeah which is important too. I think my perspective is that the single biggest driver to SMR is what's been driving the drive industry for a long time. How do you store more data in the same physical drive? And we've seen it adding more platters, we've seen magnetically assisted reads and writes, all that other good stuff. And shingled magnetic recording is quite interesting, I think, because it actually uses your platter zones in a different way. And we have some handy dandy visuals to make this clear because I think that it's a bit complex if you don't understand what's happening on the physical level. So the first thing is the reason this is possible at all is because the width of the head that writes your data is narrower than the width of the head that reads your data. And this is actually true in both CMR and SMR. What you're looking at here is actually a CMR drive, how it would read and write the data, and these bands would sit side by side, traditionally your write bands. Which means that you can write simultaneously and all other sorts of good stuff. In an SMR drive, what you actually do is you overlap the tracks so that you can create more density. Your write width is going to allow you to write like this, whereas your read width is going to be kind of sitting inside that or overlapping that. If you were to look at these side by side, you can really see the difference here. This lets you make more use of the existent space. It does also have implications for how you can read and write. The biggest one is that you can't sequentially write things because you will have overlap. Right? There's things that make it within a data center, things that you have to think about in terms of how you interpret it. There are also firmware implications there. You have drive-assisted or drive-aware SMR, or you have firmware-assisted S. Let me go ahead and look at my notes because I feel like I'm butchering this now. Excuse me. But you have drive-managed SMR, host-managed SMR, or host-aware SMR, and that's just who makes the decision where. Is the drive doing it? Is the host doing it? Or is it a combination of the two? All these things have implications for how we provision drives. They also let you get more data onto a single drive, which is very exciting, right? That's the same way we're talking about what we can do with bigger drives in a single server. Now we can do this in a single drive. We personally do not yet have SMR drives rolled out, but I think the biggest thing that we're hearing from all the drive manufacturers is that this is where the industry is going. If CMR is our normal now, SMR is going to be everything in about 18 months, two years, at least for enterprise. Is that where you're heading too, David? Yeah, I think we're still a little ways out, but that feels like a long time. Yeah. But trust me, it will go by very quickly. So when you talk about why this matters, number one, it matters because we are seeing drives get bigger and a lot of very interesting technology on the bottom of that. And number two, it matters because you have to sort of optimize your storage layer for the new way these things are working. So for Backblaze, that is kind of been our bread and butter this whole time. We are looking forward to it. You do have to interact with that, both directly with the drive manufacturers and within your own system. Now- Yeah. Yeah. Sure. Hey, Stephanie, before we jump into HAMR- Yeah We had one question that popped up with SMR drives. They were wondering, don't they usually have a massively increased rebuild time when they're doing a RAID or drive? They can, but there's things that reduce that. When we're talking about provisioning, we're sort of looking at all the different ways that will matter. I think this is a pretty astute question. I'm looking in the chat. I see, Robert, you asked this. Because it's one of the biggest things that affects parity. We know that our parity schema has had to shift as we have more large drives. As you talk about when you think about what parity is as a formulae, it is in fact just the time it takes to rebuild data. That's one of the parameters, completely without any data loss. If you think about how your shards have to be distributed, the larger your drive, the more likely your shards will end up too close to each other. You actually have to increase and reduce your parity shards accordingly. If SMR takes longer to rebuild, that would also affect your parity schema. When you talk about a single drive rebuild, again, we haven't gotten into provisioning these yet, so we haven't thought about what it means for our testing purposes. There may be things you can do on the software layer, but one of the biggest things is when you're talking about erasure coding, it actually has a built-in mechanism, so that we can control for this on some level. We might change the way our parity schema works in our distributed file rebuilds. But that does also mean that when you're rebuilding a single vault or if you have a drive that goes out, you might have to account for that. Again, Robert, not something we have gotten into testing yet, so I couldn't give you real numbers on that. But certainly something our drive team will be on top of. I throw in HAMR here not necessarily because it's related to CMR, SMR. I know there was some confusion around that. But because a lot of times when you get into the acronym soup of what is happening in drive technology, this one comes up, too. They're like, "Well, but then what is HAMR if these are CMR and SMR?" HAMR, I find interesting because it's one of those, I'm calling it a co-technology, but that's kind of not exactly perfect. But it's another piece of how we write to drives that significantly moved us forward on drive density. Whenever you're writing on a drive, you can see this north-south layer here. Your biggest issue is that if you haven't written things well enough, those bits can flip, and when those bits flip, you have data corruption. The first thing we did to help with this is heat fields, or magnetically assisted writes. Those are two different ways you can create more durability. HAMR itself actually shoots a little laser straight down in there and gets a lot better write durability, which is very cool. It makes much more stable magnetic grains. What's even more interesting about this is that these are typically written onto a glass substrate versus aluminum. You can do that because you can heat it up to a higher temperature. So they're already standard in 2.5-inch drives, and increasingly common in your 3.5 inchers. When people say CMR versus SMR, it's not really a versus HAMR, it's like, and also there is HAMR. But if you look at, say, what is it? The Mozaic drives out of Seagate, I believe all or almost all of those are glass substrate and HAMR drives. I may be misspeaking on the glass substrate specifically, but they're HAMR drives, and that's what's getting them to those 40 TB. Western Digital is projected to get to 100 TB with HAMR technology as well. So I did some linking out in the blog article in case you want to see what drive manufacturers are talking about with that. But just know it's not an either/or, it's an and. I think that's helpful for folks to know. It's also just a great shorthand way of saying it. HAMR's- Yeah pretty good, easy to remember. I did go heavy on the puns this time around with building, considering that hard drives are the building blocks of our data platform and all sorts of stuff. It was great. Yeah. Gotta love the acronyms. Get right in there. I'm seeing one more question in the chat here. Tushar, I hope I'm pronouncing your name correctly: "Do we also track data for SSDs?" What a spicy question that we get often. I will tell you, we have put out data on the SSDs in our system before. It is deeply imperfect, because when you compare what our hard drives do versus what our SSDs do, they're completely different workloads. We don't really have any data-storing SSDs. We do have a layer of SSDs that are a write-through cache. That would mean that they receive the input, capture the data, tell you on the other end, "Hey, we've got your data," because we do, and then they move that through to hard drive in a queue. It gives you better speed as a user. It gives us better ability to control the file uploads. I've considered restarting a report given that we do have some that are sort of data storing now. But if you compare even what the write-through cache is doing versus what our boot drives and servers are doing, it's just not apples to apples. Given that the population is a lot smaller than our hard drive population as well, the fact that we have far fewer drive models getting hit with very different data workloads and in a much less uniform environment. We've held off. Always a possibility we'll bring it back, especially as our platform expands, because I know people are hungry for real data on that front, and so am I. We'll see what happens. No promises. To me, it always depends on if we're giving the right context around the right data points and all that good stuff. If you're interested a little bit about how we use our write-through cache, there's a lot of blog posts on our site around Shard Stash that go into depth about this. If you're just that technical kind of person, those will be some great blogs for you to take a look at. Seeing another question here from James: "Do we normalize failure rate to drive size? Wouldn't you expect bigger drives to fail earlier and more often?" What an assumption, James, and not in a bad way. I've heard it a couple of times. I think that the first thing to take into account is that when we talk about failure, we're not actually talking about failure to write, failure to read, failure to rebuild. We're talking about a true hardware failure here. We go on record about what that means for us in, I think it's the Q3 2025 Drive Stats. This is really when a drive fails and can't be rebuilt or can't be reset. Have we normalized drive rate to failure size? There's a couple of times we've taken slices to look at that, but one of the limitations is that we have deployed in waves over time, almost correlative to drive size. If you look at early on, we were about 4 TB or 6 TB, and then we had a period where 14 TB- 16 TB were quite popular for us, and now we're into the 20 plus. Almost all of our new deployments, with the exception of some 16 TB drives, are 20 plus. What that does is that it introduces a variable that we know has significance. If you say older drives fail more often, which is true, and then you try to compare apples to apples as far as the 14s and the 16s to the 20s that currently exist, that's not really fair. We have done a bathtub curve analysis to say when drives are failing over time, how often do they fail at year zero, year one, year two, year three? Within that, we took some slices of the 14s- 16s, versus the 20s- 25s. So at year two, did the 20s fail more often than the 14s- 16s? At that time, we had maybe four or five models total of 20-plus TB drives in our system. We will likely refresh that analysis again. The short answer is that you got to sort of correct for a couple of variables before we can make the question that you are asking very visible. If you ever want to do that analysis yourself, I will happily remind you that the full log line data set is published quarterly so that you could take that and run it if you want to, instead of waiting for our analysis that comes out whenever we can get around to it, basically. All right. See if there is any other questions here or anything we did not answer. I think we had another question come in by Tushar. He left a reply that he is especially interested in the write-heavy workloads, like the write-through cache. Yes. He was asking would it be possible for us to share how we manage them at scale. Yeah. That's a lot of what the blog posts talk about that we have. Yeah. Stephanie, what other thoughts do you have? We haven't really taken a slice at. Especially interested in the write-heavy workload like your write heavy cache. When things get uploaded to our system, we don't categorize by how many operations on which drives are happening where, right? If you were in a hyperscaler environment, obviously they have different tiers about access and all these other things, which means that you can get a different lens on that potentially, or a different way to attack that. We don't have that data correlated with our drives yet. Even with write-heavy work, we can't even say necessarily that the write-through cache is accepting more write-heavy workloads, I would say. The biggest thing it captures really is small files, instead of write-heavy workloads. As far as access patterns go, I don't think that you have a clear answer there. If we wanted to talk about how that works, really where we have been talking about that is in the Performance Stats series, where we do an external benchmarking report based on Warp standards, which is MinIO's published open source benchmarking of object storage. There we separate things by file size, thread count, and run standard throughput testing as well as upload, download averages. I think you can get a better perspective on our platform there. It's just not correlated to drive failure rates. The other place you might want to look is at our Network Stats blog. It's imperfect as far as getting down to, I think, your specific question. But it does have a perspective on how things are moving into and out of our system. So with the triangulation of the three reports, you get a couple of different stuff, things in there. Noriko, I am so sorry I did not see your question. Also hello, and I owe you an email. I will be getting back to you shortly. We have to plan for SMR drive deployment and HAMR drive deployment. I do not know where those sit on the roadmap. I do not want to speak for engineering. I think it is fair to say, especially with what we just talked about how product roadmaps are going for drive manufacturers, that near future is in the cards depending on how you define near future. Not tomorrow, within five years. I do not know if that counts. It is a good way to put it. As far as system changes, that is something that we do not have the scope on yet. What I wanted to lay the groundwork for in this report, and the reason we are talking about it now is that I think that we did a similar thing when we saw our drive capacity start to raise. We said, "Hey, these things are coming down the pipe. Let us make sure that we have a full understanding of what the effects might be, and then let us track against it and see what actually happens." I am very excited to do that with emerging drive technologies too. SMR, HAMR as well. I think what we will do is the same thing we have always done, which is say, "Hey, guess what? These drives are here now. Pay attention to these models if you are interested in how those are functioning." All right. I am not seeing any more questions in the chat. Anything you can think of, David? Any final thoughts on your side? No, I think this has been a wonderful look at kind of a very concise quarter. Things were consistent. We're seeing some new technologies come into play, and I think it just makes me more excited to see where we go next with our reporting because I want to see the day that we get to 100 TB drives and 120 TB drives and we'll be around to kind of report on how those are functioning David when we get there. I love it. I feel like we just made the whole audience say, "When? Yeah, exactly. Won't be tomorrow, but Yeah It'll be sometime in the future. It is a very exciting time to be seeing all the leaps forward in technology in the hard drive manufacturing space. Always fun to have a front row seat. To wrap it all up, you've got your resources slide here, folks, if you need anything. By the way, Drive Stats at Backblaze is a monitored inbox. You can also reach out directly to me if you'd like. I'm sdoyle@backblaze.com. Then we just took some questions. We'll upload everything else to this webinar page after we're through here. Thanks everybody for joining. We always appreciate it. We'll see you on the next one. Thank you.