Okay, thanks guys. It seems that -H sould be included by default, unless
there is a specific reason not to.
Maybe the rsync -a option switch should include hard links by default.
Rsync tutorial type information usually lists generic examples such as:
sudo rsync -avz <source> <destination>
and not addressing the subject of hard links.
And you weren't kidding about the number of entries in /var/lib/yum/yumdb.
Wow!
On Wed, Feb 11, 2015 at 12:01 PM, Les Mikesell <lesmikesell@xxxxxxxxx>
wrote:
> On Wed, Feb 11, 2015 at 11:51 AM, Gordon Messmer
> <gordon.messmer@xxxxxxxxx> wrote:
> > On 02/11/2015 09:02 AM, Francis Gerund wrote:
> >>
> >> When using rsync to backup and restore, when should and when should one
> >> *not* include hard links (by using the -H option switch)?
> >
> >
> > It's probably too site or application specific to give any general
> advice.
> >
> > Run this command across the filesystem you're going to back up:
> > find /path -type f -links +1
> >
> > All of the files listed in find's output have multiple links, and will
> > benefit from using -H.
> >
> > The cost associated with -H is that rsync has to keep a table in memory
> of
> > all of the inodes and paths that it processes. A large filesystem can
> cause
> > rsync to consume a lot of RAM. If sufficient RAM is available, I would
> > always recommend -H.
>
> I don't know about the actual implementation, but wouldn't it really
> only need to track the inodes/paths of the files with >1 link?
>
> --
> Les Mikesell
> lesmikesell@xxxxxxxxx
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
