Tiered recovery is the practice of giving different workloads different recovery targets and funding each tier accordingly. The alternative, one target for everything, fails in one of two ways. Either every system is promised the fast recovery that only a few need, which is unaffordable, or every system gets the slow recovery that the budget allows, which leaves critical services down for days. After a large incident, the order in which systems return is decided one way or another. Tiered recovery decides it in advance.
This post explains how recovery tiers are defined, what each tier asks of backup storage and how to keep the tiers honest.
Why one recovery target does not work
Recovery speed costs money in specific places: faster storage for the backup copies, more network between that storage and production, standby compute and more frequent backups. Applying the top specification to an entire estate of thousands of workloads multiplies that cost by a factor nobody will approve. Yet a small subset of systems, such as identity, core databases and the applications that take orders or treat patients, cannot wait in a queue behind file archives and test environments. The economic answer is to spend on speed where downtime is expensive and accept slower recovery where it is cheap.
Defining the tiers
Tiers are usually derived from a business impact analysis, which estimates the cost of each service being unavailable over time. Three or four tiers are enough for most organizations.
| Tier | Typical workloads | Recovery time target | Recovery point target | Typical method |
|---|---|---|---|---|
| 0: Foundation | Identity, DNS, backup infrastructure, key management | Hours, before anything else | Hours | Rebuilt from known-good images, or restored first |
| 1: Critical | Revenue and safety systems, core databases | Hours | Minutes to an hour | Replication or instant recovery from fast backup storage |
| 2: Important | Line-of-business applications, collaboration | One to two days | Up to a day | Restore from backup, parallel streams |
| 3: Deferred | Archives, test and development, reporting copies | A week or more | A day or more | Restore from backup when capacity is free |
Tier 0 is often forgotten. Nothing in the other tiers can be restored without the systems that authenticate administrators and locate backups, so they come first regardless of how visible they are to the business. The post on backup recovery dependencies describes how to map them.
Dependencies override classification
A workload inherits the tier of whatever depends on it. A tier 1 application that calls a tier 3 reporting database is a tier 1 application that will not start. Classification exercises that rank applications in isolation produce tiers that look tidy and fail in practice. The check is to trace each tier 1 service through everything it needs, including shared file systems, license servers, message queues and integration middleware, and to raise those components to match.
The result usually enlarges the upper tiers. That is useful information, since it shows the real size of what must come back quickly.
What each tier asks of backup storage
The tiers place different loads on the storage that holds backups. Tier 1 recovery, where systems are started directly from backup or restored at high speed, needs strong random read performance and enough throughput to restore several large systems at once. Tier 2 needs sustained sequential read throughput across many parallel streams. Tier 3 mainly needs capacity at low cost.
That does not have to mean three separate storage systems. It can mean one platform with different protection policies and media for different buckets, or recent restore points on faster media and older ones on denser media. What matters is that the tier 1 data set has been sized for restore, not only for backup. The post on restore speed as the real recovery time explains why read throughput is the figure to design for.
The queue during a real incident
In a mass recovery, every tier competes for the same resources: backup storage read throughput, network, target compute and, above all, people. Tiering is what turns that contention into a sequence. Tier 0 is restored, then tier 1 with the full capacity of the storage and the team, then tier 2 in waves, with tier 3 left until the pressure is off.
The sequence only holds if it is written down and the tooling follows it. Restore jobs grouped by tier, with tier 1 jobs prepared in advance, save hours of decision-making. The post on mass restore planning covers how to build and order those waves, and ransomware recovery exercises covers rehearsing them.
Keeping the tiers honest
Tier assignments decay. New applications are deployed without a tier and default to whatever the backup policy template says. Owners argue their system into tier 1 because it sounds important. Applications grow until their restore no longer fits the target. Three practices counter this. Every tier has a measured restore time for a representative system, updated at least annually. The total size of tier 1 is tracked, because it determines whether the tier 1 target is achievable at all. And tier membership is reviewed with business owners, who see the cost attached to each tier when they choose.
A tier whose target has never been met in a test is an aspiration. Publishing measured recovery times next to the targets, as discussed in storage service levels, keeps the conversation grounded.
Where Scality RING fits
Scality RING exposes an S3 interface used by backup applications as a target, and it distributes data across the nodes in the system, so reads during a restore draw on many devices in parallel instead of concentrating on a few. That is the property that tier 1 and tier 2 recovery depend on when many systems are restored at once.
Erasure coding and replication are selectable per policy, and RING runs on standard x86 servers chosen by the customer, so data sets for different tiers can be given different protection and hardware within one platform. RING supports versioning and S3 Object Lock, and nodes can be added to a live system as the upper tiers grow.
A tiering review in five questions
- Is there a tier 0, and does it include everything needed to reach the backups?
- Has each tier 1 service been traced through its dependencies?
- What is the total size of tier 1, and can it be restored within its target at measured speed?
- Are restore jobs grouped and ordered by tier before an incident?
- When was each tier's recovery time last measured?
Tiered recovery is a way of spending a limited recovery budget where it prevents the most damage. It works when the tiers reflect real dependencies and the targets are numbers that have been achieved in a test.