With zfs send -w the blocks leave your pool exactly as they sit on disk: still
encrypted, still compressed, never decrypted in flight. The receiving side stores
ciphertext it has no key for.
What we can see
Raw streams still carry enough metadata for ZFS to reconstruct the dataset tree, so the endpoint necessarily knows structure without knowing contents.
| Visible | Not visible |
|---|---|
| Dataset names and hierarchy | File names and directory contents |
| Snapshot names and timestamps | File data |
| Logical and physical sizes | Properties marked sensitive |
| Encryption root and key GUID | Your wrapping key or passphrase |
Keep your keys
We never receive a key. If you lose your wrapping key, the pool’s contents are
unrecoverable. by both you us alike. Store a break-glass copy of your key
offline, somewhere you trust.
Requirements
- The dataset must already be encrypted at rest on the sending pool.
-wdoes not encrypt anything itself; it declines to decrypt. - Sender and receiver must agree on feature flags. Raw sends fail if the receiving pool lacks a feature your stream depends on, our endpoints track OpenZFS release and support all of the latest features.
- Increments must chain from a snapshot that was itself sent raw. Mixing raw and regular sends in one chain is rejected.
Verifying a chain
Every snapshot’s GUID is included in GET /v1/detailed
alongside its space accounting. Compare GUIDs across an incremental chain the same way
zfs get guid would locally, to confirm nothing is missing or out of order before you rely
on it for a restore.