<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 24, 2022, 11:55 Ken D'Ambrosio <<a href="mailto:ken@jots.org" target="_blank" rel="noreferrer">ken@jots.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I use the btrfs-send (which, of course, is modeled after zfs-send)... <br>
except, I kinda don't. And this isn't a dig at btrfs (or ZFS), but just <br>
paranoia: I'm afraid that, if there were corruption on the source FS, <br>
using a FS-specific/replicating tool to do the data transfer might bring <br>
over whatever corruption was on the source in the first place. </blockquote></div></div><div dir="auto"><br></div><div dir="auto">Not a merely theoretical concern. I saw this happen. </div><div dir="auto"><br></div><div dir="auto">Our British cousins fielded the same application we did, but since their geographically dispersed data centers were within the radius supported for syncronous SAN replication , they opted for that from primary cluster to Disaster cluster. We were replicating much further so used semantic replication stateside $BigCorp (log forwarding for DB, file level for normal volumes), even though it had a chance of losing the last transaction in flight. The DB driver made an error and wrote garbage 🗑, which corrupted DB indices, DB panicked. SAN dutifully copied the block level writes to alternate site, so that panicked also. Oopsie. They had to restore Prod last backup onto UAT system (and recreate all logged transactions... a day of market!) to return to service. It was a bad week.</div><div dir="auto"><br></div><div dir="auto">I much prefer semantic (vs block/bit) replication. </div><div dir="auto"></div></div>