What Are Backup Storage Tiers?

Backup storage tiers are storage classes used for different stages of backup retention and recovery. Organizations may keep recent backups on storage designed for fast restores, move older backups to lower-cost capacity storage, and retain long-term copies on archive storage or tape. The appropriate tier depends on recovery requirements, retention periods, retrieval costs and how often the backup is likely to be accessed.

How backup storage tiers work

Backup data does not have the same operational value throughout its retention period.

A backup created yesterday has a relatively high likelihood of being used for a restore. A copy retained for several years may exist primarily to meet regulatory, legal or historical retention requirements. Keeping both copies on storage with identical performance and cost characteristics may therefore be unnecessary.

Tiering allows backup teams to match storage characteristics to the expected use of the data.

A typical arrangement might include:

• Performance tier: Recent backups kept on storage capable of supporting frequent or large restores.
• Capacity tier: Older backups retained economically while remaining readily accessible.
• Archive tier: Long-term copies stored where access may take longer or involve additional retrieval processes.

These are functional descriptions rather than universal technical categories. Backup products and storage vendors use different terminology, and some platforms can serve more than one role.

How should you decide which backups belong on each tier?

The most important decision is often the boundary between tiers.

Moving a backup to less expensive storage saves money only if the resulting retrieval characteristics still meet the organization's recovery requirements.

Several factors help determine where that boundary should sit.

How far back do restores usually go?

Actual restore history is useful here.

If most recovery requests involve data from the previous 30 days, keeping only seven days on the fastest storage may create unnecessary delays. Conversely, retaining six months of backups on high-performance infrastructure may provide little operational benefit if older copies are rarely accessed.

Backup teams can use restore logs to determine how frequently recovery requests reach seven, 30, 60 or 90 days into the retention window.

That gives the tiering policy an operational basis rather than setting it solely from storage price.

How quickly must each copy be recoverable?

Recovery requirements should also influence placement.

Recent backups may need to support large parallel restores during a ransomware incident or infrastructure failure. Older copies used for occasional file recovery may tolerate additional retrieval time.

The relevant measure is therefore not simply how quickly storage responds to a request. Teams should consider how long it would take to retrieve the volume of data required for the expected recovery.

Retrieving a single 20 GB file and recovering 50 TB of virtual machines place very different demands on a storage tier.

What does retrieval actually cost?

Capacity price is only one component of backup-storage economics.

Depending on the storage service or medium, retrieving data may involve:

• data retrieval charges
• network or egress charges
• minimum storage durations
• early-deletion charges
• staging or rehydration delays
• operational work required to locate and retrieve offline media

These costs matter because backup economics reverse during a recovery event: the data that was inexpensive to retain can become expensive to retrieve at scale.

A useful comparison therefore looks at cost to retain plus cost to recover, not only cost per stored terabyte.

Example: choosing a tier boundary from restore history

Consider a media company that retains 90 days of backup data.

Its most recent 14 days remain on an on-premises object storage target. Backups from days 15 through 90 are moved to a lower-cost archive service.

The arrangement substantially reduces the amount of local storage required.

The company's restore records, however, show that accidental deletion is often discovered several weeks after it occurs. An editor eventually requests a 4 TB project folder from a 21-day-old recovery point.

That copy has already moved into the archive tier.

The recovery now depends on the archive service's retrieval process and any applicable data-transfer charges. What would have been a direct local restore becomes a slower and potentially more expensive operation.

The problem is not that archive storage was inappropriate. The 14-day transition point did not reflect the organization's actual restore pattern.

If restore history showed that most operational recoveries occur within 45 days, keeping 45 days locally and archiving days 46 through 90 would better align storage placement with recovery demand.

How tiering affects ransomware recovery

A tiering policy should also account for which copies remain usable after an attack.

Keeping multiple backup copies on different storage classes does not automatically make those copies independent. An attacker who compromises the backup application may still be able to reach several tiers if they share credentials, administrative controls or deletion permissions.

Retention controls therefore need to be evaluated on each tier.

For S3-compatible storage, S3 Object Lock can protect object versions against deletion or modification for a defined retention period. Properly configured immutable retention can remain in force even if an attacker obtains credentials capable of accessing the storage system.

Archive copies can provide another recovery option, but teams should verify their protection mechanisms separately rather than assuming that moving data to another tier makes it immutable or isolated.

Backup storage tiers and the 3-2-1 strategy

Storage tiering and the 3-2-1 backup strategy solve different problems.

Tiering determines where backup data should reside during different parts of its retention lifecycle based on performance, access frequency and cost.

The 3-2-1 approach focuses on maintaining multiple copies and reducing the chance that one failure or incident affects every recoverable copy.

One copy can therefore move through several storage tiers without increasing the number of independent backup copies.

For example, moving a backup from local object storage into a cloud archive class changes where that copy resides. Whether it also satisfies an additional-copy requirement depends on how the backup software performs the move and whether another independent copy remains available.

This distinction matters when tiering is part of a cyber-recovery design rather than only a capacity-management policy.

When should older backups move to a cheaper tier?

There is no universal number of days after which backup data should move.

A more useful policy considers:

• Restore frequency by backup age. How often does the organization restore data that is 7, 30, 60 or 90 days old?
• Recovery time objectives. How quickly would that data need to be available if a restore were required?
• Recovery size. Are older restores typically individual files or multi-terabyte systems?
• Retention requirements. Which copies exist primarily for operational recovery, and which are maintained for longer-term retention?
• Retrieval economics. What would recovering a realistic volume of data from the lower-cost tier actually cost?

This produces a tier boundary based on recovery behavior rather than an arbitrary retention milestone.

How ARTESCA fits into a tiered backup design

ARTESCA can be used as S3-compatible backup storage for recent and actively recoverable backup data. With Veeam Backup & Replication, ARTESCA is supported as both a Performance Tier and a Capacity Tier, depending on the backup architecture.

This is an important distinction because ARTESCA does not have to occupy a single fixed position in every tiering design. Its role depends on how the backup application and storage environment are configured.

For workloads where recovery speed is important, ARTESCA provides on-premises object storage that can be read without public-cloud data retrieval or egress charges. Scality's current Veeam documentation also publishes backup and restore performance that increases across tested one-, three- and six-node configurations, although actual performance depends on workload and deployment characteristics.

S3 Object Lock can be enabled for backup buckets to provide storage-level immutable retention. ARTESCA's security guidance recommends immutable buckets for targeted backup data, while the specific retention policy can be controlled by supported backup applications such as Veeam.

Veeam can then control how backup data is placed across repositories and tiers according to its own backup policies. ARTESCA's SOSAPI integration can also report storage information to Veeam for functions including capacity reporting and placement decisions within Scale-out Backup Repositories.

The appropriate size of the ARTESCA tier therefore depends on how much backup history the organization wants immediately accessible, the restore throughput required during a large recovery, and the point at which moving older copies elsewhere produces a worthwhile cost saving.

Related terms

• Backup target — the storage system that receives and retains data written by backup software.
• Restore throughput — how quickly protected data can be read back from a tier during a recovery.
• S3 Object Lock — storage-enforced retention that prevents a protected object version being overwritten or deleted.
• Retention policy design — setting how long each copy is kept, which drives where it should sit.
• 3-2-1-1-0 backup rule — maintaining multiple independent copies, a separate question from where each copy is stored.