Skip to content

Products · Storage

Keeping it is easy. Getting it back is the requirement.

Primary storage, backup and archive, specified against how quickly data has to be available, how long it has to be kept, and what has to survive a failure that takes the primary copy with it.

This catalogue lists what Noble supplies and how it is specified. It carries no prices, no stock or availability position, no ratings or reviews, and no manufacturer specifications — everything technical is confirmed against the requirement at quotation, because a published figure nobody has verified is a figure somebody will procure against.

What this category is for

Capacity is the easy half of a storage requirement and the half most specifications lead with. The half that decides the design is performance profile and recovery: how fast the data has to be read, how much of it can be lost, and how long a restore is allowed to take.

Backup is where the difference between a supplier and an engineering organisation shows. A backup that has never been restored is a copy nobody has tested, and an isolated copy is the only one that survives an incident that reaches the primary estate.

What it covers

Product types rather than part numbers. The type is the decision; the model follows from the requirement and is confirmed at quotation.

01

Shared storage arrays

Block and file storage serving a virtualisation estate or an application tier, where several hosts need the same data and the array is a single point worth engineering around.

02

File and unstructured storage

Departmental shares, drawings, media and document repositories — where growth is steady, deletion never happens and the useful control is tiering rather than capacity.

03

Backup targets and appliances

The destination a backup actually lands on, sized against a recovery time rather than against how much data there is.

04

Archive and immutable copies

Long retention for records that must be kept and rarely read, including copies that cannot be altered or deleted within their retention period.

What decides the specification

The questions a quotation is built from. Answering these is usually faster than sending a part number, and it catches the requirement a part number would have got wrong.

  1. 01

    How long a restore may take

    The recovery time objective drives the design more than capacity does. Restoring a large estate over a slow path can take longer than the business believes, and that is discovered during an incident unless it is measured beforehand.

  2. 02

    How much may be lost

    The recovery point objective, per system rather than for the whole estate. Very few systems need the same answer, and pricing them all at the strictest one is the most common way storage budgets are wasted.

  3. 03

    How long it is kept

    Retention set by regulation, contract or policy, and whether any of it has to be immutable. That answer changes the platform, not just the capacity.

  4. 04

    What survives a bad day

    Whether a copy exists that an incident on the primary estate cannot reach — a different site, a different credential domain, or media that is offline.

Brand and model names are used descriptively where a requirement names one. All marks belong to their owners.

Send the requirement.

A quantity, an environment and what it has to connect to is enough to start. Noble quotes against the requirement rather than from a price list, and says where a specification will not do what it is being asked to do.