Encrypted backup: a complete security guide for your backups

Protecting backups is no longer optional: with the rise of ransomware and massive data breaches, Encrypting backups has become a key part of any security strategyHaving a copy is not enough; if that copy is in plain text, any attacker who gets hold of it will be able to read and exploit all the information.

In the following lines we will see in detail how encrypted backup works on different platforms (Azure, AWS, software solutions such as NAKIVO, Veeam or Synology C2), what algorithms are used, how keys are managed and What risks and best practices should you consider to avoid losing your data?The goal is for you to end up with a complete and grounded vision, in clear and straightforward Spanish.

What exactly is an encrypted backup?

When we talk about encrypted backup, we are referring to the process by which The data in a backup is transformed from a readable format to an unreadable one. using a cryptographic algorithm and an encryption key. Without that key (or without the password that generates the key), the backup's contents are useless to anyone who steals or intercepts it.

In practice, this means that a file, database, or virtual machine image becomes a seemingly random block of data; Only authorized systems or people with the correct key can reverse that process and view the original information again. If a third party accesses the copy file, without the key they will only see encrypted data with no practical value.

This encryption can be applied while the copy is being generated (at the source), during transmission over the network, or on data already stored; Ideally, you should combine the three layers: origin, transit, and rest.to cover the entire backup lifecycle.

A simple example: you take a text file with customer data and send it to a backup repository. If you encrypt it with AES-256 following best practices of secure backups, the content is converted into ciphertext; Even if someone steals the disk or intercepts the traffic, they will not be able to reconstruct the information without the decryption key..

Why is encrypting backups so important?

Backups have always been seen as a lifeline for recovering information, but increasingly they are also a direct target for attackers. If ransomware or an intruder manages to destroy or steal your backups, it leaves you without a plan B. and multiplies the impact of the incident.

Encrypting copies has several clear benefits: for one thing, even if someone steals the files or cartridges, The information will remain protected against unauthorized accessOn the other hand, it helps to comply with regulatory frameworks that require encryption of sensitive data both in transit and at rest.

Regulations such as GDPR, PCI DSS, HIPAA, CCPA, SOC 3 or CIRCIA require robust protection measures for personal, health, or financial data. In many cases, encrypting backups is no longer a recommendation, but a requirement to avoid penalties and legal liabilities.

There is also a practical angle: when you transport backups on removable media (disks, tapes, NAS being moved to another data center, etc.), Encryption drastically reduces the risk of loss or physical theft of the storage mediumIf an external hard drive with encrypted copies disappears, the impact is much less than if it were in plain text.

However, encryption is not magic: it involves more technical and organizational complexity. You must manage your keys well, accept a slight performance impact, and prepare recovery processes. that consider the use of passwords or KMS so as not to lock you out on the day you really need to restore.

Encrypted backups against ransomware

Ransomware has changed the rules of the game. The usual tactic is no longer just to encrypt production data, but also locate and destroy backups, or exfiltrate backups to blackmail you with their publicationIf your backups are not properly protected, the attacker can leave you with no possibility of recovery.

It is important to understand one key nuance: The fact that a backup is encrypted does not prevent ransomware from deleting or re-encrypting it.Malware often uses its own encryption algorithms to make you lose access to the file, so if the copy is accessible with write permissions, the attacker or malware can corrupt it anyway.

Where encryption really makes a difference is in confidentiality. If an attacker downloads your backup files but they are encrypted with strong algorithms and well-protected keysThey will not be able to extract the information to sell or publish it. In that scenario, blackmail through data dissemination loses its power.

To increase resilience against ransomware, many organizations combine encryption with other measures such as immutable or network-isolated (air-gap) storageAn immutable backup cannot be modified or deleted during its retention period, preventing ransomware from altering it even if it manages to see it.

This approach is especially common with solutions such as Veeam Backup & Replication, which allows you to create immutable copies on Linux storage or Amazon S3When immutability is active from the moment the copy or replica is created, your backup data is protected from both malicious encryption and accidental or intentional deletion.

Encryption in transit and encryption at rest

In any modern backup architecture, there are two moments when encryption is critical: when data travels over the network and when it rests in the repository. Encryption in transit It means protecting the information while it is in transit; encryption at rest This means protecting it while it is in storage.

Encryption in transit is applied between the source (server, database, NAS, etc.) and the destination of the copy, usually by protocols such as HTTPS, SSL/TLS, or encrypted channels specific to the solutionIn this way, if someone captures the traffic with a sniffer, they will not be able to reconstruct the backup data.

Encryption at rest operates on backup files that are already stored: tape cartridges, disks, cloud storage, backup software repositoriesetc. Here, symmetric algorithms such as AES are used, supported in hardware or software depending on the platform.

