Immutability is usually discussed in terms of attackers. An immutable restore point cannot be deleted or encrypted by ransomware, by a compromised administrator account or by a mistake. That protection is real, and it is the reason immutability has become a standard requirement for backup repositories. What it does not cover is the hardware the immutable data sits on. When all of that data lives on a single server, immutability and availability depend on very different things.
A single-server immutable repository is a common design, particularly as a hardened Linux repository or a small appliance. It refuses deletion. It does not refuse a failed disk controller, a burned-out power supply or a firmware bug that corrupts a RAID set.
What immutability does and does not promise
An immutable restore point is protected from logical changes: overwrite, deletion and modification of its retention. The protection is enforced by software, either the file system on a hardened repository or the object storage layer with Object Lock. Physical failures sit beneath that software. If the disks holding a locked file fail beyond what RAID can recover, the file is gone, and the lock on it means nothing.
This sounds obvious, but it shapes how teams think about risk. A repository described as immutable is often treated as the copy that will always be there. On a single server, it is the copy that will always be there unless the server is lost, which is a different and weaker statement. What immutable backups protect sets out the logical side in more detail.
Failure modes on a single server
| Failure | Effect on the repository | Effect on immutable data |
|---|---|---|
| Single disk failure | RAID degraded, rebuild begins | Intact, but at higher risk until the rebuild finishes |
| Second disk failure during rebuild | Volume may be lost, depending on RAID level | Lost with the volume |
| RAID controller failure | Repository offline until replaced | Usually intact if the replacement reads the array |
| Motherboard or power failure | Repository offline until repaired | Intact on disk, unavailable until the server returns |
| Firmware or file system corruption | Repository may not mount | At risk, recovery depends on tools and expertise |
| Site loss, fire or flood | Server destroyed | Lost unless a copy exists elsewhere |
The fourth row is the most common in practice. A server that is offline for three days waiting for a replacement part holds intact data that nobody can restore from. If that is the week a ransomware incident lands, the immutable copy is unavailable at exactly the moment it was kept for.
Rebuild time is the exposure window
Large drives take a long time to rebuild. On a busy server that continues to accept nightly backups during the rebuild, the process can stretch to several days. For that period, the volume is running with reduced protection. RAID 6 can tolerate a second failure during the rebuild of the first, but not a third, and unrecoverable read errors on surviving disks become more likely as drive capacities grow. The longer the rebuild, the larger the window in which the single server's data is exposed to a hardware event.
A second copy is the answer, not a better server
Better hardware, redundant power and hot spare disks reduce the likelihood of a failure. They do not change the fact that one server is one failure domain. The established answer is a second copy of the backups in a separate failure domain, preferably also immutable, preferably in a different room or site. The 3-2-1 rule exists for this reason. Watching backup copy job lag covers how to tell whether the second copy is keeping up.
The alternative is to spread the immutable repository itself across several servers, so that one server failing does not take the data with it. Object storage designed for this distributes data and its protection across servers, so a single server outage reduces redundancy without making restore points unavailable.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. It provides immutability through S3 Object Lock and can be deployed across several servers, with data protection spread across them, so the loss of one server does not mean the loss of locked restore points or of access to them. It can also run on a single server where that suits a smaller site, in which case the same advice about a second copy applies.
It presents an S3 compatible API, is used as a target for Veeam and other backup software, and scales from roughly 50 TB to 8.5 PB. It is frequently used as the immutable second copy alongside an existing single-server or NAS repository. The operations workload of a hardened Linux repository covers the day-to-day side of the single-server design.
Questions to ask of an existing design
For any single-server immutable repository, three questions are worth answering in writing. How long would it take to restore service if the server failed tonight, including the time to obtain parts? Where is the second copy of the restore points it holds, and is that copy also protected from deletion? And how long does a disk rebuild take on the current drives under a normal backup load? If the answers are several days, nowhere and unknown, the repository is immutable, but the backups are not yet resilient.