Run the math on a petabyte-scale ransomware recovery and the backup repository, not the backup software and not the network, is often the choke point. A dedupe disk appliance is built to ingest fast, but a mass restore forces it to rehydrate and stream data back out, and at petabyte scale the difference is measured in days of downtime. That is the decision moment this brief is about: vendors now price capacity flash for backup at what they describe as disk-comparable acquisition cost, and that changes who should still be buying spinning disk for their repository tier.
Below: what changed in capacity-flash economics, why restore throughput is now the ransomware SLA that matters, where dedupe disk still wins, and vendor-by-vendor reads on Everpure (formerly Pure Storage, renamed in February 2026), NetApp, and Veeam.
What changed
For years the objection to flash as a backup target was one word: price. Capacity flash, including QLC, has weakened that argument at the acquisition line. Everpure’s FlashBlade//E, which its datasheet calls “an all-flash, capacity-optimized, unified file and object storage platform,” is pitched at data protection and other repository workloads “at an acquisition price comparable to disk-based products, with lower long-term cost of ownership.” On the block side, Everpure builds FlashArray//C on “QLC DirectFlash.” NetApp answered from the other direction: its AFF C-Series (current models C30, C60 and C80, “built on high-density NVMe capacity flash technology”) puts capacity flash under the full ONTAP stack, and NetApp’s AFF page says it handles “DevTest sandboxes, backup targets, and secondary storage needs,” scaling “from 122TB to 700PB.”
Meanwhile the density curve keeps moving: Everpure’s FlashBlade//S datasheet now lists 300TB DirectFlash Modules for the //S200 R2 and //S500 R2. The verdict: as of October 2026, “flash costs too much for backup” is no longer automatically true. It is a workload-by-workload calculation, and that is new.
Why it matters: restore throughput is the new ransomware SLA
Backup windows stopped being the main constraint once incremental-forever chains and changed-block tracking became standard practice. The constraint that boards now ask about is the clean-room recovery: how fast can you restore everything, from a known-good copy, after an encryption event. That is a full-fidelity, sequential-read-at-scale problem, and it is exactly where dedupe disk architectures are weakest, because every restored block has to be rehydrated from deduplicated segments scattered across spindles.
Flash targets invert that. Everpure positions FlashBlade//S for “data protection and rapid restore”; treat any vendor restore figure as scale-dependent and make the vendor prove it on your data. Instant recovery raises the stakes further: Veeam’s Instant Recovery “runs workloads directly from compressed and deduplicated backup files,” as temporary spares “with limited I/O performance” until you migrate them, so the repository’s read path decides how usable those workloads are during the incident. If your recovery SLA math prices a day of downtime high, the repository’s read path is the SLA. The RTO/RPO benchmarks brief covers how to set those targets by tier.
The economics, honestly
Here is the honest counterweight: purpose-built dedupe appliances can still win on cost per terabyte at rest when dedupe ratios run high. Backup data often dedupes well, and an appliance built around inline dedupe can land effective cost per terabyte below an all-flash system. If your repository exists to satisfy retention policy and restores are rare, small, and non-urgent, dedupe disk remains the rational buy.
| Dedupe disk appliance | Capacity all-flash target | Generic disk repository | |
|---|---|---|---|
| $/TB at rest | Lowest when dedupe ratios run high | Vendors pitch disk-comparable acquisition prices and lower lifecycle cost | Cheap to buy; power and rack space add up at scale |
| Mass restore throughput | Weakest: restores must rehydrate deduplicated data | Strongest: sequential reads at flash speed | Middling; spindle-bound |
| Instant-recovery / live-mount performance | Constrained by rehydration | Flash read latency suits live-mounted workloads | Spindle-bound; suits a handful of VMs |
| Good fit | Long retention, infrequent restores | Aggressive recovery SLAs, ransomware clean-room plans | Small estates, tight capital budgets |
The takeaway a VP can repeat: dedupe disk optimizes the cost of keeping data; flash optimizes the cost of getting it back. Price your downtime and the spreadsheet picks the tier for you. For the fuller cost model, see the backup storage cost-per-TB analysis for 2026.
Vendor read: Everpure (Pure Storage)
Everpure made the aggressive bet here. FlashBlade//E is a purpose-built play for exactly this tier: scale-out file and object on DirectFlash modules, with a pricing posture designed to win the disk comparison at the quote stage. Strengths: a platform built for repository workloads, an Evergreen model that the datasheet says “eliminates the cost and disruption of forklift upgrades,” and operational simplicity. Where it is weaker: Everpure’s economics depend on its density roadmap holding, the entry configuration is sized for large estates rather than mid-market ones (the FlashBlade//E datasheet lists a minimum configuration that “Starts at 4.5PB”), and buyers should pressure-test the claimed lifecycle savings against their own power and facilities costs rather than accepting vendor math. Everpure fits the enterprise that has decided recovery speed is a board-level requirement and wants a dedicated repository platform to deliver it.
Vendor read: NetApp
NetApp’s C-Series is the incumbent-friendly path. You get capacity flash under ONTAP, which means the tooling, SnapMirror replication, and SnapLock and snapshot locking immutability your team already runs: a real advantage when the backup target must slot into an existing compliance and replication fabric. Strengths: one operating environment across primary and secondary tiers (NetApp says ONTAP “runs across both AFF A and C-Series”), mature immutability, and ONTAP’s dedupe and compression applied to the capacity tier. Where it is weaker: ONTAP is a primary-storage OS carried into a capacity tier, so you pay some complexity tax a purpose-built repository avoids, and C-Series will not always be the cheapest option at rest. NetApp fits the ONTAP shop that wants flash-speed restores without introducing a new vendor or a new operational model. The Everpure (Pure Storage) vs. NetApp head-to-head goes deeper on where each platform earns its premium.
Where Veeam fits
Veeam does not sell the target, which is precisely why its read matters: the software layer is where flash repositories either pay off or get wasted. Veeam’s scale-out backup repository puts a performance tier of backup repositories in front of capacity and archive tiers on object storage, so you do not have to buy flash for every retention point, only for the restore-critical window. Instant Recovery is the other half of the argument: running workloads straight from the repository makes its read speed visible to users. Veeam’s storage snapshot integration with NetApp ONTAP also gives NetApp shops snapshot-orchestrated workflows the generic targets do not get. The caution: do not let a storage vendor imply flash is required for safe backups. Immutability depends on what the target supports, not on its media. Veeam’s hardened repository “requires the block storage” (local, iSCSI or Fibre Channel) and rules out NFS shares and SMB-mounted volumes; NFS and SMB repositories can be made immutable only when the share is hosted on a WORM-capable storage system; and object storage repositories rely on S3 Object Lock and versioning. Fast Clone on a Linux repository needs XFS with reflink support. None of that requires flash. Flash buys speed; immutability is a target and configuration decision.
What to do about it
- Do the throughput math first. Divide the terabytes you must restore in a clean-room scenario by the hours your business case allows. Then measure your current appliance’s real restore rate against that number; ingest specs will not tell you.
- Tier, don’t replace. Put flash under the restore-critical window and keep dedupe disk or object storage for deep retention. Veeam’s scale-out backup repository and equivalent constructs make this a configuration exercise, not a migration.
- Price downtime into the TCO. If one avoided day of outage exceeds the multi-year cost delta between flash and disk tiers, the flash target is the conservative buy, not the extravagant one.
- Make vendors prove restore rates on your data. Ingest benchmarks are marketing; demand a proof-of-concept restore of your actual workload mix before signing.
Frequently asked questions
Is all-flash storage good for backups?
Yes, with a caveat. All-flash targets excel when restore speed matters: ransomware recovery, instant VM recovery, aggressive RTOs. For long-retention data that is rarely restored, dedupe disk or object storage can still deliver lower cost per terabyte at rest. Most enterprises should tier: flash for the recent restore window, cheaper media behind it.
Is QLC flash reliable enough for backup workloads?
Vendors aim capacity flash squarely at this profile: backup targets are mostly sequential writes with reads on demand. Everpure describes FlashArray//C’s QLC DirectFlash as “fast, efficient, and durable capacity,” and NetApp lists backup targets among AFF C-Series uses. Ask each vendor for endurance and warranty terms in writing, sized to your daily write volume.
What restore speed does ransomware recovery need?
Work backward from your tolerable outage: divide the terabytes in your critical estate by the hours in your recovery target. That sustained rate, measured on rehydrated restores of your own data, is the number to test candidate targets against. As estates grow and recovery targets shrink, the required rate climbs quickly into flash-target territory.
Does an all-flash backup target replace immutability?
No. Immutability comes from target capabilities and configuration (Veeam hardened repositories on block storage, WORM-capable NAS, NetApp SnapLock, Object Lock on S3-compatible targets), not from the media type. Flash changes how fast you recover; immutability determines whether you have anything clean to recover from. You need both, and they are separate line items in the design.
Enterprise Techie sends vendor-honest analysis like this once a week. Get the brief by email, free.