Changing permissions on existing backup source
drsalists at gmail.com
Thu Jan 2 19:53:04 MST 2014
First off, thanks much for your suggestions.
On Thu, Jan 2, 2014 at 6:19 PM, Kevin Korb <kmk at sanitarium.net> wrote:
> First, a new column for the old cp -al then rsync on top of it method
> that --link-dest mostly replaced. It is slower since all the hard
> links get made and then some get replaced or deleted but it does have
> the opposite behavior in your new column. Changes to file metadata
> propagate across all backups so that new files are not created for
> simple permission or ownership changes. I didn't suggest this to the
> original question because I assumed that someone using an rsync
> wrapper would find it easier to run a manual chmod than to modify the
> behavior of the wrapper.
Is this mostly of historical interest?
I'm more interested in the new --link-by-hash option. Does this play
a role in saving files with the same hashes but different ownerships
or permissions bits?
> Second, I would suggest some changes to your rsync column...
>> Backs up hardlinks?
> There is no performance difference in using --hard-links. There never
> has been. The difference is in RAM usage. But IMO if you have enough
> hard links to make RAM usage an issue you also have enough of them to
> make disk space an issue without this option.
Adjusted. You're encouraged to look over my changes.
>> Transmits data encrypted?
> You are correct that rsyncd is not an encrypted transmission. The
> authentication is in some hashed communication (I forget which but
> dsniff can't reveal rsyncd passwords) but the content is transmitted
> in the clear. I wouldn't bother mentioning rsh anymore. It shouldn't
> even be available on a modern system.
I added a brief note that rsh is deprecated.
>> Permissions / ownership
> The requirement for root access to the backup server is no longer
> true. This was solved by --fake-super. When in effect it stores all
> files with an unprivileged owner and generic permissions. The real
> data is then stored in file extended attributes. Root access is
> required only on the backup client (so it can read all files and
> restore files to arbitrary ownerships).
Thanks, I was not aware of --fake-super.
> I would also mention that many of the other weaknesses can be handled
> at the filesystem level with newer systems such as ZFS but that is
> another discussion and of course it would apply to the other non-tape
> based backup systems too.
More information about the rsync