Single-node vs. multi-node backup storage is one of the first architecture choices in a repository project, and it is often made by default. A single server with internal disks is the familiar design, simple to buy and simple to explain. A multi-node system spreads the same data across several servers. The two differ in what they survive, how they are maintained and how they grow, and those differences matter more as the repository becomes the last line of defence against ransomware.
This post compares the two designs as a planning decision. For what happens after a single server actually fails, single-server immutability and server failure covers the recovery side.
A single-node repository is one server holding all the backup data. Protection against disk failure comes from RAID inside that server. A multi-node repository is a group of servers that together present one storage system. Data is distributed across them using replication or erasure coding, so that the loss of a disk, or of a whole server, leaves the data readable from the remaining nodes.
| Property | Single node | Multi-node |
|---|---|---|
| Survives a disk failure | Yes, through RAID | Yes, through distributed protection |
| Survives a server failure | No, repository is offline until repair | Yes, remaining nodes continue to serve |
| Maintenance | Reboots interrupt backups and restores | Nodes can be updated one at a time |
| Growth | Until the chassis is full, then a second repository | Add nodes to the same system |
| Throughput | Bounded by one server's disks and network ports | Scales with the number of nodes |
| Starting cost and footprint | Lowest | Higher: more servers, switch ports and rack space |
| Operational complexity | One machine to understand | A cluster, usually managed as one system |
The clearest difference is what happens when a server is unavailable, planned or not. With a single node, every firmware update, operating system patch and hardware repair takes the repository offline. Backups queue, restores wait, and the temptation is to postpone maintenance. With several nodes, one can be taken out of service while the others carry the load, so patching can follow a regular schedule without negotiating an outage each time. Patching a backup repository describes how to do that without weakening immutability.
Unplanned failures follow the same pattern. A failed motherboard or controller in a single node stops all backups until a replacement arrives. In a multi-node system it reduces redundancy and capacity for a while, and the repository keeps working.
RAID protects against a set number of disk failures within one group. As drives have grown, rebuild times have lengthened, and the repository runs with reduced protection for longer after each failure. Distributed protection across nodes spreads each piece of data over more devices and can rebuild in parallel from many of them. The outcome depends on the specific scheme, so the questions to ask a supplier are how many simultaneous disk and server failures the configuration tolerates and how long it takes to return to full protection after one.
A single server grows until its drive bays are full. Past that point the options are an expansion shelf, where supported, or a second server that becomes a second repository with its own capacity pool and its own management. Backup jobs then have to be split between them. A multi-node system grows by adding a node, and the new capacity joins the existing pool. For an estate that expects to double within a few years, that difference often decides the matter. What changes for backup storage between 50 and 150 TB describes the range where this usually comes up.
A single node remains a reasonable choice in several cases. A small estate that can tolerate a day without its repository does not need more. A second or third copy, where another repository holds the primary backups, can accept lower availability. So can a remote office with limited space. In each case it helps to be explicit that the design accepts downtime during server failure and to make sure another copy exists elsewhere.
It is also possible to start with one node and plan the move to several, provided the software supports expanding that way without a migration. That is worth confirming before purchase, not after.
Multi-node systems cost more at the smallest sizes, because several servers are needed before any data is stored and some capacity is spent on protection across nodes. The gap narrows as capacity rises. The comparison should include what downtime costs: backup jobs missed during a repair, restores delayed during an incident and staff time spent managing two separate single-node repositories once the first is full. Comparing usable capacity helps put quotes for the two designs on the same basis.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs or supplied as a pre-configured hardware appliance. It can span several servers, so one can fail or be taken out for maintenance without taking the repository offline, and capacity grows within the same deployment from roughly 50 TB to 8.5 PB.
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 is used as a target for Veeam and other backup software.
The decision comes down to three questions. How long can the organization go without its backup repository? How much will the data grow over the life of the hardware? And is there another copy to fall back on? If the honest answers are a day, not much and yes, a single node is defensible. Otherwise the extra servers are buying something the organization needs.