ZFS Receiving deduplicated stream error

[von_Gaden]

Hi!

I have a strange issue trying to backup / replicate a ZFS pool.
The pool has some filesystems and daily snapshots for each filesystem (created using sysutils/zfsnap). I am trying to replicate it on another pool like this:

# zpool import -R /altback backz
# zfs create backz/srv1z
# zfs send -DRv srv1z@2016-09-30_00.00.00--1m | zfs receive -Fdvu backz/srv1z

The verbose output shows that first snapshot is being sent and at some point I get an error:

receiving incremental stream of srv1z@2016-09-02_00.00.00--1m into backz/srv1z@2016-09-02_00.00.00--1m
cannot receive incremental stream: invalid backup stream

If I omit -D (deduplicate) everything works fine.
I expect that deduplicating will spare a lot of space on my backup device.

Similar issue is described in some ZFSonLinux articles.
My system is the last update of FreeBSD 10.3-Release, AMD64

Did someone noticed such problem with sending/receiving deduplicated replication ZFS streams?

 

[phoenix]

The -D option to zfs send only dedupes the stream in transit, the receiving system still writes out a non-dedupe filesystem. Basically, it allows you to send less data over the pipe/network/whatever, but won't save you any disk space.

And, unless you have lots of RAM, and lots of disk I/O available, and data that you know is dedupable, you really DON'T want to enable ZFS dedupe. Just ... don't. It's not worth it in the long run.

 

[von_Gaden]

Thank you very much for your answer!
I was unaware that the received stream won't be deduplicated. Knowing zfs receive options I'm sure if it doesn't replicate the sent stream exactly, it should not be possible to receive and write a deduplicated stream. I thought the receiving stream is exactly the same as sent, so sending deduplicated stream receives also a deduplicated one.

I'm aware of the penalty for using deduplication in live, working environment. No mater of RAM quantity I'd never use deduplication in filesystem properties. But I think it might be useful for backup purposes - less traffic and less space.

Well, this doesn't clarify my problem with receiving the stream. It might be of importance that the sent set of filesystems and snapshots is not deduplicated on the pool. The send/receive of dedup stream might work just for a given filesystem or snapshot, I should test it and report.