FYI, while these block level methods do have a use case, parallel rsync and other file level tools are far safer and often faster with less additional load on the disk.
Duplicating the OS/FS behavior hits the decidable problem and you just hope for the best with block level, often you won't notice corruption either.
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.
Rice–Shapiro theorem.
The number of writers on a typical OS means that you can't depend on a pathological case.
I suppose you could reduce it to Rice's theorm and how threeTM is undecidable but remember it generalizes to even total functions.
Just goes back to the equivalence of two static programs requires running them, and there is too much entropy in file operations to practically cover much of the behavior.
When forced to, it can save you, but a block level copy on a live filesystem is opportunistic.
Crash consistency is obviously the best you can hope for here, so that and holes in classic NFS writes may be a more accessible lens on the non-happy path than my preferred computability one.
The guid being copied and no longer unique problem I mentioned below is where I have see people lose data the most.
The undecidable part is really a caution that it doesn't matter how smart the programmer is, there is simply no general algorithms that can remove the cost of losing the symantic meaning of those writers.
So it is not a good default strategy, only one to use when context forces it.
TL:DR it is Horses for courses
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.