Security
Encryption and compression
How Datamotive encrypts data in transit and at rest, and how compression is applied during block transfer.
- Product
- Datamotive Platform
- Version
- v1.0
- Documentation status
- Published
- Last updated
- Updated
- Reading time
- 2 min read
Datamotive applies encryption and compression at two distinct stages: during block transfer (in transit) and at the target (at rest). Compression always happens before encryption so that encrypted data, which is incompressible, does not expand the transfer size.
Encryption in transit
All data transferred from a Replication Appliance or Cloud Connector is encrypted before leaving the source network:
- Algorithm: AES-256-GCM
- Key scope: one data encryption key (DEK) per plan, generated at plan creation time
- Transport: TLS 1.3 wraps the already-encrypted block stream for an additional layer of channel security
- Authentication: mutual TLS (mTLS) between nodes and the control plane; nodes authenticate using a certificate issued at registration time
The combination of per-plan AES-256-GCM encryption and TLS 1.3 means that even if the transport layer were compromised, block data would remain encrypted with the plan-specific DEK.
Encryption at rest
Shadow disks and staging storage at the target are encrypted using the target platform's native encryption:
| Target | Encryption mechanism |
|---|---|
| AWS EBS | SSE with AWS-managed or customer-managed KMS keys |
| Azure Managed Disks | Server-side encryption with platform or customer-managed keys |
| Nutanix AHV | ADSF data-at-rest encryption |
| VMware vSphere | vSAN encryption or datastore-level encryption |
For AWS and Azure, Datamotive can be configured to use customer-managed keys (CMEK/CMK). The KMS key ARN or Azure Key Vault key URI is specified in the site configuration.
Key management
Data encryption keys (DEKs)
DEKs are generated by the control plane at plan creation. In the SaaS model, DEKs are stored encrypted in the Datamotive KMS using envelope encryption: the DEK is wrapped by a key encryption key (KEK) stored in AWS KMS. Customers who supply their own KMS key become the KEK owner; Datamotive never has access to the plaintext KEK.
In self-hosted deployments, the KEK is stored in a secrets manager configured by the customer (HashiCorp Vault, AWS KMS, Azure Key Vault). Datamotive calls the secrets manager API at job start to unwrap the DEK.
Key rotation
DEKs can be rotated manually from Settings then Security then Encryption keys. Rotation re-encrypts all stored metadata references with the new DEK. The previous DEK is retained for 30 days to allow in-progress jobs to complete, then purged.
Compression
Compression runs on the Replication Appliance or Cloud Connector before encryption, in the block transfer pipeline:
| Algorithm | Typical ratio | CPU impact | Best for |
|---|---|---|---|
| LZ4 (default) | 1.5:1 to 2:1 | Low | Mixed enterprise workloads |
| ZSTD level 3 | 2:1 to 3:1 | Medium | Text-heavy, log-heavy workloads |
| None | 1:1 | Minimal | Already-compressed data (media, encrypted volumes) |
The algorithm is configurable per plan in Advanced replication settings. Setting compression to None is appropriate for workloads where most data is already compressed (for example, video storage or encrypted database volumes).
Related docs
Was this page helpful?