1) The article's use case is explicitly bootable images.
2) No, most of us don't "hope for the best" with imaging, but would like to actually achieve a reasonable level of confidence. If your approach to data integrity is "you probably won't notice corruption", you don't have an approach to data integrity.
initrd with native OverlayFS kernel support is very versatile. ;)
Yet the btrfs, CephFS, or ZFS all have snapshot syncing tricks that make state mirrors far more practical and safe to pull off. =3
Block level copies of boot volumes is high risk, because they are almost exclusively mounted in RW mode via label or guid.
Pretty common problem for someone to do their boot drive, reboot and have it mount their backup.
If you are using iSCSI or anything with multipathing this can happen even without a reboot.
I know that block level copies seem like a good easy solution. But several decades in the storage admin to architect roles during the height of the SAN era showed that it is more problematic than you expected.
To be honest, full block level backup of a boot volume is something you do when the data isn't that critical anyways.
But if you use case requires this and the data is critical, I highly encourage you to dig into how even device files are emitted.
If you are like most people who don't have the pager scars that forced you to dig into udev etc... you probably won't realize what appears to be a concrete implementation detail is really just a facade pattern.
1) The article stated that using bootable images for backup was a preference. That doesn’t invalidate asking whether that’s an ideal preference
2) Arguing that it might be better to avoid such methods because of possible problems with data integrity isn’t a lack of an approach to data integrity.
I'm also doing bootable images. But the old way with a r/o initrd, that does then mount the rootfs.
The rootfs can be mkfs and rsynced nicely.
That said, the article is awesome and the idea very clever.
But more to do streaming replication that dd catchup.