Backup Storage Architecture: Why the Target Matters When Recovery Is Urgent
- Daniel Smith
- 2 days ago
- 10 min read
Backup storage is often bought on capacity, retention, deduplication and cost. But when recovery is urgent, the real question is whether the backup target can help the business come back quickly, safely and predictably.
Backup storage is judged when recovery is urgent
Backup storage architecture is usually bought on a calm day.
It is judged on the worst one.
Capacity. Retention. Deduplication. Backup windows. Cost per terabyte.
All important.
But none of them prove the one thing the business actually needs when systems are down: recovery.
A backup target can be excellent at storing backup data and still be poor at helping the business recover. That is the gap most storage refresh conversations miss.
When recovery is urgent, the backup target stops being a quiet storage destination and becomes part of the recovery path.
If it is slow, recovery is slow.
If it is exposed, recovery is exposed.
If it cannot scale cleanly, recovery becomes constrained.
If it was designed mainly around inline deduplication, capacity efficiency and steady-state backup ingestion, it may look acceptable on a normal day but struggle when recovery becomes the primary workload.
Backup storage should not only be evaluated by how well it stores backup data. It should be evaluated by how well it supports recovery.
A green backup report is not recovery confidence
Most backup environments look healthy on a normal day.
Jobs complete. Reports are green. Retention policies are met. Capacity is monitored. Data is being protected.
That matters. But a successful backup job is not the finish line. It is only evidence that a copy was created.
Recovery confidence is different.
It means knowing what happens when the environment is under pressure: an urgent restore, a ransomware event, a failed system, a corrupted workload, a bad change, a security investigation, a business unit waiting, and executives asking how long it will take.
Backup jobs may still be running. Copy jobs may be competing for resources. Teams may be trying to recover recent data quickly while older retained data still needs to remain protected.
That is when the backup target gets tested. And that is when architecture matters.
Recovery exposes what sits underneath the backup platform
Most organisations have invested heavily in backup software. That investment matters.
Backup software controls policies, jobs, schedules, retention logic and restore workflows. But recovery does not depend on the backup application alone.
When recovery is urgent, the storage underneath the backup platform starts to matter just as much.
A backup target built mainly around capacity and storage efficiency can look perfectly acceptable during steady-state operations. Backup jobs complete. Retention is met. Capacity is managed. The environment appears under control.
Recovery changes the test.
Can recent backup data be restored quickly?
Can retained backup data survive deletion pressure?
Can restore jobs run while backup jobs and copy jobs are still active?
Can the platform scale without a forklift refresh?
Can the architecture support the business under pressure, or does it become another constraint?
The old question was: how much backup storage do we need?
The better question is: what happens when we need to recover?
Capacity growth is not recovery architecture
This is where many backup storage refresh conversations go wrong.
Not every backup target fails suddenly. Some simply slow down over time.
Data grows. Retention grows. Backup jobs increase. Copy jobs expand. More workloads are added. More disk is added to keep up with capacity.
On paper, the environment has grown. In practice, it may not have scaled.
A backup target designed mainly around inline deduplication and capacity efficiency can be good at reducing stored data footprint. But adding more disk does not automatically add the processing power, memory, I/O, concurrency and recovery headroom needed to keep up.
That is when the creep starts.
Backup windows stretch.
Copy jobs compete harder.
Restore performance becomes less predictable.
Operational headroom disappears.
The platform gets larger, but not necessarily stronger.
This is also where rehydration belongs in the recovery conversation.
If backup data has to be rehydrated before it can be restored at speed, the target is not just storing backup data. It is influencing the recovery timeline.
Capacity scaling is not the same as recovery scaling.
HDD vs flash does not solve the architecture problem by itself
Media performance matters. HDD matters. Flash matters. There are good reasons to care about both.
But faster media does not automatically fix an architecture where dedupe processing, rehydration, concurrency limits or scale constraints sit in the recovery path.
A flash-based target can still be constrained if the surrounding architecture cannot scale processing, memory, I/O and concurrency with the data. An HDD-based target can still be effective if the architecture is designed around the right recovery path, workload separation and scale-out model.
The real question is not simply: is the target fast?
The better question is: does the architecture scale performance, capacity and recoverability together?
Inline deduplication and rehydration can become recovery bottlenecks
Inline deduplication can be valuable. The issue is not deduplication itself. The issue is what happens when the architecture is built mainly around ingest efficiency and stored-capacity reduction, then has to support urgent recovery under load.
In some environments, growth is handled by adding more disk. That may increase capacity, but it does not always add the compute, memory, I/O and concurrency needed to keep backup and recovery performance moving.
If restore data must also be rehydrated before it can be recovered at speed, the target can become part of the recovery delay.
That matters because recovery is rarely a single clean restore job. It often happens while backup jobs, copy jobs, security investigation and business pressure are all active at the same time.
Snapshots are useful, but they are not the whole recovery strategy
Snapshots can be extremely useful. In the right scenario, they provide fast rollback, short-term recovery points and operational convenience close to the production environment.
But snapshots are not the same thing as independent backup and recovery architecture.
They are often close to the source platform or primary storage environment. That closeness can be useful for speed, but it can create risk if the source platform, storage layer, administrative boundary, credentials, replication chain or snapshot management plane is compromised.
Snapshots can help with some recovery scenarios. They should not be mistaken for the whole recovery strategy.
The better question is not “do we have snapshots?” It is “do we have a recovery architecture that remains usable when the production environment is under pressure?”
When ransomware reaches the recovery path
This is not theoretical.
KNP Logistics, the UK transport group behind the Knights of Old brand, became one of the clearest public examples of what can happen when ransomware affects the recovery path itself.
Public reporting linked the incident to the Akira ransomware group and weak password access. Reporting also described severe operational disruption, a reported multimillion-pound ransom demand, around 700 job losses and the collapse of a 158-year-old business. Some reporting stated that backups and disaster recovery systems were compromised, leaving the company without a clean path back.
The lesson is not only that passwords matter. They do.
The bigger lesson is that recovery architecture has to assume a bad day: compromised access, encrypted systems, deleted or inaccessible backups, security teams under pressure, executives demanding timelines, and recovery teams trying to restore while the business is already down.
That is the moment when backup strategy becomes real. Not when the report is green. Not when the backup window closes. When systems are down and the business needs to come back, the recovery path either works or it does not.
What actually fails during recovery
In a real recovery event, the problem is rarely one failed system. It is pressure stacking on pressure.
Restore jobs need to run while backup jobs continue.
Copy jobs may still be moving data.
Recent backup data needs to be recovered quickly.
Older retained data still needs to be protected.
Security teams may be investigating the same environment recovery teams are trying to restore.
Executives may be asking for recovery timelines before the technical team has confirmed which recovery points are usable.
If ransomware is involved, deletion pressure, compromised credentials and encrypted systems may all be part of the same operational window.
A target designed mainly around inline deduplication may look efficient while backup jobs are running, but recovery is a different workload. If data growth has been handled mostly by adding capacity, not scaling the full performance architecture, the target can become constrained when backup jobs, copy jobs and restore jobs collide.
Add rehydration into the recovery path, and the backup target can become part of the delay.
The business does not care that the target was efficient yesterday. It cares whether it can recover today.
Backup efficiency is not the same as recovery usability
This is the distinction many storage refresh conversations miss.
Backup efficiency matters. Deduplication matters. Capacity reduction matters. Retention cost matters.
But recovery is not just a storage efficiency problem. Recovery is an operational outcome.
The business does not ask how efficient the backup target was when systems are offline. It asks whether the organisation can recover fast enough, safely enough and predictably enough.
Which recovery points are still usable?
Can we restore without waiting on rehydration, retrieval, copy-back or overloaded infrastructure?
Can retained data survive attack pressure?
Can the platform handle recovery while backup and copy jobs still run?
Can performance scale as data grows?
Can the architecture hold up when backup, copy and restore activity collide?
A backup target should not only store backup data. It should help make recovery usable.
How ExaGrid changes the backup storage architecture conversation
ExaGrid is not generic storage sitting underneath a backup application. It is purpose-built Tiered Backup Storage designed around the difference between backup efficiency and recovery usability.
That distinction matters because recovery is not only about keeping backup data. It is about how quickly, safely and predictably that data can be used when the business needs it back.
ExaGrid separates the parts of the architecture that often get blended together: fast recovery, efficient retention, scale-out growth and ransomware resilience.
Landing Zone: fast access to recent backup data
The Landing Zone is designed for recent backup data. That matters because recent data is often the first place teams go during an urgent restore. When a VM, file server, database or application needs to come back quickly, restore performance is not a technical footnote. It is the point.
Repository Tier: efficient long-term retention
The Repository Tier is designed for deduplicated long-term retention. Organisations still need efficient retention for operational, regulatory and business reasons. But retention efficiency should not create recovery uncertainty. Keeping backup data is only useful if the organisation can recover from it when it matters.
Scale-out growth: capacity and performance together
In many backup storage environments, growth means adding capacity first and hoping performance keeps up. That can work for a while, but data growth eventually becomes a performance, concurrency and recovery-headroom problem.
ExaGrid’s scale-out model adds appliances into a single system, with compute and capacity growing together. That matters because recovery pressure is not only a capacity problem. It is an architecture problem.
Retention Time-Lock: resilience when deletion pressure is part of the event
In a ransomware scenario, the question is not simply: do we have backups?
The harder question is: can usable backup data survive the attack path?
Retention Time-Lock is designed to help protect retained backup data using delayed deletes, immutable data objects and a non-network-facing Repository Tier.
These are not cosmetic features. They are architectural controls for the moment when deletion pressure, ransomware activity or compromised access may be part of the recovery scenario.
That is why architecture matters. Not just capacity. Not just deduplication. Not just media type. Not just a feature checkbox. Architecture.
The backup application still matters
This is not an argument that backup software does not matter. It absolutely does.
Veeam matters. Commvault matters. NetBackup matters. Rubrik matters. The operational processes around those platforms matter. The people who run them matter.
Most organisations are not looking to rip and replace their entire backup environment. They already have policies, jobs, retention schedules, operational processes and internal skills built around the platforms they run today.
The point is simpler: recovery does not depend on the backup application alone. It also depends on the architecture underneath it.
The value is not that organisations need to abandon the platforms they already run. The value is that they can strengthen the recovery architecture supporting them.
Backup storage is now part of cyber resilience
Backup storage used to sit quietly in the background. That is no longer good enough.
During a serious incident, the business does not care that yesterday’s backup job completed. It cares whether systems can come back fast enough, cleanly enough and safely enough.
The board may never ask about dedupe ratios, backup targets or rehydration paths. But they do ask about ransomware, downtime, operational continuity, risk and recovery timelines.
Backup storage sits underneath all of that.
· If the backup target slows recovery down, resilience suffers.
· If retained backup data is exposed to deletion, resilience suffers.
· If the platform grows in capacity but not in recovery performance, resilience suffers.
· If snapshot access depends too heavily on the same compromised environment, resilience suffers.
That is why backup storage is no longer just infrastructure. It is part of cyber resilience.
Questions to ask before your next backup storage refresh
Before the next backup storage refresh, organisations should ask more than capacity, deduplication and price questions.
Those questions still matter. But they are not enough.
Is the platform designed for recovery under pressure, or mainly for backup ingestion?
Does performance scale with capacity?
Does adding disk also add the compute, memory and I/O needed to keep up?
How much rehydration sits in the recovery path?
Can recent backup data be recovered quickly when the business is waiting?
How is retained backup data protected from deletion or ransomware pressure?
Can the platform scale without forklift upgrades?
Will recovery performance hold up when backup jobs, copy jobs and restore jobs compete for resources?
Are snapshots being treated as one recovery tool, or as the whole recovery strategy?
Does the architecture support the recovery outcomes the business actually expects?
These are not theoretical questions. They are the questions that matter when recovery is urgent.
Do not let backup storage become the recovery bottleneck
Backup storage used to be judged mainly by how well it handled backup jobs. Today, it needs to be judged by how well it supports recovery.
Capacity still matters. Retention still matters. Deduplication still matters. Cost still matters. Media type still matters. Snapshots still matter.
But recovery architecture matters more.
When recovery is on the line, the backup target is not background infrastructure. It is part of the recovery path.
That is why FullBackup works with Australian organisations reviewing ExaGrid as part of their backup and recovery architecture, especially where recovery speed, ransomware resilience, long-term retention, scale-out growth and predictable recovery under pressure all matter.