Can You Replicate Encrypted ZFS Datasets Without Decrypting Them?

Yes. A raw send can replicate encrypted blocks and encryption metadata without loading the dataset key on the receiving system.

The decision matters when an off-site NAS should store a ZFS replica but must not possess plaintext keys. The two competing states are raw encrypted send and receive and non-raw send, incompatible features, or key-handling mistake. Begin with a saved configuration and disposable data, observe one branch at a time, and stop if the test expands data-loss, permission, or availability risk.

Define the Conditions Behind the Raw Encrypted Zfs Replication Decision

Record the environment before changing anything: software and firmware versions, device identities, mount or network path, free space, permissions, and the observable symptom. The baseline must preserve enough detail to reproduce an off-site NAS should store a ZFS replica but must not possess plaintext keys.

The first candidate is raw encrypted send and receive. The second is non-raw send, incompatible features, or key-handling mistake. The current raw encrypted ZFS send defines the mechanism or command boundary used in the test; it does not replace observation from this specific home server.

Write the acceptance condition and stop condition before running the discriminator. A pass must change the evidence predicted by one branch while leaving unrelated services unchanged; a fail must return the system to the saved state rather than trigger a chain of speculative fixes.

Test the Claim Without Lowering the Original Requirement

Use this discriminator: send a disposable encrypted snapshot with raw mode, receive it unloaded, inspect encryption properties, then restore on a key-holding system. Keep workload, client, path, file set, and timing constant so the result is attributable to the changed variable.

Use ZFS encryption behavior to select the field that can actually separate the branches, then capture its timestamp, exit status, error text, device or snapshot identity, latency, transferred bytes, permissions, and recovery state. A clean command exit is not enough when identity, durability, or application state is the claim under test.

Repeat the test once after a restart, reconnect, remount, or cold cache when that event is part of the original condition. If the first run is destructive or the environment cannot be restored, stop and reproduce on a disposable copy instead.

zfs send -w pool/secure@snap | ssh backup zfs receive backup/secure

Interpret Pass, Fail, and Exception Results

PASS: the receiver stores and snapshots the dataset while plaintext remains unavailable until the key is loaded elsewhere. Record the exact version, identity, and workload that passed so the conclusion stays conditional rather than becoming a universal claim.

FAIL: the receive side can mount plaintext, properties are transformed unexpectedly, or incremental lineage breaks. A fail does not automatically prove the opposite branch when network, memory, permissions, or source consistency can influence both; isolate those shared dependencies before escalating.

EXCEPTION OR AMBIGUOUS RESULT: destroy only the disposable replica and correct raw-send plus key custody before production. Preserve logs and do not run repair, prune, destroy, repartition, or recursive ownership commands until a recoverable copy exists.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Confirm the Decision Under the Original Workload

Apply the action matched to the observed branch, then repeat the original condition rather than a reduced substitute. The decision holds only when the receiver stores and snapshots the dataset while plaintext remains unavailable until the key is loaded elsewhere across two cycles or the relevant reboot, sleep, interruption, or load transition.

Use the immutable backup windows to check the nearest dependent workflow, but keep the original trigger unchanged. Unrelated datasets, shares, containers, users, and recovery points must retain their previous access and timing.

The stop boundary is explicit: if the receive side can mount plaintext, properties are transformed unexpectedly, or incremental lineage breaks, return to the last verified configuration, retain the evidence, and escalate to a deeper platform or hardware test only when the branch is repeatable.

After the target result holds, compare it with the replica verification so the fix does not move risk into a neighboring service. A successful target test with a new backup, identity, timeout, or availability failure is still a failed change.

FAQ

For raw encrypted ZFS replication, the remaining searches usually concern does the destination need the encryption key, can raw sends be incremental, and are dataset names and sizes hidden. The answers below keep those edge cases separate from the primary decision.

The acceptance boundary does not move: the receiver stores and snapshots the dataset while plaintext remains unavailable until the key is loaded elsewhere. If a follow-up condition changes the filesystem, identity, network path, or application version, repeat only the discriminator affected by that change.

Stop broadening the experiment when the receive side can mount plaintext, properties are transformed unexpectedly, or incremental lineage breaks. At that point, destroy only the disposable replica and correct raw-send plus key custody before production; preserve the evidence before escalating to the platform, storage, or hardware owner.

Does the destination need the encryption key?

Not for raw receipt and storage; it needs a key only to load and access plaintext.

Can raw sends be incremental?

Yes when snapshot lineage and feature compatibility are preserved.

Are dataset names and sizes hidden?

No. Raw encryption protects contents and certain metadata, not all operational information visible to the pool administrator.

For raw encrypted ZFS replication, the practical answer remains conditional: the receiver stores and snapshots the dataset while plaintext remains unavailable until the key is loaded elsewhere. When the receive side can mount plaintext, properties are transformed unexpectedly, or incremental lineage breaks, destroy only the disposable replica and correct raw-send plus key custody before production; a partial success that cannot survive the original workload is not compatibility.