Ideally, you should use both at the same time: encrypt the data while it is being transported and encrypt it again (or keep it encrypted) at the destinationThis reduces the risk of both network intrusions and unauthorized access to the underlying storage.

Practical examples: solutions like Azure Backup encrypt traffic with HTTPS and leave data stored under AES-256 encryption in Azure Storage; NAKIVO offers source-side encryption, network encryption, and repository encryption. To cover all situations, cloud providers like Synology C2 use SSL/TLS channels to protect transfers.

Encryption algorithms used in backups

Behind encrypted backups lie mathematics and cryptography. In practice, almost all modern solutions use them. combinations of symmetric and asymmetric encryption, and sometimes also hash functions to ensure integrity and authenticity.

Symmetric encryption uses a single key to encrypt and decrypt. Algorithms such as AES, DES, 3DES, Blowfish, or Twofish belong to this groupAES (Advanced Encryption Standard) has become the de facto standard thanks to its balance between security and performance.

Asymmetric encryption works with a pair of keys: one public and one private. RSA, ECC, DSA or Diffie-Hellman are examples of asymmetric algorithmsThe public key is used for encryption, the private key for decryption, which is ideal for protecting symmetric keys or establishing secure channels.

In backup environments, the usual practice is: Encrypt the actual backup content with AES (e.g., AES-256) and protect that AES key with RSAThis gives you the performance of symmetric encryption for large volumes of data and the security of asymmetric cryptography for key exchange and storage.

Key length is critical. AES-256, with 256-bit keys, provides a level of security considered very highto the point that governments and large companies use it to protect sensitive information. Brute-forcing an AES-256 key with current methods is, in practice, impossible.

In network environments, transactions are typically protected with TLS (evolution of SSL), and it is recommended to use at least TLS 1.1 or higherProtocols such as HTTPS travel over TLS, securing the channel between clients and backup servers or between appliances and clouds.

Encryption vs. hash: different roles

It is important not to confuse encryption with hash. Encryption is reversible (if you have the right key), while hash functions are designed to be irreversible.Its objective is not to hide data, but to generate a unique fingerprint that allows verification of integrity or authenticity.

Features like SHA-256 or MD5 transform any input into a fixed-length stringTwo identical entries will produce the same hash; if the hash changes, you know the content has been modified. In backups, hashes are used to verify that a restored file matches the original.

Hashes can also be used in password management or to uniquely identify blocks of data. But they never replace encryption when what you want is to prevent someone from reading the information.To hide the contents of the copy, you need encryption, not just hashing.

Risks and disadvantages of encrypting backups

It's not all sunshine and roses; encrypting backups also introduces certain risks that must be managed carefully. The main one is obvious: If you lose the key or password, your backups become unusable.There is no legitimate "backdoor" to save you if the keys are lost or corrupted.

Another risk is just the opposite: that an attacker gains access to your encryption keysIn that case, even if the backups are formally encrypted, in practice they remain exposed. That's why it's essential to protect the keys as carefully as, or even more carefully than, the data itself.

There are also risks specific to certain media. For example, LTO-4 to LTO-7 tapes support AES-256 encryption on the tape driveThe key is stored on the drive, not on the tape; if in a disaster you lose the backup servers and the drive where the key resided, recovering those tapes may be impossible.

At an operational level, encryption introduces complexity and resource consumption. The copying and restoring processes may be somewhat slower.especially with very long keys or on limited hardware. Furthermore, the infrastructure itself (repositories, KMS, certificates) becomes more sophisticated.

To reduce these risks, it is highly recommended periodically test restores from encrypted backups in different scenariosRepository moved to another instance, keys recovered from a KMS, restores from encrypted tapes, etc. There's nothing worse than discovering the problem on the day of the disaster.

Encryption key management

The security of the entire encrypted backup system rests on one thing: the keys. Using a single key for everything is a huge mistake, because If that key is compromised, your entire backup history is lost with it.The wisest course of action is to segment.

In practice it is recommended Use multiple encryption keys for different datasets, projects, or environments (production, pre-production, user backups, critical database copies, etc.). Each key must be stored securely and only accessible to the strictly necessary roles.

To manage the lifecycle of these keys (creation, rotation, revocation, controlled destruction, auditing, etc.), the ideal solution is to implement a system of key management o KMS (Key Management Service)These systems allow for the automation of a large part of the process and the application of centralized policies.

There is even an interoperability standard, KMIP (Key Management Interoperability Protocol)This allows different backup and storage solutions to communicate with key vaults and HSMs from various manufacturers. Key vaults for securely storing and managing keys are also common.

