Many NAS devices offer snapshots, and many are marketed with some form of protection against ransomware. For a team writing backups to a NAS, it is tempting to treat those snapshots as the immutable copy: if the backup files are encrypted, roll the share back to last night's snapshot. Sometimes that works. Whether it works in a real attack depends on what the attacker can reach, and that is where snapshots and immutable backups part company.
Both are useful. They protect against different things, and a design that relies on one while believing it has the other tends to discover the difference at the worst possible moment.
What a NAS snapshot is
A snapshot is a point-in-time view of a volume, kept by the storage system itself. Most implementations use copy-on-write or redirect-on-write, so the snapshot costs little space at first and grows as the live data changes. Restoring from a snapshot is fast, because the data never left the device, and snapshots can be taken frequently with little overhead.
Snapshots are managed by the NAS. They are created on a schedule set by its administrator, retained according to its policy, and deleted by its own housekeeping or by an administrator. Some NAS platforms offer locked or immutable snapshots that cannot be deleted before a set time, even by an administrator. Others do not, or offer it only on certain models or licenses.
What an immutable backup is
An immutable backup is a restore point written to storage that refuses to modify or delete it until a retention period expires. On object storage this is usually S3 Object Lock, applied to each object at write time. In compliance mode, the lock cannot be shortened or removed by any user, including the storage administrator, until it expires. The protection belongs to the data, not to a schedule on the device.
Immutable backups are written by the backup software, which also knows what each one contains, which chain it belongs to and how to restore it. A snapshot knows only which blocks of a volume existed at a moment in time. What immutable backups protect covers the model in more depth.
Comparing what each one survives
| Event | NAS snapshot | Immutable backup on object storage |
|---|---|---|
| Backup files encrypted through the share | Survives, the snapshot holds the earlier blocks | Survives, locked objects cannot be overwritten |
| Backup service account used to delete files | Survives if snapshots are outside the account's reach | Survives, deletion is refused until retention expires |
| NAS administrator account compromised | Lost unless snapshots are locked against admin deletion | Survives in compliance mode, which no admin can lift |
| Volume or pool deleted on the device | Lost, snapshots live inside the volume | Depends on whether the storage protects its own configuration |
| Hardware failure of the device | Lost with the device, unless replicated elsewhere | Survives where data is spread across servers |
| Attacker waits for retention to lapse | Lost once the snapshot schedule rolls past it | Lost once the lock expires, so retention must exceed dwell time |
The pattern is clear in the third and fourth rows. A snapshot is only as protected as the administrative access to the device holding it. In many attacks, the NAS admin interface is reachable from the compromised network, and its password is either reused, default or stored somewhere the attacker can read.
Snapshots are still worth having
None of this makes snapshots useless. They are fast to take and fast to restore, they catch accidental deletion and simple file encryption through the share, and they cost little. In a layered design, a snapshot is the quickest way back from a small mistake. The issue is only when snapshots are treated as the last line of defense, the copy that survives a determined attacker with administrative access.
The question to ask of any snapshot-based design is who can delete the snapshots, and from where. If the answer includes any account that could be compromised along with the production environment, the snapshots are part of the attack surface rather than outside it. Taking backup infrastructure off the domain covers one way to change that answer.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. It supports S3 Object Lock in both governance and compliance modes, so restore points written by Veeam and other backup software can be locked at write time for a set retention. In compliance mode the lock holds against every account, including ARTESCA administrators.
A common pattern keeps the NAS in place as a fast primary repository with snapshots for quick recovery, and adds ARTESCA as an immutable copy target through the backup software's copy jobs. It scales from roughly 50 TB to 8.5 PB. Choosing between governance and compliance mode covers the decision made when the bucket is created.
Testing which one you actually have
A simple exercise settles the question for any existing design. Log in to the NAS as its administrator and try to delete a snapshot newer than its retention. If the device allows it, the snapshots are protected only by the admin password. Then try to delete a locked object on the immutable target with the most privileged account available. If the target refuses, the restore point is protected by the storage itself. The results of those two tests describe what will survive far more accurately than any product sheet.