deduplication on shapshot receival

[slavanap]

I have a question regarding commands parameters, because it's not clear from the documentation.

I have a huge pool build up with backup snapshots for years. It has one encrypted dataset, root is not encrypted.

The pool is stored on a separate disk, no raid or anything, I utilize ZFS snapshots and compression capabilities for backup purposes only.

I want to rewrite the entire pool and dedup its contents with support of dedup special dev on SSD.

Questions:

1. How to send first snapshot of encrypted dataset to a new pool, preserving the encryption and dedup and recompress its data on the fly. (so -w option is not feasible; what are the options?)
2. How to dedup and recompress each of snapshots I send over after the initial one (presumably with -I option)? Is it guaranteed that dedup and recompression will happen automatically on an unencrypted dataset.
3. If I change (increase) recordsize to 1M, will this option be regarded on receive and blocks that originally had recordsize=128K will be correctly concatenated?

Answers:

1. zfs recv -o encryption=aes-256-gcm -o keyformat=passphrase -o keylocation=file:///testfile -o dedup=verify -o recordsize=1M -o compression=zstd-10 -o atime=off -o relatime=on main/test2
   then

2. sudo zfs send --large-block -I main/test1@snap{,2} | sudo zfs recv -F main/test2

3. do not change recordsize on test1 because if will reduce de-duplication effect.

[amotin]

If you are using encrypted replication, then you can't change anything, receive side blocks will be exactly the same as source, may only participate in dedup, since it works on different layer. If replication is compressed but not encrypted, receiving side may have different indirect block sizes and few other things, but block will be the same, including original compression. If replication is neither compressed nor encrypted, then receiving side may have different compression settings, but block sizes should remain the same unless you are looking for troubles.

[slavanap]

@rincebrain thanks, this one worked flawlessly
zfs recv -o encryption=aes-256-gcm -o keyformat=passphrase -o keylocation=file:///testfile -o dedup=verify -o recordsize=1M -o compression=zstd-10 -o atime=off -o relatime=on main/test2

[slavanap]

but as I've noted from previous answer, recordsize does really nothing on receive, so can be omitted for backup storage, but kept intact for sending size.

[rincebrain]

It applies for future writes, though if this is archive-only storage, that only matters if you ever restore it, potentially.

dedup=verify is also by far the slowest possible combination - doing sha256, and then a bytewise comparison anyway, and only deduplicates within the same encryptionroot anyway.

If you're going to use dedup (and you shouldn't, in almost every case), and you're going to use verify (same statement), you should probably opt for the fastest thing it'd let you use verify with, which would be edonr. Failing that, skein (2.1) or blake3 (2.2) would be the fastest thing you don't have to use verify with.

(Of course, if you change this, things after you change it won't deduplicate against things before, so you'd probably want to re-receive the backup entirely...)

[slavanap]

That's good to know about edonr. Thanks! My primary goal is to have the most compact cold storage of about 18TB worth of data accumulated for 3 years, which could have potential hash collisions in files, has same recordsize, and occurrences of file copying within 1 dataset.

[rincebrain]

If you're accidentally colliding a salted nontrivial hash, I have questions, and I suspect various TLAs have job proposals.