I answered in another comment on that question. The main point of course is not a language. ZFS incremental snapshots and its send/receive are great, but my task is to create binary identical image of hard drive with bootloaders, partitions and so on. I have got SSD that can breake and slow USB connected HDD. I want to sync them several times a day and be able to trivially switch them in the case of failure. ZFS is only a filesystem. I need to prepare harddrive with bootloaders to use ZFS send/receive. I do not want it. Raw dd is what is needed, but it is slow -- the only reason this utility is written.
> ZFS incremental snapshots and its send/receive are great, but my task is to create binary identical image of hard drive with bootloaders, partitions and so on.
If you use UEFI, bootloader is just a normal file on a normal (FAT) partition so no special magic is needed, but fair enough.
ZFS typically handles partitions its own way so no need to sync that.
But really: If you just want to keep to full drives in sync, at block-level so one can at any point be a stand-in replacement for the other, it sounds like what you want is RAID0. Isn't that what you want?
And with UEFI you can boot those RAID-volumes, even though they are soft-raid volumes.
Not saying your need doesn't exist, but that existing solutions which are more standardized and requires less administration seemingly already exists.
Forgive me, it's Monday morning and I haven't yet had my coffee, but it sounds like you're describing a block-level copy between two drives, something which RAID0 is most definitely not.
Unless I'm misinterpreting, I think you were going for RAID1.
It should be enough to copy partition table and boot loader only once. After that, it's safer and probably faster to backup with consistent btrfs/zfs snapshots. Copying raw blocks from a writable mounted filesystem will lead to inconsistent backups.
Agreed that it is preferred way, after raw dd with unmounted filesystem. But I need to be prepared for that: I am a human, I can forget some steps. Here command takes only two arguments (src and dst) -- simplicity is reliability against humand mistakes. Some data will be corrupted, but with journaling filesystems or something like ZFS this is not dangerous (unfinished transactions will be ignored).
