oetiker / znapzend

zfs backup with remote capabilities and mbuffer integration.
www.znapzend.org
GNU General Public License v3.0
613 stars 137 forks source link

Assorted Readme/znapzendzetup docs improvements #350

Closed jimklimov closed 6 years ago

jimklimov commented 6 years ago

Revised after some troubles I had during my first ever setup - hopefully helpful to other newcomers.

coveralls commented 6 years ago

Coverage Status

Coverage remained the same at 85.901% when pulling 67ac09d09bd14bdb56f06a44c551d2409be6a81e on jimklimov:readme-improve into ed7074ee7506f23816ddbb8255a7f0251401ec7b on oetiker:master.

jimklimov commented 6 years ago

This PR should also address parts of #335 and #347 issues.

One thought I had while writing this (but did not have time to check in sources): the receiving side might be lagging, as well as the sending side, while zfs send or zfs recv is spinning on some lock or very busy doing its work. When I scripted large transfers over network (ssh, netcat, etc.) I had mbuffer running on both sides - so even if both zfs'es were slow, the two buffers still did not waste time transferring data over the network.

Does znapzend support such setup? Should there be options for it (path and config for mbuffer on DST #X)? Does the ability to configure mbuffer+port somehow cover this, with or without SSH (docs are still not clear, and who/how starts the networked daemon(s) for mbuffer)?

oetiker commented 6 years ago

thanks