https://bugzilla.samba.org/show_bug.cgi?id=2294
--- Comment #39 from andy <a...@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. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
