Transferring data from one FreeNAS rig to another the safe way..

[Chris Moore]

Errors are not corrected. ZFS can’t correct data it can detect and if available it can copy data from other “drive”.

If data was corrupted during wire transfer, it has been copied to new pool corrupted. If new pool is mirror, it will be copied to both “disks”. But ZFS will detect it and let you know.

If (for instance) on your primary ZFS pool some data gets corrupted, ZFS will detect that and copy it from other “disk” (if you have mirror) where data is still ok.

No, that can't be correct. If the source pool has parity blocks, you have redundancy regardless of the destination pool configuration. You shouldn't loose the parity data just because you do a ZFS send to another pool. If that were the way it works, why would anyone use it?
@wblock @danb35

 

[Bostjan]

Data is check summed inside one pool. The integrity of data is checked and kept inside one pool. That is why you have mirror or RAIDZ2 or RAIDZ3. It can copy correct data from other “disk”. If you have just one “disk” in a pool, you cannot recover corrupted data.


When you copy data to new pool, the new pool checks data only inside its pool.


ZFS copies blocks of data, it doesn’t copy files. If some data gets corrupted in a pool ZFS doesn’t know which file is that, it just knows that some data is corrupted.

 

[danb35]

Data is check summed inside one pool.

And there's no checksumming or other integrity verification in transit? You've stated this several times in this thread--do you have a source supporting this?

 

[Johnnie Black]

If some data gets corrupted in a pool ZFS doesn’t know which file is that, it just knows that some data is corrupted.

That's not correct, if there's corruption you can see a list of the affected files, unless corruption is on the Metadata.

 

[danb35]

And there's no checksumming or other integrity verification in transit?

Though I don't have any deep knowledge of the ZFS internals, as I've thought more about this, some points are becoming clearer to me:

• zfs send and zfs recv are both one-way commands--there's no provision for giving or receiving feedback on the data transmitted. Thus, there's no way for zfs recv to tell zfs send, "hey, block 1234 didn't check out--can you re-send?"
• The point above can be shown by the fact that Unix pipes are one-way.
• ssh may (presumably does) have error-checking, however.

Thus, in the case of a "live" replication, zfs send is going to create a clean stream, ssh is going to ensure that it is transmitted correctly, and zfs recv will then write it to the destination.

 

[Elliot Dierksen]

ssh may (presumably does) have error-checking, however.

Not to get to nit-picky on the network side, but it would be TCP which guarantees the delivery since SSH operates over TCP.

 

[danb35]

Does TCP also guarantee data integrity?

 

[Elliot Dierksen]

Yes, via checksums on the packets. Packet reception is verified via acknowledgements.

 

[anmnz]

Yes, via checksums on the packets. Packet reception is verified via acknowledgements.

Although, nit-pickily, SSH provides much stronger integrity guarantees than TCP does. You wouldn't want to rely on sending a ZFS stream over the network without SSH (or similar).

 

[kdragon75]

So, network stuff aside, does zfs send not send the metadata? i.e. checksums? If you can at least get the metadata a scrub would still identify an incorrectly written block. the odds of the received checksum and received corrupted data matching are astronomical. Were talking random coincidental hash collisions.

 

[anmnz]

Yes it does send checksums, so you'd know if a block got corrupted. I don't think it provides any protection against an MITM attack that both modifies a block and recalculates its checksum, though.

 

[kdragon75]

Yes it does send checksums, so you'd know if a block got corrupted. I don't think it provides any protection against an MITM attack that both modifies a block and recalculates its checksum, though.

Thats why your use SSH with keys ;)

 

[anmnz]

Thats why your use SSH with keys ;)

Indeed.