3 ms·

Just curious, how do you sync file ownership and permissions when going to a ZFS target server with a non privliged account? Or would you have all the files on

Just curious, how do you sync file ownership and permissions when going to a ZFS target server with a non privliged account? Or would you have all the files on the target owned by the user ID accessing the target server, then keep the metadata (owner/mode/SE Linux attributes / ACLs, etc) in a separate log file? And do you typically turn on ZFS compression? I tried that years ago with ZFS under Linux, but had major slowdowns after a while. But I'm sure it has improved quite a bit in more recent years. Also how does ZFS stack up against Btrfs in your experience? But for a direct-to-cloud backup, the way you do it is really great -- to me it is much easier than messing with things like S3 buckets and similar technoligies.

rsync 6y ago
Well, if you are using a sophisticated tool like restic or borg or duplicity, the file attributes are bundled up into the encrypted chunks and all is well. However, if you are using plain old rsync, you can use the --fake-super command line switch to maintain those attributes and I believe rsync.net customers are using that successfully. Yes, you are correct - in the old days (2001-2010 or so) we maintained a pair of "permission scripts" which allowed customers to dump all their attributes to a file and then reapply it later. Again, --fake-super seems to "fix" all of this. Generally speaking, you should always enable ZFS encryption. It improves many aspects of ZFS behavior and performance - not just space usage. Unless you have very bizarre workloads or hardware, I think that in 2020 there is no reason to not enable compression. Deduplication is another story and is very expensive to maintain - rsync.net has never run de-dupe on any systems. We (rsync.net) and I (personally) have zero experience with btrfs ...
- onetimertwo 6y ago
  That shold be "you should always enable ZFS compression"?
  - rsync 6y ago
    Oh, sorry - yes, you are correct: s/encryption/compression

rsync 6y ago

Well, if you are using a sophisticated tool like restic or borg or duplicity, the file attributes are bundled up into the encrypted chunks and all is well. However, if you are using plain old rsync, you can use the --fake-super command line switch to maintain those attributes and I believe rsync.net customers are using that successfully. Yes, you are correct - in the old days (2001-2010 or so) we maintained a pair of "permission scripts" which allowed customers to dump all their attributes to a file and then reapply it later. Again, --fake-super seems to "fix" all of this. Generally speaking, you should always enable ZFS encryption. It improves many aspects of ZFS behavior and performance - not just space usage. Unless you have very bizarre workloads or hardware, I think that in 2020 there is no reason to not enable compression. Deduplication is another story and is very expensive to maintain - rsync.net has never run de-dupe on any systems. We (rsync.net) and I (personally) have zero experience with btrfs ...

onetimertwo 6y ago
That shold be "you should always enable ZFS compression"?
- rsync 6y ago
  Oh, sorry - yes, you are correct: s/encryption/compression