rsync --link-dest, --delete and hard-link count

[Paul Slootman]

On Fri 05 Feb 2010, Andrei_r20 wrote:
> 
> So what I am thinking of doing now is:
> 
> The fist backup is done to an empty destination. Than, each following backup
> will be done to a freshly created empty dir with current date as name but
> with --link-dest option pointing at the previous (latest) backup directory.
> 
> Like this, if I understand right, each new backup will be hard-linked to the
> previous backup, and only the new changes will be stored separately.

Correct.
It's also basically how dirvish works, which automates the process for
you. (www.dirvish.org)

> Here are my questions:
> 
> 1) Now, what happens if I use the --delete option with --link-dest, and some
> files are deleted on the source? Are they going to be deleted from all of
> the hard-linked previous backups (thus corrupting my previous backups) or
> the missing file on new backup just wont be hard-linked to previous backup
> existing files (so they will just appear not to be there)?

--delete when rsyncing into an empty tree is basically a no-op.
The --link-dest directories will not be changed.

> 2) If I understand right, each new backup will increase the hard link count
> of all unchanged files by one. So after a five year period I will have the
> hard link count increased by 17. What happens if I now recover the latest
> backup back to the source? Will the hard link count go back to what it was
> on the source when the backup was done or will it stay the same (incremented
> by 17)?

I think I don't really understand the question, or you really don't get
how hard links work :-)
The link count is simply a function of the local filesystem and
operating system. If you use rsync to copy a tree (to whatever
destination), using the appropriate options you will restore all of the
metadata belonging to the files as well as the data of the files.
However, the link count doesn't count as metadata.
Otherwise you would have the same problem when rsyncing to the backup
system as well: the source file has one link, and you have >1 links in
your backup tree.

> Is this new method better than the one I firstly proposed, or it just
> introduces unnecessary risks?

The method with tar and untar etc. sounds much more complicated and
prone to error. You could, of course, still create tar files of the
trees for off-site storage or whatever if you need to. Just don't remove
the tree afterwards.


Paul