36 ms·

Any suggestions? I looked for a while but couldn't find anything so I adapted this script which a guy on IRC linked me to.

mbreese 11y ago
I don't have any suggestions, and I don't suspect that are anyone else will either. Why? Because ZFS backup and mirroring is going to be so system specific, that it is better left to one-off scripts written by the admin. For example, your zfsu tx script - if I'm reading it right, you assumes that root can ssh from the backup server to the target server without a password. This is rarely the case (and I'd argue that it should never be the case). But, this is something that works on your systems... The last time I had to setup ZFS snapshot mirroring, I did something similar, but it was so specific to my setup that it wasn't worth making it into a package that others would use. Each of the backup targets had a "backup" user with a password-less SSH key that could execute exactly one command with sudo (zfs send). That's not exactly something that lends itself to a simple install script. Instead, it probably would be more beneficial to write a blog post somewhere that detailed why you needed these scripts, and the one or two magic lines in them that got the job done. The most I remember finding were the original Sun/Oracle ZFS docs.
- feld 11y ago
  I disagree completely. And I really don't trust someone to write zfs replication scripts on their own that can properly handle differentials automatically or the new resumable-send feature which this guy's tool doesn't even mention because he probably doesn't even know it exists. Listen, this is hard and it sucks that there isn't a tool that comes with zfs to do this for you. But there are scripts that have been in production for years that have never failed. Scripts that are currently pushing hundreds of GBs per hour across the internet and recovering gracefully from failures. Use them. They work. They're even authored by zfs experts.
  - mbreese 11y ago
    Yes, there are best-practices that should be used and advertised. But there is no way to have a generic tool that will work in some reasonable percentage of environments. Yes, it's hard, but it's better to teach people how to manage it instead of giving them an unmodifiable tool and just say "here - use this". Telling them "here - do it like this", is much better.

mbreese 11y ago

I don't have any suggestions, and I don't suspect that are anyone else will either. Why? Because ZFS backup and mirroring is going to be so system specific, that it is better left to one-off scripts written by the admin. For example, your zfsu tx script - if I'm reading it right, you assumes that root can ssh from the backup server to the target server without a password. This is rarely the case (and I'd argue that it should never be the case). But, this is something that works on your systems... The last time I had to setup ZFS snapshot mirroring, I did something similar, but it was so specific to my setup that it wasn't worth making it into a package that others would use. Each of the backup targets had a "backup" user with a password-less SSH key that could execute exactly one command with sudo (zfs send). That's not exactly something that lends itself to a simple install script. Instead, it probably would be more beneficial to write a blog post somewhere that detailed why you needed these scripts, and the one or two magic lines in them that got the job done. The most I remember finding were the original Sun/Oracle ZFS docs.

feld 11y ago
I disagree completely. And I really don't trust someone to write zfs replication scripts on their own that can properly handle differentials automatically or the new resumable-send feature which this guy's tool doesn't even mention because he probably doesn't even know it exists. Listen, this is hard and it sucks that there isn't a tool that comes with zfs to do this for you. But there are scripts that have been in production for years that have never failed. Scripts that are currently pushing hundreds of GBs per hour across the internet and recovering gracefully from failures. Use them. They work. They're even authored by zfs experts.
- mbreese 11y ago
  Yes, there are best-practices that should be used and advertised. But there is no way to have a generic tool that will work in some reasonable percentage of environments. Yes, it's hard, but it's better to teach people how to manage it instead of giving them an unmodifiable tool and just say "here - use this". Telling them "here - do it like this", is much better.