What Is Backup Storage?

Backup storage is the infrastructure used to protect and retain copies of data so organizations can recover quickly from system failures, corruption, ransomware attacks, and other disruptions. Effective backup storage does more than preserve data. It helps organizations meet recovery time objectives (RTOs), minimize downtime, and restore critical applications and services when they’re needed most.

Recovery performance is especially important during ransomware attacks. In Sophos’s “The State of Ransomware 2026,” based on a survey of 2,158 IT and cybersecurity leaders, organizations used backups to recover data in 66% of attacks where data was encrypted, up from 54% in the 2025 report. But having backups is only part of the equation. Organizations also need to ensure those copies are protected from compromise and can be restored fast enough to meet business requirements.

This article explores how backup storage supports recovery, the main types of backup storage, capacity and retention, ransomware protection, restore testing, and how to evaluate backup storage for database workloads, including where Everpure fits.

What backup storage covers

Backup storage is the storage infrastructure or repository used to retain backup copies for recovery. Backup software manages the creation, cataloging, retention, and restoration of those copies.

While backup processes determine how data is captured, backup storage plays a critical role in how quickly and reliably that data can be recovered. Backup and archive storage serve different purposes. Backup storage prioritizes recoverability and restore performance, while archive storage focuses on long-term retention and cost efficiency. Organizations must balance capacity, retention, security, and recovery speed based on the criticality of their workloads.

This makes recovery time objectives (RTOs) a critical consideration. An RTO defines the maximum acceptable time to restore a system or service after a disruption. Even when backup copies are intact, slow storage performance can extend recovery times beyond acceptable limits, increasing downtime and business impact.

Backup storage must support two distinct demands: efficiently writing and retaining backup data during normal operations, and rapidly restoring large volumes of data when systems go down. During a ransomware incident, multiple applications, databases, and services may need to be recovered simultaneously, placing significant demands on storage throughput and performance.

Snapshots on a primary array can accelerate recovery from certain failures, but they complement rather than replace independent backup copies. Ransomware, administrative errors, or infrastructure failures can compromise primary storage and its snapshots. Microsoft’s SQL Server guidance recommends keeping database backups in a separate physical location or on a separate device from database files. For more on how these approaches support different recovery requirements, see “Snapshots vs. Backups vs. Replication: What’s the Difference?”

Types of backup storage

Enterprise backup systems typically combine several types of backup storage rather than relying on one. Each type suits a different part of the recovery window.

Object storage stores data as self-contained objects addressed through an API, which suits large retention sets and object lock policies. Backup as a service (BaaS) moves the backup target, and much of its operation, to a provider.

A common pattern is to tier these. Recent restore points sit on the fastest storage, where most restores happen. Older copies age to object storage or tape, where they cost less to keep and are needed less often.

Managing backup capacity and retention

Capacity and retention are the two settings that decide what a backup environment costs and how far back it can recover.

Capacity planning

The amount of backup storage an environment needs comes from a handful of variables:

• Protected data size: The amount of database data included in each backup, which may differ from the database’s allocated size. For SQL Server, actual backup size depends on the data pages backed up, backup type, compression, and encryption settings. Use historical backup sizes to estimate storage requirements.
• Change rate: How much data changes between backups, which drives the size of incremental, differential, and log backups.
• Restore points: How many full and intermediate backups are kept at once.
• Retention length: How long each copy stays before it expires.
• Data reduction: How much deduplication and compression shrink the stored copies.

Data reduction depends heavily on the data itself. Conventional deduplication is typically less effective on data that is already compressed or encrypted, and encrypting database backups and compressing them where possible is recommended. Results also vary widely by platform, so reduction measured on an organization’s own backup sets is a more reliable planning input than a published average.

Backup retention policy

A backup retention policy defines how long copies are kept, how many versions exist, and where each copy lives. A common scheme is grandfather-father-son (GFS): daily backups kept for a short period, weekly backups kept longer, and monthly backups kept longest. Regulated records often carry their own minimum retention periods, which set a floor for the policy.

