Changing permissions on existing backup source

Dan Stromberg drsalists at
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> 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.


Thanks again.

More information about the rsync mailing list