Backup storage server specs are often chosen by capacity alone: enough drive bays for the terabytes required, and whatever processor and network card come with the chassis. Capacity determines how much the repository holds. Throughput, meaning how fast backups land and how fast restores come back, depends on a different set of components. A server with ample space and the wrong balance elsewhere will hold every restore point and return them too slowly.
This post goes through the hardware specifications that affect backup and restore throughput, for teams buying new servers or assessing ones they already own.
Data moving into a repository passes through the network interface, is processed by the storage software, and is written to disks through a controller. A restore reverses the path. The slowest of those stages sets the rate for the whole operation. Raising the specification of any other stage changes nothing until the limiting one is addressed. Finding the slowest step in a restore describes how to locate it on a running system.
| Component | What it affects | What to look for |
|---|---|---|
| Network interfaces | Upper limit on data in and out | 10 GbE as a minimum, 25 GbE where restores must be fast |
| Number and type of data drives | Sequential throughput and parallel streams | More spindles for more streams, flash for random reads |
| Metadata storage | Listing, small-object operations, restore start-up | SSD or NVMe for metadata, separate from capacity drives |
| Drive controller | How fast disks can be addressed | Enough ports and lanes for every bay at full speed |
| Processor | Checksums, encryption, erasure coding, compression | Enough cores for the planned number of concurrent streams |
| Memory | Caching and metadata handling | Sized to the software vendor's guidance for the capacity |
The network interface is the simplest limit to calculate. A 10 GbE link carries a little over 1 GB per second at best, roughly 4 TB per hour. A 1 GbE link carries a tenth of that, which makes it unsuitable for any repository beyond a few terabytes. Two points are easy to miss. The limit applies end to end, so the backup proxies, the hypervisor hosts and the switches between them must match. And a restore that feeds many hosts at once benefits from more than one interface on the repository, with traffic spread across them.
Large-capacity hard drives deliver good sequential throughput individually, and a repository stripes data across many of them. Throughput therefore rises with the number of drives working in parallel. A server with twelve large drives and one with twenty-four smaller ones may hold the same capacity, and the second will generally sustain more concurrent streams.
Flash changes the picture for random reads. Instant recovery, where virtual machines run directly from the repository, and file-level restores, which read scattered blocks, are much faster from SSD. All-flash repositories cost more per terabyte. Hybrid designs keep bulk data on hard drives and use flash where it has the most effect.
Object storage keeps an index of every object it holds. Backup software writes millions of objects and regularly lists, checks and deletes them. If the index sits on the same hard drives as the data, each of those operations competes with data transfers for disk seeks. Placing metadata on SSD or NVMe is the single change that most improves responsiveness on a hard-drive repository, and most object storage software expects it.
Storage software computes checksums on everything it reads and writes, and may also encrypt data and calculate erasure-coded fragments. These tasks scale across cores. A repository handling many concurrent backup streams needs enough cores to keep up, though backup storage rarely calls for the highest clock speeds. Memory supports caching and metadata handling. The software vendor's sizing guide is the right reference for both, since requirements vary widely between products.
With hardware prices and delivery times as they are, reusing existing servers is an appealing option. A server retired from virtualization duty often has plenty of processor and memory, adequate networking and too few drive bays. A former file server may have the bays and an older, slower controller. The checks are the same as for new hardware: network speed, number of bays, controller generation, whether there is room for metadata flash and whether the model appears on the storage software's compatibility list. Comparing backup storage procurement options sets reuse alongside new purchase.
Age matters as well. Drives and power supplies near the end of their service life raise the failure rate of the repository, and support contracts for older models may have lapsed.
Specifications give an upper bound. The figure that counts is measured on the assembled system with the backup software that will use it: a full backup of a representative set of machines and a restore of the same set, with throughput recorded for both. Running a proof of concept describes how to structure that test so the results can be compared across options.
ARTESCA is object storage software used as a backup target. As a software appliance it runs on industry-standard x86 servers the customer chooses, and it is also supplied as a pre-configured hardware appliance in all-flash or hybrid configurations. Immutability is provided by S3 Object Lock on each object, and in compliance mode no account, including ARTESCA administrators, can remove a lock before it expires.
ARTESCA can span several servers, so throughput and capacity grow together as servers are added, up to 8.5 PB in the same deployment. It is used as a target for Veeam and other backup software.
A well-specified backup storage server is balanced more than it is powerful. The network can carry what the disks can deliver, the processor can keep up with both, and metadata has fast storage of its own. Checking each stage against the restore time the organization actually needs is the surest way to avoid paying for capacity that cannot be read back quickly enough.