Retention also sets the rollback window. CISA recommends being able to roll back data at least seven days, and retention that is too short can leave no clean copy that predates an undetected problem.

Ongoing management

Backup storage needs the same monitoring as production storage, with a different set of signals:

• Job success: Failed or partial backup jobs, caught before the next restore depends on them
• Capacity headroom: Free space against the growth trend, so retention doesn’t have to be cut to make room
• Measured restore times: Actual restore durations from tests, compared against RTOs
• Tier movement: Copies aged between tiers on a schedule that matches the retention policy

Protecting backup storage from ransomware

Attackers also target backup storage directly. In a 2024 Sophos study of 2,974 IT and cybersecurity professionals whose organizations had been hit by ransomware, 94% said attackers tried to compromise their backups during the attack, and 57% of those attempts succeeded. Protection is part of managing backup storage rather than a separate project.

The 3-2-1-1-0 rule

CISA describes the 3-2-1 rule as three copies of important files, on two different types of storage media, with one copy stored offsite. A widely used extension, 3-2-1-1-0, adds an immutable or air-gapped copy and zero errors on verified restores:

• 3 copies of data
• 2 different storage media
• 1 copy offsite
• 1 copy immutable or air-gapped
• 0 errors on verified restores

Immutable and indelible copies

An immutable backup can’t be changed during its retention period. Whether it can be deleted depends on the implementation. AWS documents two S3 Object Lock modes: in governance mode, users with special permissions can alter lock settings or delete objects, while in compliance mode a protected object version can’t be overwritten or deleted by any user, including the account root user, before retention ends.

That difference is the difference between immutable and indelible. An indelible copy can’t be deleted by an administrator before its retention period expires. The distinction matters most when administrator credentials are compromised.

Air gaps are a separate control. In backup environments, air-gapping typically refers to isolating the backup media or backup network from production systems. Isolation limits who can reach a copy, and immutability limits what can be done to it, so the two are typically used together.

Access controls on the backup system

Protection also covers the backup system itself:

• Separate credentials: Keep backup administration accounts apart from production credentials and require multifactor authentication.
• Least privilege: Avoid granting backup or restore accounts more privileges than necessary.
• Approval gates: Use multi-party approval for destructive operations such as shortening retention or deleting copies.

For storage-specific security controls, NIST SP 800-209, Security Guidelines for Storage Infrastructure, was published in 2020. A Rev. 1 draft released on July 22, 2026 adds a focus area on threats to backups and the process that creates them. The same practices apply whether backup storage runs on premises or in the cloud.

Testing restores, not just backups

The “0” in 3-2-1-1-0 exists because a successful backup job doesn’t prove that a restore will work. The NIST Cybersecurity Framework (CSF) 2.0, published in February 2024, lists as outcome PR.DS-11 that backups are created, protected, maintained, and tested, and as RC.RP-03 that backup integrity is verified before restoration.

Microsoft’s SQL Server guidance puts it directly: There is no restore strategy until backups are tested. It calls for test-restoring every type of backup in use, running DBCC CHECKDB against the restored database, and recording the time each test restore takes.

A restore test program for databases typically covers:

• Full restores: A complete database restored to a test system and checked for consistency
• Point-in-time recovery: A restore to a specific moment using full, differential, and log backups together
• Restore time against RTO: The measured duration from the start of the restore to a usable database
• Concurrent restores: Several systems restored at once, as a broad incident would require

CISA recommends scheduled recovery tests. The schedule itself belongs in policy, set by how critical each system is. Recording each test’s date, backup set, duration, and result gives auditors evidence and shows whether restore times are drifting as data grows.

How to evaluate backup storage for database workloads

There is no single best storage for backup. The right choice depends on the RTO for each system, the retention the business requires, and the threats the backup copy has to survive. The following questions separate options in practice:

