Backup storage at 50 to 150 TB sits in an awkward middle. Below that range, a single server or a NAS with a few disks does the job, and its limits are tolerable. Above it, organizations have storage teams and budgets to match. In between, the data is large enough that failures, rebuild times and backup windows start to matter, while the team running it is still two or three generalists. Designs that worked at 20 TB begin to strain, usually without a clear moment when they stop working.
This post describes what changes in that range and which assumptions are worth revisiting before the next purchase.
Why this range is a turning point
Several limits arrive together. Disk rebuilds stretch from hours to days. A full restore no longer finishes overnight. Retention and immutability multiply stored data faster than production grows. And the cost of the repository becomes visible enough that finance asks about it. Each of these is manageable, but they call for a different kind of system than the one a smaller estate could get by with.
What changes between small and mid-sized repositories
| Area | Below about 50 TB | From 50 to 150 TB |
|---|---|---|
| Hardware | One server or NAS, a single RAID group | Several RAID groups or several nodes |
| Drive failure | Rebuild in hours | Rebuild in a day or more on large drives |
| Hardware failure | Repository offline, tolerable briefly | Outage blocks backups for the whole estate |
| Full restore | Hours | Days, limited by throughput |
| Expansion | Replace with a bigger unit | Needs to grow in place |
| Immutability | Often added as a feature | Has to be designed into capacity and retention |
Failure tolerance
At 20 TB, losing the repository for a day while a part is replaced is an inconvenience. At 100 TB, the repository protects several hundred virtual machines, and a day without it means a day without new restore points for all of them. Rebuild times make this worse. A RAID group of large-capacity drives can take more than a day to rebuild after a single failure, during which a second failure may lose the group. The question shifts from whether the repository has redundancy to how long it runs exposed after a failure and what happens if a whole server is lost. What happens when a single immutable server fails follows that scenario through.
Restore throughput
Backup speed gets most of the attention during sizing, because the backup window is felt every night. Restore speed matters more in this range, because a large restore is now a multi-day event. Restoring 80 TB at a sustained 500 MB per second takes about two days. At 150 MB per second it takes about six. The repository's read throughput under parallel load, and the network between it and the hosts, decide which of those the organization gets. Mass VM recovery planning covers how to order a large restore so that the most important systems return first.
Growth without replacement
A repository in this range will not stay in it. With typical data growth and a retention extension or two, 80 TB becomes 150 TB within a few years. A system that can only grow by being replaced forces a migration each time, with its overlap period, double capacity and risk to older restore points. A system that grows by adding disks or nodes to the same deployment avoids that. Expand or replace works through the decision when a refresh is due.
Immutability and capacity
Immutability is now a standard requirement, and it changes the capacity calculation. Locked data cannot be removed early, so the repository must hold every restore point for its full lock period, plus the extra that results from how backup software extends locks. A repository sized for logical retention alone runs out of space sooner than expected. In this range the difference can be tens of terabytes, enough to justify calculating it properly before the purchase.
Operations for a small team
The team has not grown with the data. Whatever is chosen has to be run by people who also manage virtualization, networking and user support. That favours a repository with few moving parts to administer, health reporting that can be forwarded to existing monitoring, updates that do not need an outage and a clear procedure for replacing a failed drive or server. The cost of backup administration for small teams shows how to count that time when comparing options.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs or supplied as a pre-configured hardware appliance. This capacity range is where it typically starts. 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 the repository does not depend on one machine, and it grows within the same deployment up to 8.5 PB. It is used as a target for Veeam and other backup software.
Questions to settle before buying
Five questions sharpen a purchase in this range. How long would the repository run exposed after a drive failure, and after a server failure? How long would a full restore take at measured read speed? How does the system grow, and to what limit? How much capacity does the immutability period add? And how many hours a month will it take to run? Clear answers to those matter more than the price per terabyte.