Concepts
Metadata management
What metadata Datamotive stores, where it lives, and how it is protected.
- Product
- Datamotive Platform
- Version
- v1.0
- Documentation status
- Published
- Last updated
- Updated
- Reading time
- 2 min read
Datamotive separates workload data from metadata. Understanding this separation is important for data residency planning and compliance assessments.
What is metadata
Metadata in Datamotive includes:
- Plan definitions: which VMs are protected, RPO/RTO targets, network mappings, group ordering
- Site and credential references: hostnames, cloud account IDs, and encrypted credential references (not plaintext secrets)
- Job records: start time, end time, status, bytes transferred, error messages
- Recovery point index: timestamps, consistency type, disk snapshot IDs at the target cloud
- User accounts and RBAC assignments
- Audit log entries
Metadata does not include:
- Block-level disk content from protected workloads
- File contents, database rows, or application data of any kind
- Guest OS credentials or application configuration files
Where metadata lives
SaaS-managed deployment
Metadata is stored in Datamotive's multi-tenant control plane, hosted in AWS us-east-1 (primary) with replication to eu-west-1 for durability. Tenant data is logically isolated using separate encryption keys per tenant.
Self-hosted deployment
Metadata lives in a PostgreSQL database inside the customer's control plane VM or Kubernetes namespace. The customer is responsible for backing up and protecting this database.
Sovereign cloud deployment
Metadata is stored inside the sovereign boundary in a PostgreSQL instance managed by the customer. No metadata crosses the air-gap boundary after initial installation.
Metadata security
Datamotive encrypts all metadata at rest using AES-256. In the SaaS model, each tenant has a unique data encryption key (DEK) wrapped by a key encryption key (KEK) stored in AWS KMS. Customers who require customer-managed encryption keys (CMEK) can supply their own KMS key ARN during tenant provisioning.
Credential secrets (cloud access keys, vCenter passwords) are never stored in plaintext. They are encrypted with an additional layer of envelope encryption and stored as sealed references. The control plane decrypts credentials only at job execution time, and only the specific credential needed for that job is decrypted.
Metadata backup
For self-hosted and sovereign deployments, back up the PostgreSQL database daily using a snapshot or pg_dump. The backup does not need to include workload data (which lives at the target cloud), only the metadata database.
If the control plane is lost and must be rebuilt, the metadata database backup allows full recovery of all plan definitions, job history, and recovery point indices. Replication resumes automatically after the control plane is restored and nodes re-register.
Related docs
Was this page helpful?