A receive endpoint for your zfs send.
ZFSRecv is a managed zfs recv service for replication streams. Pipe raw, encrypted, incremental sends to our servers using the tooling you already have in your $PATH. No extra packages, no proprietary formats.
# take a recursive snapshot # zfs snapshot -r tank@2026-08-15T03:00 # raw + incremental, sent straight to ZFSRecv # zfs send -Rw -i @2026-08-14T03:00 \ tank@2026-08-15T03:00 | \ curl -T - \ https://us-sw-01.zfsrecv.com/v1/recv/tank receiving incremental stream 4.71G sent · 2.38G on wire · resumable
It's just zfs send | curl
You get your own destination pool, send encrypted with keys that never leave your possession, and it runs from your cron. We provide the far end of the pipe and get out of the way. If you can replicate to another box on your LAN, you already know how to use ZFSRecv.
Snapshot locally
Keep taking snapshots the way you already do, sanoid, crontab, or by hand. Nothing about your setup changes.
Pipe it to us
Send raw incremental streams over HTTPS to your nearest region. Only compressed, encrypted, changed blocks cross the wire.
Retain & verify
Snapshots are immutable and stay until you destroy them with the API. Monthly scrubs on our metal verify everything.
Every OpenZFS feature you rely on.
No re-implemented "backup engine", just raw ZFS send streams. We terminate zfs recv and store the exact bytes you sent.
Zero-knowledge by default
Raw sends stay encrypted with your encryptionroot keys. We hold ciphertext and nothing else — we literally cannot read your data.
True incrementals
Block-level deltas between snapshots. A 40 TB pool with quiet days moves megabytes, not terabytes.
Resumable streams
Interrupted transfer? We hand back a receive_resume_token. Pick up exactly where you left off.
Immutable retention
Received snapshots can't be rewritten or rolled back from your side. Ransomware on the source can't reach what's already been received.
Pin what matters
Place a named hold on any snapshot and we refuse to destroy it — zfs hold/zfs release semantics, enforced server-side. Pruning everything else is on you or your tooling.
Verified at rest
Monthly scrubs on RAID-Z2 backed pools, checksummed end to end.
Drop in syncoid, or a cron job, or Ansible.
ZFSRecv is a simple HTTPS receive target. Whatever already orchestrates your replication just points at a new host.
- Works with sanoid/syncoid and hand-rolled scripts alike
- Per-pool API keys, no shell access
- Your bandwidth caps and off-peak windows honored via
mbuffer
# replicate every dataset under tank, hourly 0 * * * * syncoid --recursive \ --sendoptions="w" --no-sync-snap \ tank \ https://ca-on-01.zfsrecv.com/v1/recv/tank
Compatibility
| Platform | Raw send -w | Resume -s | Notes |
|---|---|---|---|
| FreeBSD | ✓ | ✓ | Base system or OpenZFS |
| Linux | ✓ | ✓ | OpenZFS DKMS or kmod |
| TrueNAS SCALE/CE | ✓ | ✓ | Just add a replication target |
| Proxmox VE | ✓ | ✓ | Per-pool or per-vmid |
| TrueNAS CORE/Enterprise | ✓ | ✓ | Full backwards compatibility |
| illumos / OmniOS | ✓ | ✓ | Legacy streams accepted |
| macOS (OpenZFSonOSX) | ✓ | ✓ | Experimental |
| Windows (OpenZFSonWindows) | ✓ | ✓ | Experimental |
Pay for what you use, no ingress or exgress fees, no charge per API call.
Incrementals mean you store deltas, not full copies. No per-pool, per-dataset, or per-snapshot costs.
For the server in the basement, or under the desk, and that NAS that holds precious memories.
- Up to 2 TiB stored
- Single receive region
For production where it counts, and teams running real fleets across sites.
- $20/month minimum
- Up to 100 TiB stored
- Optional dual region automated replication
Petabyte-scale cloud or on-prem receive appliances.
- Unlimited stored
- Dedicated / private regions
- SLA + on-call engineers
- Invoice / PO billing