Choose raw OpenZFS sends deliberately for encrypted replication chains

Set stream encryption and key-custody expectations before establishing an OpenZFS replication chain.

Source facts

For encrypted datasets, OpenZFS 2.3 raw send transfers data in its on-disk encrypted form and can operate without loaded encryption keys. A received raw dataset retains the sending dataset’s encryption keys, although its key-location setting may differ. Sending that encrypted dataset without raw mode instead sends unencrypted data, potentially re-encrypted by the receiver with a different key. That change prevents later raw incremental sends to that receiving dataset. Raw and decrypted replication choices therefore affect chain continuity.

Source: OpenZFS 2.3 — zfs send.

Applicability

This applies to OpenZFS 2.3 native-encrypted dataset sends. It addresses stream encryption and incremental compatibility, not every aspect of transport security or destination account authorization.

DSE recommendation

DSE recommends deciding whether the receiver should possess decryption authority before the first transfer. Record raw-mode choice, key custody, key-location expectations, and the intended incremental chain in the replication build sheet. Keep an independent, controlled method of recovering required keys. Avoid changing stream mode as an ad hoc troubleshooting step without understanding its effect on subsequent incrementals. Include destination access and transport protections in the separate replication security review, rather than treating raw mode as the whole design.

Verification

With disposable encrypted datasets, test a full raw transfer followed by an incremental transfer using the intended key state. Verify how the recovered dataset is unlocked by an authorized operator. Retain stream options and key-handling observations without recording private key material in the test evidence.

Official reference

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