Craig Barratt wrote at about 23:06:25 -0800 on Sunday, November 9, 2008:
> Jeffrey writes:
>
> > Looking at the code and the structure of the storage and attrib files,
> > it doesn't seem like there is any way for BackupPC to record and
> > restore hard links.
>
> Not true. Hardlinks are stored without using hardlinks.
Thanks good to hear!
>
> Hardlinks are stored just like symlinks. The attribute type is
> BPC_FTYPE_HARDLINK and the contents of the file is the path of
> the file being linked to.
>
> For example, if there are 4 links to a file, one instance (it
> doesn't matter which - depends on the Xfer Method) will be stored
> as a regular file. The remaining three instances will be stored
> as type BPC_FTYPE_HARDLINK with pointers to the first file.
Dohhh... for some reason, I kept looking at the "first" file which of
course had a standard attrib file with type=0.
>
> Note that this is independent of the hardlinks used to de-duplicate.
>
> There is one subtlety with rsync: it also needs to remember if a
> regular file is the target of (other) hardlinks so that the correct
> file list can be generated during a restore. This is done by using
> an extra bit in the file's mode stored in the attrib file.
Based on this, I can understand why you need to add a bit for hard link
target to the mode but according to RsyncFileIO.pm, it seems like
otherfile types are also encoded in the mode bit via the S_IFxxx
masks. For non-hard links, how does this differ from the 'type attrib?
or is it redundant.
Also, given the target how does rsync 'know' what other files are
hard-linked to it when only doing a partial restore (or is that not
necessary info)?
Further, can I assume this schemme will continue to work even if you modify the
exclude/include between incremental backups so that hard-links
variously appear/disappear?
Also, can I assume that directories are treated the same way -- and
that if so then this is one case where the directory tree won't be
completely replicated for incrementals (i.e. only the target tree will
be replicated).
> This results in one subtle bug that can't be easily fixed: if you
> switch the Xfer method from tar to rsync, old backups that have
> hardlinks stored with tar won't be correctly restored with rsync.
> The workaround is generate a tar file and extract it, or switch
> the Xfer method back to tar before you do the restore. The
> opposite case should work correctly.
>
> Craig
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
