-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/02/2014 09:53 PM, Dan Stromberg wrote:
> First off, thanks much for your suggestions.
...
>> 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?
I am also interested in that but it is not currently in mainstream
rsync. Also, at work, I have switched to rsync backups without
- --link-dest using ZFS subvolume snapshots so this could only benefit
my personal usage at home so I am less motivated to look into it.
It is true that the old cp -al method is rarely used anymore but it is
still certainly available. Also, the overhead of pre-making all the
hard links really isn't that much more than making most of them while
rsync is running. I actually resisted the switch from cp -al to rsync
- --link-dest for a while because the performance change wasn't that big
and because I didn't want to waste disk space on metadata changes.
Then I had issues where customers would change permissions, complain
that something broke, then claim they didn't make any such changes.
Suddenly it was worth having an extra copy of a php script just to
show what the permissions were yesterday.
Also, you can still get a performance advantage out of cp -al...
If you are running nightly backups in a window with most of the day to
spend on other things you can use that most of a day idle time to do
all the cp -al runs to prime the next backup. Now when rsync runs it
doesn't have to make any link calls during its execution. This makes
the rsync run and therefore the impact on the server being backed up
much smaller.
There was also someone on here a while back who was using --link-dest
but was not purging old backup trees. Instead they were re-using the
oldest backup as the target. This has some tricky implications that
need to be understood and analyzed but it worked for that person and
avoided long cycles of rm -rf on massive trees of hard links to purge
old backups (the reason my company went to BTRFS and then ZFS).
- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
Kevin Korb Phone: (407) 252-6853
Systems Administrator Internet:
FutureQuest, Inc. ke...@futurequest.net (work)
Orlando, Florida k...@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/
iEYEARECAAYFAlLGKHQACgkQVKC1jlbQAQcNDgCeI1zTfLLpqZra09uMI6ipN2Dp
d6gAmwagk1xSO4ZJdZm90VWJimbhCP1p
=ubjd
-----END PGP SIGNATURE-----
--
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
