Encryption compatibility with the Datto Solution
Topic
This article explains the potential limitations of backing up and virtualizing operating systems that use hard drive encryption. This article also provides an FAQ about the types and methods of encryption used by Datto.
Environment
- Datto SIRIS
- Datto ALTO
- Datto NAS
Description
Using active disk encryption on a host protected by a Datto device can potentially create a situation in which one or more encrypted files cannot be fully restored. It can also limit the Datto appliance's access to back up key files on the host operating system needed to create a bootable virtualization. Because many different types of encryption products exist, we recommend that you perform thorough compatibility testing before you are in a disaster recovery scenario.
NOTE Datto Technical Support cannot make specific compliance-related recommendations.
Common Encryption Types
File-Level Encryption - Files using this type of encryption can often be restored by a Datto appliance. The health of a protected server, such as corruption on the server's hard drive, can affect the decryption capabilities of file-level encryption.
Full-Disk Encryption - If your server uses a full-disk encryption product, such as BitLocker or TrueCrypt, the machine is in a decrypted state when your Datto appliance backs it up. As a general rule, disk-level encryption solutions which perform decryption at a low level, before the operating system is completely loaded, will work with the Datto solution.
However if the encryption solution is dependent upon a running application or driver within the operating system, it's much less likely to be compatible. Datto recommends performing periodic local virtualizations and file restores to test the boot and restore integrity of full-disk encryption backups.
Encrypted Windows Boot Files - Datto does not recommend encrypting Windows boot files, because this type of encryption might affect the bootability of the protected system in a restore scenario.
If you are concerned about the security of your data during its transfer between the protected system and the Datto appliance, consider encrypting the data with SIRIS encryption (login required).
Restoring Machines with Encryption
Depending on the level of encryption in use on the production machine, restore options may be more limited in nature. If the encryption is at the drive level, and the drive is unlocked, or we are able to back it up in an unencrypted state, there should be no limitation on restores.
If you are backing up a volume using file-level or block level encryption, certain granular restores such as file restores will not work properly. If the machine you are restoring data to has the same encryption software as the source then iSCSI-based restores, such as our Direct Restore Utility, may allow the files to be decrypted, so long as the machine accessing the restore has the same software.
If EFS is in use, the restore would need to have the same local user or administrator role to match the file's owner or administrator of the file. If neither scenario is the case, than the only way to extract files would need to be done through virtualizing the agent, be it on the local device, on a hypervisor, or as a last resort, in the cloud.
Restore Type Compatibility Chart
| Encryption | File Restore | Direct Restore | BMR | Image Export/ESX upload | Virtualization (Local/cloud/hypervisor) |
|---|---|---|---|---|---|
| EFS | X | ✓ | ✓ | ✓ | ✓ |
| 7zip | ✓ | ✓ | ✓ | ✓ | ✓ |
| VeraCopy | X | ✓ | ✓ | ✓ | ✓ |
| TrueCrypt/VeraCrypt | ✓ | ✓ | ✓ | ✓ | ✓ |
| Dm-crypt | ✓ | ✓ | ✓ | ✓ | ✓ |
| Bitlocker | ✓ | ✓ | ✓ | ✓ | ✓ |
FAQ
Q: My customer wants to activate BitLocker on a production server. What impact will this have on his Datto backups ✓
A: On BitLocker-protected servers, the entire disk is encrypted until you enter its passkey and decrypt it. Once in the decrypted state, the Datto solution can back it up. Our backup solution does not differentiate between a decrypted BitLocker system and a system that does not have BitLocker installed.
Incremental backups are not affected in size by BitLocker. Restores and virtualizations are also typically unaffected, because the Datto solution restores the system in its decrypted state.
Q: Is there any encryption of my backups during transmission from the protected server to the Datto appliance on the LAN ✓
A: During local transmission between the agent and the Datto appliance, our technology uses public & private key pairs for security.
Protected systems use SHA-256 to sign the certificates that we use to communicate with the Datto appliance. The protected system acts as the server, and the Datto device as the organization and all requests to the agent are encrypted this way.
For the backup data itself, all of our agents can use the iSCSI protocol to read and write the volume data. The Datto Windows Agent also has support for the MercuryFTP protocol, which leverages security tokens and BLAKE2 encryption to help with data transmission.
Even when using CHAP authentication over iSCSI, you are only provided with authentication protection. It does not protect against data transmission eavesdropping or data at rest. Although the volume data is unencrypted using this method, the process by which we determine where to connect to and send the data is encrypted. The Datto appliance gives us the target, location, and a username and password.
Q: What encryption is used on the Datto disks itself?
A: There is no native encryption on the disks itself. The security is dependent on the local Datto & Linux operating system, and relies on the protection surrounding the backup-admin and user accounts. Encrypting your agents can thwart most people from accessing the disks, and protecting the device's backup-admin credentials adds a second layer of protection. See SIRIS, ALTO, and NAS: Secure deployment best practices for Datto appliances.
Q: What kind of encryption do the offsite replication connections use?
A: Datto appliances support the following ciphers:
- 3des-cbc
- aes128-cbc
- aes192-cbc
- aes256-cbc
- rijndael-cbc@lysator.liu.se
- aes128-ctr
- aes192-ctr
- aes256-ctr
- aes128-gcm@openssh.com
- aes256-gcm@openssh.com
- chacha20-poly1305@openssh.com
The default ciphers used are:
- chacha20-poly1305@openssh.com
- aes128-ctr
- aes192-ctr
- aes256-ctr
- aes128-gcm@openssh.com
- aes256-gcm@openssh.com
Offsite server access is strictly enforced with public & private SSH key exchanges, and 2-Factor Authentication (mfa).