Without good key management, encryption goes from being an ally to becoming a danger: Either you leave security gaps due to poorly protected passwords, or you risk losing access to your own dataDiscipline is just as important as technology here.

Encryption in cloud backup solutions: Azure and AWS

Large public clouds have been hardening their backup services with increasingly sophisticated layers of encryption. Azure Backup, like AWS Backup, integrates encryption at rest and in transit by default., and allow working with keys managed by the platform or by the client themselves.

Encrypted in Azure Backup

Azure Backup automatically encrypts all data stored in the cloud using the Azure Storage encryption with AES-256 compliant with FIPS 140-2Additionally, traffic between the sources and the Recovery Services store is carried out over HTTPS within the Azure backbone network.

This service uses several levels of encryption. First, the Data encryption in the Recovery Services storewhich by default uses keys managed by the platform. The user doesn't have to do anything to enable this encryption at rest.

If you need more control, you can opt for customer managed keys (CMK) stored in Azure Key VaultIn that case, an AES-256 DEK (Data Encryption Key) protects the backup data, and that DEK is, in turn, protected by the RSA key that you manage. You can revoke the store's access to the key at any time, giving you complete control over access and its lifecycle.

There is also an additional level called infrastructure-level encryptionThis adds a second layer of encryption to the storage infrastructure, managed by the platform. Combining CMK with this infrastructure encryption provides double encryption of the same backup data.

Regarding workloads, Azure Backup supports virtual machines with disks encrypted with both platform keys and client keysas well as VMs protected with Azure Disk Encryption (BitLocker on Windows, dm-crypt on Linux) and SQL databases with TDE enabled, provided you import the appropriate certificates when restoring.

Encryption in AWS Backup

AWS Backup introduces the concept of source-independent encryption for the types of resources it fully manages. This means that the recovery point (the copy) can use a different encryption method than the original resource.

For example, you can have an Amazon S3 bucket encrypted in one way and Configure AWS Backup-managed backups to use a specific KMS key associated with the backup vaultThat vault defines which KMS key encrypts the copies stored there.

For resources that AWS Backup does not fully manage, Copies typically inherit the encryption settings of the original resourceIn those cases you will have to configure the encryption following the guides of the service itself (EBS, RDS, etc.).

When copying backups between accounts or regions, AWS Backup automatically encrypts the backups for most resource types. even if the original was not encryptedThe copy is protected with the KMS key associated with the destination vault.

However, your IAM role must have appropriate permissions on the KMS keys used for backup and restore; otherwise, Tasks can be marked as successful at the orchestration level, but without actually including the objects in the copy.IAM policies and KMS key policies must be aligned, including any deny and grant statements.

AWS Backup uses AES-256 as the standard algorithm for encrypting these copiesAdditionally, in contexts such as cross-region backups, the key associated with the role initiating the task must have specific permissions (e.g., alias/aws/backup resources in DescribeKey) for everything to work without errors.

Enterprise backup and encryption solutions: NAKIVO, Veeam, MyQ, and Synology C2

NAKIVO Backup & Replication

NAKIVO Backup & Replication incorporates a fairly comprehensive approach to copy encryption. It uses AES-256 as the reference algorithm and allows you to activate three types of encryption: at the source, on the network, and in the repository.

El source-side encryption (Available from version 11.0 onwards) allows data to be encrypted within the system that generates the backup, so that it travels encrypted to the repository and remains so throughout its lifecycle. It is especially useful for backups in the cloud or distributed environments.

El network encryption It protects traffic between NAKIVO transporters. In versions prior to 10.11.2, two transporters on different machines were required: the source transporter compresses and encrypts the data, and the destination transporter decrypts and writes it to the repository. This allows the transfer to be encrypted even without a VPN., something very useful for remote environments.

El repository encryption It is configured when creating the backup repository and is supported for incremental backup types, including full and forever incremental, primarily on Linux systems. Enabling repository-level encryption ensures that all backups stored there are encrypted with the set password.

It should be noted that, in NAKIVO, An encrypted repository cannot use immutability. At the same time, if you enable encryption for the entire repository, the immutability feature is disabled. Additionally, the solution can be integrated with AWS KMS to manage passwords and keys more securely and prevent their loss.

Recovery from encrypted backups in NAKIVO is similar to the standard method, but If KMS is not enabled, you will need to re-enter the passwords when connecting repositories to new instances.If you do have KMS, simply reactivate it and select the key used previously.

Veeam and immutability as a complement to encryption

Veeam Backup & Replication has gained a reputation for its focus on ransomware protection. In addition to supporting backup encryption, It leverages the immutability capabilities of Linux file systems and S3 storage. to ensure that the copies cannot be modified or deleted during their lifecycle.

