Encryption is one of the first boxes ticked when a NAS is set up as a backup repository. Volume encryption is a checkbox in the setup wizard, the backup software offers encryption of its own, and compliance questionnaires ask whether backups are encrypted at rest. With all three in place, the repository can feel well protected. Encryption does protect against specific threats, and it is worth having. It also leaves the most common attack on backups untouched.
The useful question is not whether backups are encrypted, but against whom. Each layer of encryption assumes an attacker in a particular position, and offers nothing against an attacker in a different one.
The layers of encryption on a backup NAS
Volume or disk encryption on the NAS encrypts data as it is written to disk and decrypts it as it is read. The key is held by the NAS, often unlocked automatically at boot or by an administrator after a restart. Anyone reading files through the share sees plaintext, because the NAS decrypts on their behalf.
Encryption in transit protects the path between the backup server and the NAS. SMB 3 supports encryption on the wire, and NFS can be run over Kerberos with privacy protection. Many estates leave both disabled for performance reasons, so traffic between backup server and repository travels unencrypted on the local network.
Backup software encryption is applied by the backup application before data leaves the backup server. The NAS stores files it cannot read, and the key is held by the backup software. This is the strongest layer of confidentiality, and also the one with the most demanding key management.
What each layer protects against
| Threat | Volume encryption | In-transit encryption | Backup software encryption |
|---|---|---|---|
| Disks removed or stolen | Protected | No effect | Protected |
| Traffic captured on the network | No effect | Protected | Protected |
| Files read through the share | No effect, the NAS decrypts | No effect | Protected without the key |
| Files encrypted by ransomware through the share | No effect | No effect | No effect |
| Files deleted by a compromised account | No effect | No effect | No effect |
| NAS admin deletes volumes or snapshots | No effect | No effect | No effect |
The bottom three rows describe how ransomware usually treats a backup repository. It does not need to read the backups. It needs to make them unusable, and encrypting an already encrypted file, or deleting it, works just as well whatever its contents. All it needs is the access the backup software already has, which is why credentials are the weak point on SMB and NFS backup shares.
Encryption is about confidentiality, not availability
Encryption keeps data secret from those without the key. It does nothing to keep data present and unchanged. A backup repository needs both, and in most incidents availability is the property under attack. An organization whose encrypted backups have been deleted is no better off than one whose plaintext backups have been deleted.
Encryption can even make availability worse if keys are handled carelessly. A backup software encryption key stored only on the backup server is lost along with that server in a ransomware attack, and the backups it protected become unreadable to their owner. Keeping a recovery copy of backup encryption keys covers the precautions that prevent this.
What protects availability
Protecting backups from modification and deletion requires storage that refuses those operations, regardless of who requests them. On a NAS, that can mean locked snapshots where the platform supports them, though these remain within reach of anyone who can delete the underlying volume. On object storage, it means S3 Object Lock, where each object carries its own retention and the storage refuses to remove it early. NAS snapshots versus immutable backups compares the two approaches directly.
Encryption and immutability work together. Immutability keeps restore points present. Encryption keeps them private. A repository with only one of the two has half the protection its owners may believe it has.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. Backup software such as Veeam writes to it through an S3 compatible API over HTTPS, so traffic between backup server and repository is encrypted in transit. Backup software encryption can be applied on top, with keys held by the backup application.
For availability, it supports S3 Object Lock, so restore points can be locked at write time and refused deletion or overwrite until retention expires. It scales from roughly 50 TB to 8.5 PB and is often added alongside an existing NAS as an immutable copy target, leaving the NAS as a fast primary repository.
Answering the questionnaire honestly
When an auditor or insurer asks whether backups are encrypted, the accurate answer usually names the layers in use and the threats they cover. A better follow-up question, and one increasingly asked, is whether backups can be deleted by a compromised administrator. Answering that requires a test, not a setting: attempt to delete a recent restore point with the most privileged account available, and record whether the storage allowed it. That result says more about recoverability than any encryption checkbox.