49:16 Webinar
FlashBlade & SQL Server: Enterprise Scale Rapid Recovery
Explore how Everpure FlashBlade®, as part of the Enterprise Data Cloud, overcomes constraints through a scale-out architecture for rapid backup and recovery throughput.
This webinar first aired on February 19, 2026
The first 5 minute(s) of our recorded Webinars are open; however, if you are enjoying them, we’ll ask for a little information to finish watching.
Click to View Transcript
Hey, welcome to today's Pure Storage Tech Talk, where we're going to dive into the most pressing challenges in the modern data center. This is su-success paradox. As our data environments grow and become more successful, the stakes for protecting that data get higher, and the bottlenecks for recovering it often become more painful.
Today, Mark and I are here to show you how to move past traditional storage management and into a world of policy-driven orchestration. The real value for you in this session is learning how to achieve enterprise scale, Rapid Recovery without requiring a brand-new set of skills. We'll be looking at some truly impressive benchmarks, including a validation env
that reached a restore rate of a hundred and thirteen TiB per hour across eight parallel SQL Server instances. Whether you're looking to simplify your backup targets or need to ensure your 1 TiB database can be backed up online in just three minutes. W-this talk is designed to give you the architectural blueprints to make that happen.
We will also walk through some cautionary tales and practical, practical testing tips to ensure that when you scale your performance, you don't accidentally saturate your network or cause an outage. By the end of this session, you'll have a clear path to achieving fast, scalable and simple recovery for your most critical SQL Server workloads.
So let's take a reality check. As DBAs, we've actually been too successful, believe it or not. SQL Server estates keep growing. More databases, more instances, larger databases, more copies, more complex instances, and larger retention.
That growth and complexity is needed, but it quietly changes the rules. Most environments didn't fail because backups were ignored. They failed because traditional backup targets simply can't keep up with modern scale and recovery expectations. Here's where it gets painful.
Your SQL Server can't write backups fast. Your network can usually handle it, but the backup target becomes the choke point, especially during restores. And when recovery time objectives shrink, that bottleneck moves from annoying to dangerous.
This is why DBAs end up babysitting backup jobs, tuning compression knobs, and splitting files, scripting around workloads and praying restores finish before the business notices. It's not a SQL problem, it's an architecture problem. This is high stakes because when things go wrong, backups aren't theoretical.
There's how fast can you bring revenue systems back online, meet compliance and audit expectations, and defend your credibility when leadership asks, "Why did you take so long?" At that moment, nobody cares how clever your script was. They care about outcomes, the speed, reliability, and certainty. So here's the real shift DBAs need to make.
It's about managing backups better. It's about orchestrating recovery outcomes. Just like we don't manage every gear in a car, we manage where we're going, how fast, and under what conditions. For DBAs, that means stop managing backup infrastructure piece by piece.
Stop treating storage as a passive dumping ground. Start managing data recovery as a policy-driven outcome. What does data transformation look like for a DBA? Well, from backup silos to a united recovery platform, one scalable target your entire SQL Server estate.
No special cases, no fragile tuning per database. From manageable manu from manual tuning to policy-driven orchestration. Policies instead of scripts. Again, I'm gonna say that. Policies instead of scripts. Templates instead of one-off heroics.
Consistent protection without constant intervention. From cost center conversations to recovery confidence. When restore speeds exceed one hundred terabytes per hour, backups stop being a liability and start being a strategic capability. That's the transformation that matters.
Less knobs and scripts, but an architecture that lets DBAs focus on recoverability, not babysitting backups. And that's exactly what we'll dig into next, how FlashBlade changes the backup and restore conversation entirely. With the presets built into Pure1 workload deployments, like snapshots become fully
automated and repeatable.You start by defining a preset once, covering everything from performance needs to protection policies. Then when it's time to deploy, it's as simple as choosing the preset, naming the workload, the orchestration is automatically handled. Volume creation, QOS and performance settings, snapshot schedules,
replication targets. No manual setups, no misleading settings, no inconsistencies, whether it's dev or test. You can deploy one workload or 1,000 with the same level of speed and precision. This transformation storage from a bottleneck Th- this transforms storage from a bottleneck into a self-service, on-demand resource.
You gotta love that. From a DBA's perspective, this isn't about a new storage platform, it's about removing friction from everything around SQL Server. So first, let's address the obvious concern DBAs always have. I know this, I've been one. This doesn't force change. The Pure Data Platform is included with Purity.
There's no extra license, no separate control plane, and no rip and replace. And if you're already running Pure, this layer on top of what you trust today. And yes, we know backward compatibility matters to DBAs. Your existing SQL workflows, backup job scripts, and operational patterns still work. What changes is how much manual effort it takes to keep these consistent as your
environment grows. Where DBAs really feel the impact is provisioning and protection. Instead of configuring volumes, performance snapshots, and replication over and over again, Pure Fusion lets you define these behaviors once and apply them consistently. That means the right performance characteristics every time, the right
protection policies every time. No one-off databases that behave differently during recovery. And we know recovery matters. Not the backup, it's the recovery. This dramatically reduces risk, especially in large SQL estates, where inconsistencies
are usually discovered during restores when it's already too late. And this is the key DBA benefit. Automation here isn't about speed for speed's sake. It's about confidence. When configuration is enforced automatically, fewer human errors, fewer missed snapshot
schedules, fewer surprises during failover or restore, which is when it really counts. You know that. So instead of storage being another DBAs have to coordinate, chase, or double-check, it becomes workflow-driven and predictable. The outcome for DBAs, faster provisioning when new databases show up,
consistent behavior across environments, and most importantly, reliable recovery when the business is watching. That's why Pure Data Platform matters to DBAs, not because it's new, but because it finally makes storage behave like the rest of the modern SQL Server stack. Automated, repeatable, and boring in the best possible way.
Now, we've spent the first part of this talking about how Pure Storage, policy-driven and predictable. But even with a high-performance backup target like FlashBlade//S behind you, real-world results still depend on how your SQL Server environment is tuned. That's where Mark comes in.
Mark is now going to dive into the practical side, tuning SQL Server, a database's layout, and backup configuration so you're actually restore performance your hardware is capable. All right. Well, thanks for the intro there, Melody. Again, my name is Mark, Wilkinson.
I'm a Consulting Field Solutions Architect here at Pure. And, let's talk a little bit about FlashBlade and SQL Server. So three reasons, why this is such a good combination. One, simplicity, and Melody touched on this a little bit. There's not a lot of new skills to learn as a DBA when you start using FlashBlade.
It's just another backup target. Obviously, your storage admins might have a little more work to get things set up, but for you, the DBA, it's, it's literally just another backup target. Speed, both, fast backup and fast restore. No compromises there.
Oftentimes, you know, backup appliances can be limited when it comes to recovery time. They're really great at getting a lot of data written really fast, but when it comes time to actually read that data and restore your databases, you can run into bottlenecks. So with FlashBlade, you get both. And then finally, the scalability.
In the validation environment and some of the results I'm gonna, I'm gonna walk through in a minute here, we scaled from one instance to eight and got the same performance, and I'll share those numbers with you in the next slide. And also from a scalability standpoint, the FlashBlade can scale with your workload. If you need more throughput or you need more capacity, there's options to do both of those
things to increase both of those independently. All right, so these are the big numbers. These were the, these were the fun and exciting numbers from our validations. So again, you get speed and scale with FlashBlade. So we were able to hit 113.3 TiB per hour restore, and that was across eight SQL
Server instances in parallel. All of the tests were done with, 1 TiB databases across eight SQL Server instances. And the scale part here is that we were to restore one one-TiB database in three minutes.But we were also able to restore eight one TiB databases in three minutes. So even scaling from one instance up to eight, there was no degradation in, you
aggregate performance across all of those. So how did we get here? We used FlashBlade, simple as that. No, not really. I've got a couple other slides here, obviously, that we're gonna go through. FlashBlade helps, but fast storage isn't
always enough. With the FlashBlade scale out architecture, it did scale linearly as more load was added, which was fantastic to see, but there was also some work to do on the SQL side. So SQL Server layout and design choices made for maximum backup and restore throughput. The backup configuration itself was designed for maximum throughput, and
environment that we used was opti- mized for minimum bottlenecks. One thing I do wanna point out is that everything that I'm gonna walk through here, it was all just exploring the, you know, what's possible with FlashBlade. So nothing that I'm doing here is optimizing for OLTP workloads or anything like that. I was, I was optimizing for fast backup and restore just to see what was possible.
Now it's not completely outside of the realm of possibility. There's some things in It's like the configurations that I use are, are fairly real world things. Like, we didn't go completely nuts, which I'll show you here when we get to the environment. But first, I wanna talk a little bit about the, the choices that have to be made on the SQL
Server side to get the most out of, backup and restore. So we're gonna talk a little bit about parallelism. And this is gonna just be kind of a dive into how SQL Server manages backup and restore operation, and how you can influence that for more performance. We're gonna start with a really simple example and then we'll, we'll get
more complex as we go. All right, so here we've got a simple just single data volume, single backup target with a SQL Server. Now, when you execute a backup, we're gonna get one reader thread that's gonna read data from the data volume, and then one writer thread that's gonna write to the backup target.
And in this example, the backup target can be anything. It could be an SMB share, it could be a, you know, an object bucket in S3 or on FlashBlade. It could be, could be anything. Anywhere that you're gonna be writing your backups to, but this is the absolute simplest kind of layout that you can have.
Is it gonna be super high throughput? Probably not. If your environment is really constrained, this might, this might work for you. You know, this, this might get the job done. But obviously that's not what we're here to see.
So how do we make this better? How do we make this faster, more throughput? So here we've got, an example where we're going to, increase the threads, increase the parallelism. Again, we've got our volume there, our SQL Server and our backup target, but we're gonna
change a couple things. So first off, we'll add another data volume, and another data file. When you add a new volume, the only way you're gonna be able to take advantage of it is by breaking your database across multiple files on those volumes. So that's what we did here. Now, when you execute that backup, you're gonna get two reader threads.
So you're gonna get two threads that are actually reading those data files, and you're gonna get more throughput. Are you gonna get 2X the throughput? Probably not, but you're gonna get more, assuming that your primary storage can handle it. We're also gonna add more backup targets.
And again, this could be These could be objects in object bucket, could be files on an SMB share. Doesn't matter here. When you do that, you get f- one thread per file. So in this case, we've got four writer threads. So from the previous example, we just had the two threads.
Here we've got six. Again, not gonna be a 6X performance increase, but it is going to get you more throughput, as long as the environment can handle it. And I'm gonna repeat myself and say that 100 times. All of this depends on your environment and what's possible in your environment. And we're gonna talk about testing later 'cause that's a very, very important part of
all of this. And for all of you rule breakers out there, or people that like to really push the limits, just so you know, there's a maximum of 32,767 files per database. So you can only go so big. In the validation environment I used eight data volumes, so I think 32,000 might be a
little bit overkill, but I used eight. I used 24 backup files, and, and got some fantastic performance. As far as the backup files themselves go as well, there's gonna be a max of 64, which I would absolutely recommend not going that large. I, I Like I said, I went to 24, which was even a little bit much
it's important to test. So those are the limits. They're there. I would not try to come close to the limits. It's definitely not a goal, it's a limit. All right, so let's, let's move on here. I'm gonna talk about SMB.
SMB is a little different. There's a few other things you can do to speed this up and things you should do to speed this up, because it is gonna become a bottleneck once you really start, fanning out across a lot of files for your backup. So again, same setup.
We've got our volumes here. We've got two volumes, a SQL Server and our backup targets. Just like before, we're gonna get two reader threads, one per volume. Now things are gonna get a little bit different. So we're gonna add files, but we're also going to add DNS entries,
pointing Two DNS entries pointing to the same SMB host. And when I say SMB host, that could be a file server on your network, it could be a FlashBlade like it was in this case. But we're gonna add an extra DNS entry, and I'll explain why in a secondSo just like before, we've got four backup files, so we get those four writer threads.
But now something a little bit different is gonna happen. So when you write to an SMB share from a Windows host, the, the host name, the u- the host name for the, the SMB host is used to create a unique SMB session. And it will spin up one session per unique host name. What this session does is it controls all the IO operations between the Windows server and
the SMB target. Windows isn't great at handling those, those sessions. The-- Each session has a queue, and the queues become overwhelmed pretty quickly. So one way to get around that and increase your throughput is to get more queues to be created.
And a very simple way to do that is to just add more DNS, names for the same SMB target. It's not doing any sort of IP address lookups or MAC address lookups or anything fancy like that. It is literally just using the host names. So if you have multiple host name entries in DNS that all point to the same SMB target, and
you reference those targets in your backup scripts, you can increase your throughput quite a bit. I- I'm trying to remember here exactly, but even going from, one to two, in the lab environment, I think I saw something like a twenty or thirty percent throughput increase, so it was qu- it was pretty so don't forget about this step if you are using SMB targets.
This is a pretty simple thing to do. It's simple in practice. I know maybe you might have to talk to your, your system administrator people to, to get them to add some DNS entries for you, but it's, it's definitely, it's definitely worth the time and effort to convince them to do that, because you can get some big gains here.
All right, and now S3. S3 is, a little different and, a bit more complicated. But again, we're, we're starting with the, the two volumes here. We've got four backup files. You don't have to use multiple DNS names to get extra throughput for S3.
It, it does all that on its own. Well, it, it handles parallelism on its own and, and, you don't have to do any tricks to get, to get extra throughput. So like before, the, with the other examples, we get, you know, one reader We get one writer thread per, per backup target.
In this case, these are gonna be objects. But we get something a little bit different here. So when you are using S3 as your backup target, it uses something What the multi-part API does is it allows, it allows you to break your, your object up into small parts and then send those parts in parallel.
So it's a way to just, you know, get more throughput, more performance. But it comes with some, some limitations and caveats, which I will talk about briefly here, and we'll go into a little bit more detail later, 'cause it's really important that you understand this if you're, if you're thinking of using S3 as a backup target. So each backup object is split into parts.
The max transfer size setting of your backup command is what defines the max size of those parts. Each object can have a maximum of ten thousand parts, and just like with any backup, you can have a maximum of sixty-four, you know, objects/URLs in this case. All of that, if you do the math, means that you have a max backup set size of twelve point
two TiB possible. So that's a hard limit if you're gonna be backing up to S3. So if your backup set size is larger than twelve point two TiB, it's not gonna work. It's not going to be able to, split it up into enough parts to, to be able to send to, to an S3 target.
Now that's, that's a lot, right? Twelve point two TiB, that's a pretty huge backup set, so I don't think it's gonna be a limitation for a lot of folks. But if you do have databases where your backup sets are approaching that size, just keep that in mind. All right.
All right, let's talk a little bit about the environment I used, and then we'll go through some results and some, some cautionary tales, as, as Melody put it in the So environment design, again, designed for middable bot- minima- minimal bottlenecks, sorry, and maximum throughput. This was done in a virtual environment.
There were eight ESX hosts, each with ninety-six cores and a half TiB of memory. Primary storage was fiber channel-connected FlashArray. I had four different FlashArray device, devices, so we had two ESX hosts connected to each array. And then the backup targets, were three different models of FlashBlade, the FlashBlade//E, the S100, and the S200.
And those were all connected via eight one hundred gigabit Ethernet links. And I tr- I tested both SMB and, object store/S3. One thing I don't think I mentioned through, in the REST of this, though, is that the, the performance between S3 and SMB was pretty close. S3 was slightly slower, but not enough it would make a, like, a material diff.
So they're both good options, as far as performance goes. Database instances, there was one instance per ESX host, eight instances total. Forty, vCPUs and a hundred and twenty-eight GBs of memory per instance. Like I said, this was designed for minimal bottlenecks and maximum throughput, so I wanted to make sure that each of the ESX hosts had a ton of headroom, and I wasn't getting
any, like, noisy neighbor situations or anything like that. So most of these, ESX hosts were pretty, they weren't busy at all, you know, when, when I was running these tests. 'Cause again, I wanted to make sure that I was, I was getting maximum throughput and not hitting CPU bottlenecks or anything like that. Now I will admit that I failed in that respect, because, we did end up seeing
in the, the fiber channel HBAs that were connected to the ESX hosts. They could only pull data off of the FlashArray so quick, and write it so fast. SoOur, our results were, were limited by that. But that also speaks a lot to the, to the, you know, the performance of the FlashBlade. The fact that eight instances, using, 32 GB fiber channel connections could not,
could not overwhelm it, so. But back to the database instances. They were all Windows Server 2025, SQL Server 2025, with one TiB databases. As I'd mentioned previously, there's eight data volumes with eight equal-sized data files per vol- well, eight equal-sized data volumes, files spread across those volumes.
One log volume and all formatted, NTFX- NTFS 64K allocation unit size. I felt the need to put the last part in there, the NFS 64K, because when I read that as a best practice, me being me, I had to go test it and make sure that it was still a best practice, and, I'm happy to report that it is. So that's still good guidance.
All right, backup settings. So I did use compression. I did tests with and without compression, but I, I used compression. I used the new Zstandard compression that's available in SQL Server 2025 Plus. The reason I use that is, again, I wanted to make sure that, there were
here, and Zstandard uses about half the CPU in my tests than the, the standard default compression does. So all of these exam- you know, all of these results that I'm, that I'm getting here would also be possible using the standard SQL Server compression. You would just notice higher CPU.
And as we all know, when you're, when you're tuning backups, it's a balancing act, so. In this case, I, I wanted to get maximum throughput, so I went with the Zstandard. Max transfer side- size, I used the allowed, which is four MB for SMB and 20 megabytes for S3. Be careful with these settings.
Using really small MTFs can impact storage performance. So again, test, test, test. And then I used 24 backup files, again, to get as many threads as I could. These boxes had a ton of headroom because they were 48 cores and no so I had a lot of threads to work with, so I wanted to, to maximize that as much as
possible, without going completely overboard and using something I would n- never possibly imagine using in production. I wanted to keep all of my tests kind of production-ish. All right, let's take a look at results. All right, so this is backup throughput.
I hadn't mentioned that yet in this presentation. We talked about that 113 TiB number. But I thought it'd be cool to see the backup numbers as well, and we were able to get up to 60, roughly 60 TiB an hour on the, on the S200. The, the FlashBlade//E, which is the or capacity optimized, FlashBlade,
did great as far as the multi-instance. A little bit slower for the single instance, performance, but again, it's a optimized device not meant for, for high performance. The, S100, solid single instance and multi-instance performance. And then of course, the S200 is the, the best of the bunch.
It's the, the biggest box that, that I tested. And 60 TiB per hour is fantastic. I mean, that should make a lot of folks happy. That's, what? A TiB a minute. And these numbers too that I'm sharing are all, like, wall clock time, real numbers.
I took the size of the data divided by the actual, you know, wall clock time it took to execute the statement. So this isn't, numbers that were kind of backed into based on throughput numbers that I saw, you know, staring at, you know, FlashBlade transfer, throughput numbers or anything like this. This is actual, like, time that a DBA could
expect things to take. So if you had 58 TiB of data to backup, it should take an hour based on these, based on these tests, assuming your environment looks exactly like mine. I should have that caveat. Restore performance. So this is where we get to see that big number,
113 terabytes per hour. So the E, again, capacity optimized device, but it, it, it really performed fantastically in the restore operation. S100, solid, solid choice as well. Lots of room to grow. All these tests were done on single chassis
configurations, so you can always expand these, you know, to get more, more throughput. And then the S200 with the, the big number is best of the bunch. And like I had mentioned before, we did hit limitations of our environment at this point. The, the actual connectivity to the Flash Arrays that we were using, just couldn't keep up with the S200. The FlashArrays themselves were fine.
We weren't overloading them in any way. It was just the connectivity between the two. All right. And now this is probably the most slide that I'm gonna share today. Test, test, test, and then when you're done with that, test some more.
There's really no hard and fast rules here. Everything needs to be tested thoroughly. If you don't test it, you're gonna run into problems. When you're dealing with really high throughput backup and restore, there's a lot of things that can break along the way, in your environment.
So, like, you really need to make sure that you're, you're testing every little change that you make, to make sure that you're not overloading anything in your environment. So to that point, I've got, I've got two example scenarios. One of them is 100% I found this during testing example. Another one is one that I actually experienced in real life.
So we had discussed a little bit, I was talking about the kind of complexity of backing up to S3 as far as, making sure that your backup is actually gonna fit. So I wanted to share a scenario outcome, 'cause the outcome is not what you might expect.So in this scenario, I'm a DBA, I've got a project. We've got our new shiny FlashBlade.
We wanna move from SMB to S3, 'cause I wanna be able to, you know, replicate my backups to the cloud, to, let's say AWS S3. So I wanna use as much as my original configuration as possible because our backups have been running great. Why mess with a good thing? With my current backup settings, I'm using the default max transfer size.
I'm writing to four files on my SMB share. I'm not using compression. So for our new, you know, S3 setup, we're gonna continue to use default max transfer size, which for S3 is 10, 10 MB, by the way. We're gonna write to four URLs/objects now instead of files since this is S3.
We're still not gonna use compression. In my environment, the database that I'm backing up has a total backup set size of 530 GB. The instant CPU is usually greater than 90%, so this thing is smoking all day don't really wanna add any more load to it.
Worker threads are usually also up above 90%, and thread pool waits are not an unusual occurrence. That sounds contrived, but these environments exist, so I really want, to make sure that they, they pay attention to these types of things, when they're testing backup because it can impact, can definitely impact the, the performance
of the, of the instance. So what's gonna happen in this case? The backup is gonna start fine. You're not gonna see any errors. SQL Server's gonna use four separate threads to start reading, 10 megabyte chunks of data.
So remember, we've got, you know, we've got four threads, one, one per I, sorry. I said reading data. It should be writing data. Just confused myself there. We've got four different URLs that we're writing to, so we've got four threads.
It's gonna start reading data in 10 MB chunks, 'cause that's what the max transfer size default setting is, and it's gonna start sending that data down the wire to whatever the S3 target is. And again, this could be FlashBlade, could be AWS, really anything that speaks S3, this is gonna apply to. 75% of the way through your
backup, it's gonna fail. It's gonna give you the most vague device error, essentially just IO device error, and not really give you anything to work with there. Why does this happen? You've got four URLs. Remember, we've got 10,000 parts per object max that we can split things up
all, it's split up into, sizes of max transfer size. So what that means is that we got 4 URLs times 10 MB times 1,000 is 400 GB backup set max. So with our settings that we pulled over from when we were using SMB, that means our, you know, our backup set could be 400 GB max.
But remember, our backup set's actually 530 GB. So now you have 400 GB of data sitting in S3 that's not usable. So the, the way that the, the multipart API works is that, it doesn't understand things like progress. It doesn't know how many parts you're gonna send. And this is, this is an S3 API.
This is just how it works. It's not any sort of limitation with SQL, it's not a limitation with, with FlashBlade or anything. It's just how it works. So it doesn't know how many parts are it doesn't know how big any of these anything are, it just accepts parts until it f- gets a final request that says, "Hey,
I'm done sending parts. Here's the map on how to stitch all these parts back together into an object." so again, there's no, there's no way for it to know progress. It doesn't understand progress or anything like that. It just waits until the client says, "Okay, I'm done.
This is how you put everything back together." So because of that, it has start writing a backup whether or not your backup set's actually gonna fit, whether or not it's gonna fit within these, these boundaries and limitations of the S3 API. So in this case, it sent 400 GB before it hit that 10,000 part limit, and then it was like, "Oh, well, I can't break this up any more parts, so I'm gonna fail." so
sit there for however long that took, you know, maybe 10, 20 minutes, maybe an hour, on the size of the database, you know, saturating your link with all this data being sent to your backup target and then have it fail, and then have to do it all over again. Not only, is that obnoxious, but you now have 400 GBs of data sitting in your S3 target taking up space, and you can't really see it, without hitting a, hitting an S3
API to pull those parts backup and, and clean them up. So you can really get yourself into a mess, if you do this. So really be careful and make sure you do the math, before you start, trying to use S3. One little cool caveat here that also kinda goes back to what Melody was with the policy-based administration here is that on FlashBlade you can set up a,
policy-based option that will clean up these like kind of orphaned parts that can be left behind, when a multipart upload fails. And other, other providers have other methods, other, other things that you can do to, to clean it up. But, but yeah, this is definitely something that can happen. So you'll have to clean all that data up after
it fails, and then figure out why it failed and figure out how you can tune things. So how do you recover from this? You can increase max transfer size, but when you're targeting S3 that requires turning on compression, that is a SQL limitation. And if you remember, our s- our instance is already at 90% CPU, so it's not gonna be able
to handle that, so you're stuck there. You can add more URLs and targets, but again, that's gonna add more threads, and if our thread count is already really high in that box and, um-You know, we're already seeing thread pool waits. It may not be a good idea to do that so you might just have to move back to SMB.
So don't be this person. Do your testing, do the math, and, and f- and make sure that your backups are gonna fit within those limitations, and you'll be good. Now I'm, I'm a fan of S3. Don't get me wrong. I think it's great.
I just think there's, there's a lot of caveats that you have to be aware of. You just have to be careful when you're using it. Once you get there, there's a lot of, a lot of nice data protection features and things that you can start using. Second scenario. The DBA finally talks leadership into buying a FlashBlade for backups.
Yay. Big win there. The DBA read through my white paper on making backups go fast. Even better. So they decide to write to 24 backup files across eight SMB host tapes just like I do in my paper. They run a test backup.
They completely saturate their top of rack switches on their rack. SQL Server instance goes to 100% CPU, and the company experiences an outage. Don't be this person either. Not every environment is going to be hand- be able to handle maximum throughput. I, I can't stress enough how much throughput the FlashBlade can actually handle.
So it is not going to feel any pain at all. You really need to make sure that your network can handle the backup throughput pushing 'cause I can almost guarantee that the FlashBlade will be able to do it. So testing tips. Start with small changes. Add one more backup target one at a time.
Test it out. See how it's gonna perform. Add one more data volume at a time. Now I know that, like, that, that one, that one, those four words there, one more data volume, there's a lot of work behind that 'cause you've gotta rebuild indexes across those volumes and all of that.
So, I know it's not as simple as just adding another volume and here you go, there is just to do incremental changes and make sure that you're not gonna overload anything. Use the null device to watch for thread exhaustion amongst other things. So for those of you that don't know, you can backup to null, which essentially just the
bits go away. They just get spilled on the floor. I don't know where they go, but they don't get written anywhere. This is a really good way to baseline your backup performance and see what's possible f- when reading from your primary storage. It's also a good way to see, you know, you've got a box that's kinda hovering
max worker threads all the time, ru- running a backup to null is a good way gonna run into any sort of thread exhaustion issues or anything like that, 'cause you can kind of replicate what the backup is gonna be doing without actually taking a backup. When using null too, I'll say, make sure you're running copy-only backups so you don't mess up your, your backup chain.
Get good baselines before you do any testing. Again, you can use null, to test your primary storage throughput, and just of, you know, what's possible. If you can only read from your primary storage at, like, a GB/s, you're not gonna be able to write a backup faster than that, because, you know, you're gonna be,
you're gonna be bottlenecked there at your primary storage. So make sure you get a good baseline just to set your expectations so you know what you can expect when you're writing your backup. And then monitor all parts of the stack with each change, so primary storage performance, storage fabric, your instance performance, network throughput, the backup target
performance, and just make sure you've got good metrics for all of these that you can watch when you're running these tests. And this is a good exercise anyways just to know a couple key metrics for all these, these pieces of the puzzle. But it's really, really important that you monitor all of that, when you're, attempting anything that, that we discussed
here today. All right. And that's it for me. Any, any questions or anything that anybody had? Well, thanks Mark. Mm-hmm. So our first question is, if we already have a working
backup solution that technically meets RPO but not RTO, how disruptive is it to introduce FlashBlade as a new backup target? It's not. Well, I mean, I say that so quickly. Um- it's not hard to start using it. If you are using something like, like Ola Hallengren scripts, it's very simple to, just,
you know, change the SMB target that you're writing to. But that's I mean, that's essentially it. You're just changing the, you know, the SMB or the, the object path that it's going to. Object is a little bit more difficult because there's some SQL Server configuration you need to do, as far as adding, your, your authentication credentials, to SQL Server
you know, for the object target. But for SMB, it's, it's very much just replacing one path with another. So it's, yeah, it's pretty straightforward to, to implement. Okay. Excellent. And what about, do you have any experience with anyone using this for
AGs and remote replicas? In what, in what, I guess, in what context? The person who's asking the question just, standing up a replica. I mean, it is just a normal backup target, so I mean, s- standing up a replica and, and
restoring from it is no problem. I mean, something like that I would think more of, more about snapshots, but I mean, the FlashBlade itself isn't gonna, isn't gonna impact anything in that, in that use case scenario. I mean, let me know if there's something specific that you're, that you're trying to find out there though.
She says so, so restoring to STaaS one. Oh, restoring to stand up one? It's- Do you want me to pop mute and just ask the question?Can they? Well The last comment was, so restoring to STaaS, to STaaS one up. Oh, restoring a stand one up.
Again, it's just another, You're just ex- It's just another SMB share. So Whoa, where did that music come from? It's just another SMB target, another SMB share on your network, so it's Restoring from it is just like restoring from, you know, from any, any SMB share. So there's no, no big difference there.
Okay. Excellent. Yep, that seems to have answered your question. Yeah. And then, the next question is, how architecture behave in a mixed state where some SQL Servers are older versions or are not yet on SQL Server 2025?
So 2025 isn't a requirement at all. The only reason I even mention it is because of the- Mm-hmm the Zstandard I used. So this would work fine with really any, any version of SQL Server that can talk to SMB, which I don't, I don't even know when they started that, so everybody here should be fine.
But any version that can talk to SMB is gonna be fine backing up to this, and that can backup to URL, which again, I can't remember what version they started that in. I think it was maybe 2016 or 2017. But yeah, any of those versions should be able to, to use the FlashBlade as a backup target without a problem. Yeah, nothing I'm doing here other than that
compression, was, was 2025 specific. And again, just did that because I was concerned with, CPU being a bottleneck. Yeah, but that is a great feature. I love that one. Yeah. And then, I think this might be our last question actually. Are, are these restore speeds realistic for customers, or are they only achievable in a
highly controlled lab environment? I mean, that is a good question. So I did try to keep this as production as possible, but obviously my lab environment doesn't have a lot running in it. And not everyone is gonna have, you know, 32 gigabit, fiber channel connections to primary
storage and 100 gigabit ethernet. So this is really what's possible. If you've got a really, if you've got a fast storage fabric, you've got a really fast network, then yeah, these numbers are absolutely possible. There's nothing, there's nothing special about, about the configuration here other than I was
using really high throughput components. So, I wanna say I had four 32 gigabit, channel connections to the primary storage from each, ESX host. And then, as I'd mentioned earlier, there's eight 100 gigabit, 100 gigabit ethernet connections to each of the FlashBlades.
So it's definitely a high throughput setup, but not outside of the realm of, of what folks could have, you know, in their environment currently. Okay. And okay, we And we Since then, we've had a couple of other questions come in, quick ones. So using this to restore, can you also use no recovery?
Hold on a second. Sorry, I Oh, so, um- Oh, my Can we use this- Sorry, I was, I had music playing on my computer. I thought it was on the webinar, so I apologize for that. Go ahead. Okay. This, you were You've been using this for restores, but can we also
use this for no recovery? Sorry, use it for what now? I guess backups with no recovery. Oh, yeah. Yeah, absolutely. It's just another, it's just another backup target, so it acts just like a file share. It's not going to A- anything you can currently do, I mean, unless you're using a
dedicated backup appliance that uses special tooling or something like that. If you're taking native SQL Server backups, this will support anything native SQL Server backups can do. Cause again, it's just a It just presents as a file share, an SMB file share on the network. So yeah. Yeah, you can absolutely use, use no recovery.
That's not a problem at all. Perfect. And then the retention policy, is it directly related to the space available in the storage? That I don't know. I'm not sure if you have any, any comments on that, on that, Melody. I'm not sure what the options are as far as, setting up your retention policies there.
Unless you're specifically talking about, when I was talking about cleaning up those, those object parts, but I'm not quite sure I understand the question. I'm not sure how the two are related. We can get back to him on that. Okay. All right. Anything else?
Nope. I think that's all the questions for today. Well, fantastic. All right. Well, thanks everyone for, for joining here. Looks like we got a couple more slides to slide through here. I'll let you do the talk in there, Melody.
So if you have an opportunity, we'd love for you to stop by our booth at RCA, which is coming up March 23rd to the 26th for, threat detection. Next slide. And of course, if you're a member of our Pure Storage community, we'd love for you to check out this QR code and join our Pure Community at pure- purecommunity.purestorage.com,
or scan the QR code. Next slide. Thank you for joining, and join us at the next Pure Tech Talk. We'll follow up with e- by email with additional resources, and thank you for joining us. See you soon. Thanks, folks.
Mark Wilkinson
Consulting Field Solutions Architect, Everpure
Melody Zacharias
Technical Evangelist Director, Everpure
SQL Server estates are continually growing, and traditional backup targets often become the primary bottleneck in failing to meet aggressive recovery time objectives. Stop managing backups and start orchestrating them.
Explore how Everpure FlashBlade®, as part of the Enterprise Data Cloud, overcomes constraints through a scale-out architecture for rapid backup and recovery throughput. We will share baseline performance data, including restore speeds exceeding 100 TB/hr, and provide practical guidance on integrating FlashBlade with native T-SQL backup using SMB and S3 protocols.
Key Takeaways:
- Operational simplicity: Uses policy templates to eliminate manual configuration and human error.
- Flexible multi-protocol integration: Advantages of using both SMB and S3-compatible object storage as native backup targets, including the use of multiple Virtual Interfaces (VIFs) to maximize throughput.
- Optimized performance tuning: Gain insights from real-world validation data on how to balance host CPU usage and compression (using ZSTD) to achieve the most efficient backup and restore windows for your environment.
We Also Recommend...
Personalize for Me
My Updates
No updates at this time.