Home  ›  Glossary  ›  Backup Encryption

What is backup encryption?

Backup encryption is the scrambling of backup data with a cryptographic key so that only a holder of that key can read it. Copied backup files, pulled drives or a downloaded bucket are useless to anyone without the key. Encryption protects what a backup contains and does nothing to stop the backup being deleted.

Source, network and disk encryption

A backup repository is the most complete copy of an organization's data in one place, often reaching back months across databases, mailboxes, file shares, HR and finance. Walking away with it yields what a breach of every production system would, which is why attackers who steal data for double extortion ransomware look at backups early. Encryption can be applied at three points, and each covers a different loss:

LayerWhere it happensLoss it covers
At the sourceBackup agent, proxy or backup server, before data leavesTheft anywhere downstream; the storage never holds readable data
In transitTLS on the connection to backup storageInterception on the network
At restThe backup storage, as data is written to diskStolen, lost, returned or decommissioned drives and servers

Encryption is also a standard line on audit and cyber insurance questionnaires, and GDPR names encryption among the measures for protecting personal data. An unencrypted tape lost in transit or a drive returned under warranty can turn into a reportable incident, where an encrypted one usually does not.

Data keys wrapped by a master key

Most backup products use AES with 256-bit keys, arranged in layers. Each backup set or bucket gets its own data key, and those data keys are encrypted in turn by a master key held in a key management system, often backed by a hardware security module. When the organization, and not the vendor or provider, controls the master key, the setup is called customer-managed keys. Revoking that master key cuts off every data key beneath it at once.

A restore that waits for the key manager

An encrypted backup is only as restorable as its key. If the encryption password exists only in the configuration of a backup server that ransomware has just encrypted, or the key manager runs as a VM on the cluster that went down, the owner is locked out as thoroughly as the attacker. In a rebuild, the key manager or an escrowed copy of the key comes back first, before a single byte of data.

Encryption also says nothing about survival. An attacker with write access to a repository has no need to read the backups, since deleting them or encrypting them again under a new key works just as well. Encryption limits the harm of data exfiltration, while only storage that refuses deletion, as with an immutable backup, limits the harm of deletion. They are two separate answers on an audit form.

Encrypting before or after deduplication

Encrypted data looks random, so it neither compresses nor deduplicates. Software that reduces data first and encrypts afterwards keeps its savings. Data encrypted at the source and then sent to a deduplicating target lands close to full size, and a repository sized on an expected reduction ratio can fill months ahead of plan once encryption is switched on at the wrong layer. The savings side is covered under deduplication.

ARTESCA and backup encryption

On ARTESCA, data at rest is encrypted with AES-256, S3 connections are accepted over HTTPS, and encryption is configured per bucket with keys held in an external KMIP-compatible key management system, away from the storage they protect. Backup software that has already encrypted at the source can write to the same buckets, and S3 Object Lock retention applies to those objects whoever holds their keys.

ARTESCA does not hold or escrow the backup software's own encryption passwords. Those stay with the backup application, and losing them leaves locked objects intact but unreadable.