Through automation, Veeam allows Create immutable backups natively in Linux repositories and Amazon S3 bucketsWith immutability active from the creation of the copy or its replica, ransomware cannot encrypt or delete your copies, even if it gains access to the storage.

This approach, combined with encryption of data at rest and in transitIt offers a robust defense: data is encrypted to maintain confidentiality and is immutable to preserve availability and integrity.

MyQ: encryption and database backups

In managed print and cost control environments, solutions like MyQ also integrate backup and encryption mechanisms. From the tab of Confidential Information You can check the status of the main database and registry, make backups, restore, and work with encryption.

To back up your MyQ data, simply Access the main database section, click on Backup and set an optional passwordIf set, that password protects the backup; otherwise, the copy is created without protection.

The result is a file database_*.zip which includes the MyQ database, reports, certificates and configuration filesTo restore, select that ZIP file from the same tab and, if the copy was protected, enter the corresponding password.

As an additional layer, MyQ allows Encrypt the main database using a certificateThe product does not provide certificates; these must be installed by the customer. Once available, they are selected from a drop-down menu, and other services are temporarily unavailable during the encryption or decryption process.

Synology C2: combination of AES-256 and RSA-2048

When you create a Hyper Backup task from a NAS to Synology C2, two AES-256 keys are generated: one to encrypt the file names and another for the backup versionThe first makes the names unreadable on the server side, so no one can see your filenames; the second is randomly generated for each version of the copy.

After the generation, The version key is further encrypted with an RSA-2048 public key before the data is uploaded to the server. This way, even if someone gained access to C2's storage, they could not use the AES keys without the corresponding private key.

On the client side, the RSA public key and an encoded filename key are available. When Hyper Backup Explorer starts, You are asked to set a password to obtain the RSA private keywhich you will need to decrypt the version keys and, therefore, the data.

It is essential to keep that private key safe, because Anything encrypted with the public key can only be decrypted with it.Synology allows you, as a last resort, to request the password-protected private key stored on their end, provided you remember the password. If you lose the key and forget the password, the data will be permanently lost.

In addition, Synology C2 data centers They only recognize incoming data associated with your account.Communication between the NAS and C2 is conducted via encrypted SSL channels. Two-step authentication can also be enabled to further enhance account access security.

Encryption methods: software, hardware, and cloud

Beyond specific solutions, we can classify backup encryption methods into three main groups: software-based, hardware-based, and cloud-basedEach one has its advantages and particularities.

Software-based encryption is the most common: backup applications themselves incorporate built-in encryption functions that operate during the copying processThis avoids the need for additional tools and simplifies management, provided you choose software that implements robust and up-to-date algorithms.

There are also built-in options in end-user operating systems. macOS combines Time Machine with FileVault to encrypt backupsallowing encrypted backups to be stored even in NAS devicesIn Windows, encrypting copies with File History is somewhat more complicated, but it can be achieved using BitLocker or other layers.

Hardware-based encryption relies on devices that include hardware security modules (HSMs) or integrated encryption mechanismsThis includes devices such as some external hard drives, PCIe cards, or USB tokens that store keys. The advantage is that the encryption is performed directly on the device, making the keys much more difficult to extract.

Finally, cloud-based encryption relies on providers that offer end-to-end encryption and secure storage in their data centersIt is important to verify that the data is encrypted on the local device before uploading it (E2EE) and that only you retain the decryption key, instead of "transparent" encryption where the provider has access.

If you use cloud services without their own encryption, such as simple storage like Drive or Dropbox, it is recommended to Apply encryption to backup files yourself beforehand, so as not to depend on the provider's access policies or be exposed to internal access or breaches.

How to further strengthen the security of backups

Encryption is a fundamental piece, but not the only one. To build a solid data protection strategy, it should be combined with other organizational and technical measures that reinforce the security posture.

First, it's key to choose Secure server locations, in certified data centers with good physical and logical protection guaranteesIn cloud environments, it is advisable to prefer regions with strong legal frameworks for data protection.

Another essential point is to enable Multi-factor authentication (MFA) in backup services and management accountsThis way, even if a password is leaked, it will be much harder for an attacker to access consoles and repositories.

It is also advisable to periodically check the access rights to repositories and backup consolesby removing users who no longer need access, applying the principle of least privilege, and auditing permission changes.

And something that many organizations neglect: regularly test data restorationIt is not enough to see that the backup tasks are completed; it is necessary to verify that the complete information can be recovered, within the required timeframes and using the defined encryption keys or passwords.

Overall, the combination of strong encryption, good key management, immutability, isolation of some copies, MFA, and regular restore testing It offers far superior protection against theft, loss, or malicious corruption of data.which is exactly what you want with a good encrypted backup.