Terminology glossary

This glossary defines terms used throughout Datamotive documentation. Where a term has a specific Datamotive meaning that differs from general industry usage, that meaning is noted.

A

Appliance — See Replication Appliance.

Application consistency — A recovery point in which all in-flight transactions are committed before the snapshot is taken, so the restored workload starts cleanly without journal replay. Requires VSS (Windows) or pre/post freeze scripts (Linux). Contrast with crash consistency.

B

Block transfer — The process of reading changed disk blocks from the source and writing them to the target. Datamotive compresses and deduplicates blocks during transfer to reduce bandwidth usage.

Bootstrap seed — The initial full copy of a workload's disks transferred to the target. After the bootstrap completes, only changed blocks (incremental) are transferred.

C

CBT (Changed Block Tracking) — A hypervisor-level mechanism that records which disk blocks have changed since the last snapshot. Datamotive uses vSphere CBT (for VMware), Nutanix CBT, and EBS snapshot differentials (for EC2) to avoid re-reading unchanged blocks.

Cloud Connector — A lightweight VM deployed in a cloud account (AWS or Azure) that acts as the local replication endpoint. Receives compressed block data from the Replication Appliance and writes it to the target disks.

Control plane — The management layer of Datamotive. Orchestrates jobs, stores plan metadata, exposes the API, and serves the console. Can run as SaaS, self-hosted, or sovereign.

Crash consistency — A recovery point taken without quiescing the workload, equivalent to restoring from a sudden power loss. Applications that use write-ahead logs (most databases and file systems) can recover from crash-consistent points, though journal replay adds startup time.

D

Data plane — The replication engines and transfer pipelines that run inside the customer's infrastructure. All customer data moves through the data plane; no customer data transits Datamotive's SaaS infrastructure.

DR drill — A test of a recovery plan that boots shadow VMs in an isolated network without disrupting the source workload. Also called a recovery test or non-disruptive test.

E

Easy Backup — Datamotive's backup product. Provides immutable, policy-driven backup with object storage targets and granular restore.

Easy Hybrid DR — Datamotive's disaster recovery product. Maintains continuously updated shadow VMs at a target site for sub-10-minute RTO.

Easy Migrate — Datamotive's migration product. Uses the same replication engine as Easy Hybrid DR but orchestrates wave-based cutovers instead of ongoing DR.

Easy Protect — Datamotive's ransomware protection product. Scans each replication cycle for anomalies and maintains a verified clean recovery point.

F

Failback — The process of returning workloads to the original source site after a failover, typically after the source site is repaired. Datamotive reverses the replication direction rather than performing a new bootstrap.

Failover — The process of bringing up shadow VMs at the DR target when the source site is unavailable or during a DR drill.

G

Group — A logical collection of VMs within a protection plan that share the same RPO, RTO, and failover order. Useful for grouping application tiers (web, app, database).

J

Job — A unit of work executed by the Datamotive engine: a replication cycle, a failover, a failback, a DR drill, or a consistency check. Jobs are tracked with status, duration, and log output.

M

Metadata — Information about workloads, jobs, plans, and recovery points. Stored in the control plane. No customer workload data is included in metadata.

N

Node — A Replication Appliance or Cloud Connector registered with the control plane. A site may have one or more nodes.

P

Plan — A protection or migration plan. Contains the list of workloads to protect or migrate, their grouping, RPO/RTO targets, network mappings, and failover order.

Protection plan — A plan configured for ongoing DR (Easy Hybrid DR). Maintains shadow VMs indefinitely until the plan is deactivated.

R

Recovery point — A point-in-time snapshot of a workload stored at the target. Datamotive maintains multiple recovery points per workload according to the configured retention policy.

Recovery time objective (RTO) — The maximum acceptable time from a failover decision to the workload being available at the target. Datamotive Easy Hybrid DR targets RTO under 10 minutes.

Recovery point objective (RPO) — The maximum acceptable age of the recovery point used for failover. A 15-minute RPO means the workload can lose at most 15 minutes of data.

Replication Appliance — A Linux VM deployed inside a VMware vSphere cluster that reads changed blocks from the hypervisor API and transfers them to the target. One appliance protects up to 300 VMs.

Replication cycle — One pass of the incremental replication engine: read changed blocks since the last checkpoint, compress, transfer, and commit. Cycle duration determines the achievable RPO.

Retention policy — Rules that determine how many recovery points to keep and for how long. Datamotive supports count-based (keep last N) and time-based (keep for N days) policies.

RPO — See Recovery point objective.

RTO — See Recovery time objective.

S

Shadow VM — A VM created at the DR target site that mirrors the source workload's disks. It remains powered off between replication cycles and can be booted in seconds during a failover.

Site — A logical grouping of nodes in the same physical location or cloud account. A replication path always connects a source site to a target site.

Sovereign cloud — A deployment model in which both the control plane and data plane operate inside a defined, air-gapped boundary with no external network dependencies after initial installation.

T

Target — The cloud account, region, or data center that receives replicated data and hosts shadow VMs.

W

Wave — A batch of VMs that are cut over together during a migration project. Waves are sequenced to respect application dependencies.

Related docs

• Architecture patterns

• Deployment models

• Core platform overview

• RPO and RTO best practices