Concepts
Block transfer
How changed blocks move from source to target — chunking, rolling windows, parallel streams, and the optional compression, encryption, and dedupe transforms.
- Product
- Datamotive Platform
- Version
- v2.0.3
- Last updated
- Updated
- Reading time
- 1 min read
After CBT identifies changed blocks, the block transfer pipeline moves them to the target. Datamotive uses a rolling-window, descriptor-driven transport instead of sequential stop-and-wait transfer — built for fragmented enterprise change sets over WAN links.
Transfer mechanics
| Element | Behavior |
|---|---|
| Chunk size | 1 MB default. Changed data is packaged into chunks scheduled by replication descriptors (offset, length, metadata, state). |
| Per-disk window | 32 MB default, adaptively scaled across 16 / 24 / 32 / 48 / 64 MB based on storage-write pressure, WAN stability, API responsiveness, and retry rates. |
| Parallel streams | Multiple chunks in flight simultaneously across disks, workloads, and workers — no idle WAN periods between batches. |
| Flow control | Target-side workers pull replication windows and centrally manage inflight concurrency and node-level backpressure. |
| Intermediate checkpoints | Every 500 MB (default), bounding retransmission after interruptions. |
| Finalization | Chunk validation, storage-write completion, metadata sync, and consistency validation produce the recovery checkpoint. |
Optional transforms
Three per-plan options reduce and protect the data on the wire (set in the replication configuration):
- Compression — compresses data in transit; the dashboard's Data Reduction metric reports the achieved average for compression-enabled replications.
- Encryption on Wire — encrypts data in transit from source to destination (encrypted transfers use the dedicated port 5002).
- Dedupe — the DeDup Node on the recovery site keeps checksums and data for transferred chunks; already-replicated chunks are referenced instead of resent. Most effective for similar workload datasets, standardized OS builds, and one-time migrations.
Bandwidth behavior
Replication time is a function of changed data volume and available bandwidth. Datamotive recommends a minimum of 150 Mbps dedicated between replication nodes for a fully loaded node (40 parallel disks). Under-provisioned bandwidth never loses data — changed data eventually syncs — but stretches iterations and can breach the plan's RPO (exceeded interval status).
Bandwidth throttling caps usage globally, per node, or per time window. Internal validation testing sustained ~420 Mbps (≈70% of practical WAN limits) on a single node replicating 40 VMs / 80 disks from Azure to AWS — see the Scale and performance guide.
Full vs incremental
The first iteration per disk transfers full data (Type: Full in the Disks job view); subsequent iterations transfer changed blocks only (Incremental). A resync — triggered by recovery-configuration changes or the reset-disk action — re-replicates entire disks.
Related docs
Was this page helpful?