Capacity bought, recovery assumed
This is about the storage sitting underneath your backup application: how fast it gives data back, how much of your history it should hold, and how you prove any of it before the day it matters.
Aban Smart designs, supplies, integrates and supports the repository and archive tiers that sit behind backup platforms, using QStar, INCOM/StorEasy and DISC technology.
There is a purchase most organisations make once and then misremember for years. They buy a quantity of backup capacity, the jobs turn green every morning, and everyone begins to speak as though recovery has been procured. It has not. Backup is a write operation and recovery is a read operation, and the two are sized, tested and budgeted differently. A repository can absorb overnight ingest comfortably and still need well over a week to hand a large estate back. Nothing in a nightly report would tell you that.
Different data, different purpose, different lifecycle.
Backup software vendors specify what they need. The storage underneath is frequently whatever capacity was cheapest that quarter. Four properties decide whether it does the job.
Ingest throughput inside the window. The obvious one, and the only one usually tested. Streams, deduplication overhead and concurrent job count all shape it.
Restore throughput. The neglected one. Deduplicated data must be rehydrated, which is a random read pattern rather than the sequential write pattern the repository was sized for. Many repositories restore substantially slower than they ingest, and that ratio is worth measuring rather than assuming.
Retention depth. How much history the tier holds before something has to move or expire. Depth drives capacity far more than daily change rate does.
Resistance to attack on the catalogue. A backup platform is an inventory plus a data store. Destroy the inventory and the data store becomes hard to use even where it survives intact. The repository should not share a credential domain, an authentication path or a management plane with the platform it protects.
That last point is why an on-premises S3 endpoint has become a common repository shape. Backup products write to it as an object target with its own access control, while retention is enforced at the storage layer rather than inside the backup console. The enforcement options themselves are compared under immutable and WORM storage.
Replication is the control people most often over-trust. Synchronous replication does exactly what it promises: it makes the second copy match the first, promptly and reliably. That includes matching a deletion. It includes matching an encryption event. A ransomware operator who reaches the primary repository does not need to find the replica, because the replica will faithfully reproduce the damage within the replication interval.
This makes replication an availability control. It protects against the loss of a site, a rack, an array, a power event. It does not protect against a change you did not want, which is a different failure entirely. Three mechanisms are routinely conflated:
| Mechanism | What it protects against | What it does not stop | Recovery it enables |
|---|---|---|---|
| Replication | Loss of a site, array or facility | Deletion, corruption or encryption, all of which it copies | Continue from the surviving location |
| Versioning or snapshots | Overwrite and unwanted change, within the retained window | Deletion of the versions themselves by a privileged account | Roll back to a point before the change |
| Immutability | Early deletion or modification for the retention term | Damage written before the copy was taken | Recover a copy that could not be removed |
Read across the rows and the design follows. Replication gives you somewhere to run. Versioning gives you a point to go back to. Immutability gives you confidence that the point still exists. Asynchronous replication with a deliberate lag is a partial mitigation, because it buys detection time, but a lag long enough to be useful is usually longer than anyone will accept for a disaster copy.
Archive replication tooling is explicit about the availability role it plays. QStar Archive Replicator, for example, writes synchronously to as many as four destinations across mixed technologies and file systems, local or remote, which is presented as a route to a 3-2-1 pattern for archived data rather than as protection against unwanted change.
The trailing zero is the one most often skipped.
The extended rule reads: three copies, on two media types, one off-site, one offline or immutable, and zero errors on verification. The first four numbers get implemented. The zero gets skipped, and it is the only one that produces evidence.
An unverified copy is an assumption in a rack. Verification means three separate things, and doing one does not cover the others.
Automated boot verification, where recovered virtual machines are started in an isolated network and checked for service response, covers a useful part of the third level at low operational cost. It is not a substitute for a full rehearsal, but it converts a nightly assumption into a nightly observation.
A checkbox test restores a known file to a scratch location during business hours, with the administrator who built the system present, from the most recent copy on the fastest tier. It proves the software runs. It proves almost nothing about a bad day.
A test worth the time changes several of those variables at once:
Two habits make the results usable. Write down what failed rather than only what succeeded, because the failures are the improvement list. And treat measured RTO and RPO as facts that change with data volume, so re-measure after significant growth rather than carrying last year's figure forward.
Backup platforms are optimised for a rolling operational window: recent copies, fast restores, frequent access. Ask one to hold seven years of monthly fulls and the economics turn awkward. The catalogue grows, index operations slow, licensing is often capacity-based, and the tier holding it all is priced for restore performance that ancient copies will never need.
Long-retention data has different characteristics. It is read rarely, usually for audit, dispute or investigation. It is retrieved selectively rather than as a bulk restore. Its value lies in being findable and provably unaltered, not in coming back in twenty minutes.
| Backup copy | Archive copy | Immutable copy | |
|---|---|---|---|
| Purpose | Recover recent operational state | Retain a record for its required term | Preserve a copy that cannot be removed early |
| Typical retention | Days to months | Years | The full retention term, fixed at write |
| Access pattern | Whole systems, restored urgently | Individual records, retrieved on request | Rarely read; exists as the fallback |
| Recovery expectation | Measured RTO in hours | Retrieval in minutes to hours | Available when other copies are gone |
Moving long-retention copies out of the backup product to an archive tier is well-trodden ground. Cohesity's archival documentation lists QStar among the S3-compatible targets it has validated, and a 2019 joint Rubrik and QStar data sheet described archiving from Rubrik to QStar Archive Manager over SMB. Both are third-party and historical documents. We reference them as evidence that the integration pattern is established, not as current certifications or partner commitments, and any specific version pairing needs validating for your environment. The destination design is covered under long-term data archiving and archive storage systems.
Storage cannot fix a backup policy that never covered a workload. If a database is not in a job, no repository property will produce it later.
It does not detect intrusion. Immutability preserves whatever it was given, including files encrypted before the copy was taken, so retention depth and detection latency together decide whether a clean point still exists.
It does not remove the need for a documented recovery runbook, a call list and a decision authority. Those are the things people search for at 03:00, and no storage tier supplies them.
See solutions for the wider set. To have a repository measured for restore throughput and recovery evidence rather than capacity alone, request an assessment.
Manufacturer documentation relevant to this page. Availability, specifications, and configurations are subject to verification.
Replication of archived data between sites and media for disaster-recovery designs. Replication is not a substitute for immutability or isolation.
Long-term retention architecture for hybrid-cloud backup repositories. Useful for architecture context.
Provided as historical reference. Not current product documentation; confirm current availability and configuration.
Joint architecture document describing long-term retention of Rubrik data on QStar archive targets. A historical joint document, not a current certification or partner commitment.
It covers site loss, which is what disaster recovery traditionally meant. It does not cover deletion, corruption or encryption, because synchronous replication reproduces those changes accurately. A complete design pairs replication for availability with versioning or immutability for protection against unwanted change. Treating one copy as covering both roles is the most common gap we find.
Share the workload, capacity, retention, access, and resilience requirements. Aban Smart will identify the next discovery inputs and the appropriate engagement path.