Changing permissions on existing backup source
Kevin Korb
kmk at sanitarium.net
Thu Jan 2 19:19:14 MST 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Interesting list. I have a couple of suggestions I can offer...
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.
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.
> 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.
> 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).
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.
On 01/02/2014 09:05 PM, Dan Stromberg wrote:
> On Wed, Jan 1, 2014 at 10:09 AM, Charles Marcus
> <CMarcus at media-brokers.com> wrote:
>> If I change the permissions on the source maildirs, will this
>> cause everything to be transferred again? Meaning, will rsync see
>> everything as 'modified', thus creating a new copy of the entire
>> mail store on the backup target?
>>
>> Or will the newest backup directory just reflect the new
>> permissions for the hardlinked files, without making new copies
>> of everything?
>
> Come to think of it, this makes a good row in my backup software
> comparison chart... Added:
>
> http://stromberg.dnsalias.org/~strombrg/backshift/documentation/comparison/index.html
>
> HTH
>
- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
Kevin Korb Phone: (407) 252-6853
Systems Administrator Internet:
FutureQuest, Inc. Kevin at FutureQuest.net (work)
Orlando, Florida kmk at sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLGHiEACgkQVKC1jlbQAQdpMwCfaugPWjT2g3cp4LKwEUwDFuT1
/zYAoI6lRpYVobKzNoFH8TdTjObxYXE4
=DEk9
-----END PGP SIGNATURE-----
More information about the rsync
mailing list