rsync - Feb 2024 - [Bug 2294] Detect renamed files and handle by renaming instead of delete/re-send

https://bugzilla.samba.org/show_bug.cgi?id=2294

--- Comment #39 from andy <andy at digitalsignalperson.com>
---
> This feature request is so old it has lost relavence because btrfs/zfs/etc
are more optimal backup solutions than rsync.
Funny I am doing exactly this, but I came to rsync looking for a backup for
when ZFS fails. Many consider zfs/btrfs/snapshots as "not a backup".
There are
many things that can go wrong that you will need real backups to save you:
- accidentally deleted pool/datasets/snapshots
- bug in replication tool
- user error
- ZFS bug

It should be considered a certainty that one of those will happen at some
point, and the ZFS snapshots won't save you.
> With zfs one can even have encrypted backups without the backup server ever
seeing the key or un-encrypted data.
I love this idea, but in practice I'm finding there is significant risk with
the state of ZFS encryption. There are so many active bugs related to
encryption. I'm in the middle of implementing a replication system based on
raw
encrypted snapshot replication between multiple systems, trusted and untrusted.
But the new bugs I've run into along the way, along with the previously
known
ones, makes me really feel the need for a solid non-ZFS filesystem backup. And
also a low complexity tool, not dependent on complicated replication
tools/scripts.

In looking for rename/move solutions with rsync, one issue I can foresee with
inode tracking is that I find it is very common to cross filesystem boundaries.
Anything tracking inodes would need to track the device as well, though the
device number from the stat struct doesn't seem to be enough in the case of
ZFS
to trace back to what filesystem it actually comes from. 

Reading the unison documentation, it seems that for linux they track the combo
of inode & last modification time to detect moves/renames. I wonder if some
kind of collision is possible under a rare multi-filesystem edge case. Inodes
aren't unique across multiple filesystems.

Restic is another option that handles moves/renames/dedup automatically, just
at the cost of CPU time for encrypting/hashing. Probably worth considering borg
and friends at that point.

Well, maybe the cost of rsync's inefficiency here is worth it's
simplicity. But
it would be a great feature to have.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.