Three names, not thirty
We build archives from three manufacturers, each of which owns a different layer.
QStar writes the archive software. INCOM builds the appliances and storage systems, some of them branded HIT. DISC makes the optical libraries and write-once media. Nobody else is in the stack.
Aban Smart designs, supplies, integrates and supports these technologies. The scope of any commercial relationship is confirmed with you per engagement.
Long vendor lists on an integrator's website usually mean shallow familiarity with all of them. Ours is short and we would rather explain why than pad it. An archive needs software that decides where data lives, hardware that holds it under enforceable rules, and media that physically cannot be rewritten. Three manufacturers cover those three layers between them, and they are the ones our engineers actually configure, migrate and troubleshoot.
Three manufacturers, three layers, one integrator.
Who does what in the stack
| Manufacturer | Layer | What they provide | Typical role in a design |
|---|---|---|---|
| QStar | Archive software and data management | Archive Manager and related products, HSM and tiering, S3 gateway and object storage, replication and migration tooling | The control layer. Presents the namespace, applies policy, decides which tier holds which copy, and keeps the archive readable as hardware underneath it changes |
| INCOM Storage (StorEasy, HIT) | Appliances and archive storage systems | StorEasy WORM appliances, archive storage systems, HIT-branded library and storage systems | The enforcement and capacity layer. Where retention rules are applied by the platform rather than by an administrator's discipline |
| DISC | Optical libraries and media | Robotic optical archive libraries and write-once media | The last-resort layer. Data on media that is physically write-once and can be removed from the network entirely |
Two clarifications, because both are commonly got wrong.
HIT is INCOM. HIT is a brand under which INCOM Storage sells archive storage and library systems, alongside StorEasy. It is not a fourth manufacturer, and an earlier version of this site implied otherwise. We have corrected that here.
The layers are not interchangeable. QStar software running onto plain disk gives you management without enforcement. A WORM appliance with no archive software above it gives you enforcement without lifecycle. Optical media with neither gives you durable data that nobody can find. The stack is useful because the layers are combined, not because any one of them is sufficient.
Why the roster stays short
Depth costs time. Knowing how a QStar migration behaves when the source catalogue is inconsistent, or how a DISC library reports a media fault before it becomes a read failure, comes from doing it repeatedly on the same products. That knowledge does not transfer across a catalogue of twenty vendors.
There are also fewer integration surprises. Three products from three manufacturers give three interfaces to validate. The combinations we propose are ones we have built before, so the commissioning phase is about your data and your applications rather than about discovering how two vendors interpret the same protocol differently.
The honest limit: this means we are not the right supplier for every requirement. If your requirement is a hyperscale primary storage platform, a backup software licence renewal, or a specific vendor your enterprise agreement already mandates, say so early. We will tell you plainly whether our stack fits before anyone spends time on a design.
What Aban Smart adds on top
Buying three products is not the same as owning an archive. The work between the purchase order and a system your auditors accept is where we sit.
- Architecture. Deciding which layer enforces retention, how many copies exist and where, what the recall path looks like, and what happens when a component fails. This is done before any part number is chosen.
- Sourcing and specification. Turning the architecture into a configuration that is actually orderable, with the correct drive counts, media types, licence tiers and support terms, and with GCC delivery and import realities accounted for.
- Integration. Connecting the archive to what already exists: the PACS, the video management system, the MAM, the backup application, the directory service. This is usually the part that consumes the schedule.
- Migration. Moving data off a platform that is ageing or off support without losing metadata or breaking the application's references to it. Covered in more detail under archive migration and modernization.
- Commissioning and handover. Proving the system does what the design said, including restore tests and retention behaviour, and leaving your team able to run it.
- Support across all three. One point of contact when a problem spans the software, the appliance and the library, which is where multi-vendor stacks usually strand a customer.
Regional context matters as much as product knowledge. Data residency expectations, sector regulators, procurement cycles and the logistics of getting removable media into and out of a site are all local questions. How we work sets out the delivery model, and about Aban Smart covers who we are.
Confirming scope before you commit
Aban Smart is an integrator. We design, supply, integrate and support the products described here. We do not describe ourselves as an authorised, official, certified or exclusive distributor for any manufacturer, and you should treat any supplier who claims such status as something to verify rather than assume.
Specific partnership scope, including how support is escalated to the manufacturer and what is covered under which agreement, is confirmed in writing per engagement. Ask for it during evaluation, not after.
To see what each layer does in practice, start with archive management software, WORM storage appliances and optical archive systems, or browse the full technologies overview. To discuss a requirement, contact us.
Frequently asked questions
No. QStar, INCOM (including StorEasy and HIT-branded systems) and DISC are the manufacturers whose products we design with and support. A previous version of our website listed more than that, which overstated the position. If a requirement needs something outside this stack, we will say so rather than resell something we do not know well.
Related pages
Turn your requirement into a defensible architecture
Share the workload, capacity, retention, access, and resilience requirements. Aban Smart will identify the next discovery inputs and the appropriate engagement path.