• Restore throughput under load: How long does a full restore of a representative database take, measured rather than quoted, while other work is running?
• Deletion protection: Can an administrator with full credentials delete copies or shorten retention, and what approval does that require?
• Actual data reduction: What reduction does the target achieve on real, compressed, and encrypted database backups?
• Integration: Does it work with the backup software in use and with native tools such as Oracle Recovery Manager (RMAN) and SQL Server’s BACKUP command?
• Cost as data grows: How do capacity, retention, and any egress charges scale over the planning horizon?
• Recovery location: Where do restores land if production storage is unavailable or held for forensic investigation?

How Everpure helps with storage management backup

Everpure™ FlashBlade serves as a backup target for native database tools without proprietary agents: Oracle RMAN writes over Direct NFS (dNFS), and SQL Server’s T-SQL backups write to SMB or S3. In Everpure validation published in February 2026, Oracle RMAN restores to FlashBlade exceeded 60TB/hour, and SQL Server restores across eight concurrent instances exceeded 113TB/hour. FlashBlade Rapid Restore increases the speed of data restoration without changing backup software and integrates with a range of backup software partners.

For backup capacity, Purity DeepReduce™ applies similarity-based data reduction on FlashBlade//E™ and FlashBlade//S200 R2 arrays. In Everpure lab testing published in June 2026, Purity DeepReduce reduced uncompressed SQL Server backup sets by almost 55%. For backups already compressed by SQL Server, it provided an additional reduction of approximately 37%, for a total effective reduction of approximately 68%.

SafeMode™ Snapshots are immutable and indelible. Manual eradication is blocked for the configured eradication delay, and changes to snapshot protection policies require multi-party authorization with Everpure Support, so a compromised administrator account can’t remove recovery copies on its own. SafeMode is built into FlashBlade and FlashArray™ systems without an additional license, and Everpure publishes guidance on Oracle RMAN backup and recovery with FlashArray.

When production arrays are unavailable after an attack or disaster, the optional Evergreen//One™ Cyber Recovery and Resilience SLA guarantees next business day shipping of clean recovery arrays in North America and EMEA, 48 hours to finalize a recovery plan, and an 8TiB/hour data transfer rate.

Explore Everpure data backup solutions to see how these fit a backup architecture built around restore time.

Conclusion

Storage management backup is judged at restore time. Capacity, retention, tiering, and security all matter, but each one ultimately serves a single outcome: returning clean data within the recovery time the business has agreed to.

When restore throughput isn’t measured, the actual restore time is first observed during an incident. Measured restore throughput, deletion-protected copies, and scheduled restore tests establish that number in advance. That makes the storage underneath the backup copies as much a design decision as the backup software on top of them.

Backup storage FAQs

What is the optimal backup storage strategy?

Most enterprise strategies combine tiers. Recent restore points sit on fast storage for routine and large-scale restores, while older copies move to object storage or tape for low-cost retention. The 3-2-1-1-0 rule adds an offsite copy, an immutable or air-gapped copy, and verified restores. The strategy is complete only when measured restore times meet each system’s recovery time objective.

What is a scale-out backup storage solution?

A scale-out backup storage solution grows capacity and performance by adding nodes or blades to a single system, rather than replacing a controller or adding separate silos. Backup software sees one target as it expands. This design suits environments where protected data grows steadily because restore throughput can increase along with capacity instead of staying fixed while more data accumulates.

How can backup scale as enterprise data grows?

Scaling backup starts with the capacity variables: protected data, change rate, restore points, retention, and real data reduction. Tracking these over time shows when headroom will run out. Tiering keeps recent copies on fast storage and ages older copies to lower-cost tiers. Restore testing should scale too since restore times grow with data even when backup jobs still finish inside their windows.

What is enterprise backup?

Enterprise backup is the set of software, storage, and policies an organization uses to copy and restore data across its servers, databases, virtual machines, and cloud workloads. It’s typically centrally managed, policy-driven, and designed around recovery objectives for each system. It includes retention rules, security controls on the backup environment, and regular restore testing, not only the scheduled jobs that create copies.