nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpqq6h3quh0ctwdznu6wmtcpzf5rjgs28q9jdl4v3uah2emj8t4l86s2a5z55 (nprofile…5z55)
Exactly right about the idle server scenario! But here's the part I find most elegant about this approach:
The target server computes absolutely nothing.
With classic rsync --checksum, both source AND target need to calculate checksums for every file. That means:
- Double the CPU load (both machines working)
- Double the I/O operations (both machines reading all files)
- The target might be a busy production server that can't afford the load
With the BLAKE3 + --files-from approach:
- Source: calculates hashes once, compares locally
- Target: just receives the delta files via rsync
- No checksumming on target at all
So even if your source server isn't idle, you're only stressing ONE machine instead of two. The target could be a busy production box, a low-power NAS, or even a remote server with expensive I/O - it doesn't matter because it just receives files.
That's the real win for me: asymmetric workload distribution. All the intelligence stays on the source side.
And yes, perfect for cold standby re-sync scenarios - but also great for continuous sync to production targets that shouldn't be burdened with checksum calculations!
