Retain and resume interrupted OpenZFS receives with an explicit policy

Give retained partial receives a restart decision, owner, and separate completion check.

Source facts

OpenZFS 2.3 receive can preserve partially received state when its resumable option is selected. Interruptions can include a broken stream, checksum error, process termination, or unclean shutdown. The receiving dataset exposes a receive_resume_token that can be supplied to send to continue the transfer. This requires the extensible_dataset pool feature. A separate abort operation deletes saved partial state. Resumable receive therefore provides a controlled recovery path, but retained partial state still needs ownership.

Source: OpenZFS 2.3 — zfs receive.

Applicability

This applies to OpenZFS 2.3 resumable receive. It addresses interrupted-transfer handling and does not mean an incomplete receive is already an accepted, usable recovery snapshot.

DSE recommendation

DSE recommends deciding whether unattended replication should retain partial state and defining who reviews an interrupted transfer. Record the source snapshot, destination dataset, token location, and restart or abort decision without exposing unrelated credentials. Before deleting partial state, confirm whether resuming the existing transfer is still intended. Keep incomplete receives visible in monitoring so an old interruption is not mistaken for a current recovery point. Use a separate completion and application-recovery check after transfer resumes.

Verification

Interrupt a disposable transfer, inspect the saved state and token, and resume it using the documented mechanism. Compare the completed destination with the intended source. Rehearse abort on a separate partial transfer and confirm monitoring reports the difference between retained partial state and an accepted completed snapshot.

Official reference

OpenZFS 2.3 — zfs receive. Reviewed October 15, 2026.