Run Pre-flight Checks Before a Kafka Data Clone
Select Run pre-flight to inspect the source, target, schemas, message range, and masking rules. Nothing is written to the target until you review the plan and start the clone.
Run pre-flight again after changing the source topics, scope, range, masking, target, naming, or partition settings.
What pre-flight checks
Pre-flight determines:
- Which target topics already exist and which Kafma will create.
- Whether existing target partition counts differ from the plan.
- Which schemas already exist, must be registered, or need a decision.
- The approximate message count and whether the clone is a heavy workload.
- Whether each masking rule can be applied to sampled records.
The result is an execution plan for the current selection, not a continuous view of either cluster.
Read the execution plan
The summary shows the topic, action, and estimated message counts, together with the time the plan was generated. Review the rows below it before selecting Start Clone.
Common topic actions include:
| Plan result | What will happen |
|---|---|
| Create | The target topic is missing and a structure scope will create it |
| Append Msgs | The target topic exists and Kafma will append the selected messages |
| Skip | No topic or schema change is required, or the selected scope does not permit it |
| Warning | Review the row; some warnings skip work, while masking and unresolved Schema Registry warnings block the clone |
Each topic lists its schema and masking checks underneath. Schema rows show what Kafma plans to register or skip. Mask rows show whether each rule can be applied to sampled messages.
Review topic, schema, message, and masking actions
Check four things:
- Every listed topic is intentional, including its target name.
- The range estimate is small enough for the debugging or test task.
- Each schema row has the expected target action. The execution log reports schema versions discovered from selected messages.
- Every masking rule targets the expected field without a warning.
If the target topic already exists, Kafma keeps its current configuration and partition count. A different partition count does not block the clone; messages are appended to the target's existing partitions.
Understand warnings and blockers
Pre-flight surfaces planned skips, required decisions, and potential problems before the clone:
- Data only skips a topic that does not exist on the target.
- A missing or unreachable target Schema Registry requires a decision for schema-backed data.
- An invalid or unmatched masking rule blocks the clone until it is fixed or removed.
- A large estimated copy warns that Data Clone may be the wrong tool for the workload.
Use a narrower range for local debugging. For continuous or full-cluster replication, use infrastructure designed for that workload rather than a desktop clone.
Resolve Schema Registry decisions
For a structure scope, if the target has no reachable Schema Registry, choose one of the resolutions offered by pre-flight:
- Configure the target Schema Registry and run pre-flight again.
- Copy raw bytes only when target consumers can resolve the unchanged source schema IDs through the same compatible Schema Registry.
- Skip the affected topics.
Masking is unavailable with raw bytes because Kafma cannot reach the fields without decoding the value.
Start and monitor the clone
Select Start Clone after the plan is ready. The execution panel reports topic progress, copied messages, schema actions, masking failures, and elapsed time.
Pause takes effect at the next batch or topic boundary and can resume within the same run. Abort stops further work; records already written remain on the target.
The completion summary distinguishes copied messages from failed or dropped records. Use View target topics to inspect the result.
Interrupted runs and duplicate messages
Data Clone does not remove or deduplicate messages already copied. If you run the same range again after an abort or failure, messages copied before the interruption may be added to the target a second time.
For a clean retry, use a new target topic name. Otherwise, accept the duplicates only when they do not affect the test.
Activity Logs
Each completed, failed, or aborted clone creates one entry in Activity Logs. The entry shows the source and target clusters, message count, topic outcome, and any dropped records.