Re: [rdiff-backup-users] Serious data loss using rdiff-backup

[Alistair Popple]

> Hmm... so do you think when the symlink to /usr was deleted, /usr was
> deleted along with it?

This is probably best explained with an example I used to replicate
the problem on a test system at home.  Hopefully this is
understandable (I can clarify anything if it isn't):

I created the following directory structure in /tmp/rdiff-backup-test/src:

.
|-- test1
|   |-- test1.1
|   |   |-- a
|   |   |-- b
|   |   `-- c
|   `-- test1.2
|       |-- d
|       |-- e
|       `-- f
`-- test2
    |-- test2.1
    |   `-- test1.1
    |       |-- g
    |       |-- h
    |       `-- i
    `-- test2.2
        |-- j
        |-- k
        `-- l

The following steps were then performed:
* rdiff-backup -v7 address@hidden::/tmp/rdiff-backup-test/src/
/tmp/rdiff-backup-test/dest/
* mv /tmp/rdiff-backup-test/src/test2/test2.1
/tmp/rdiff-backup-test/src/test2/test2.1.old
* ln -s /tmp/rdiff-backup-test/src/test1
/tmp/rdiff-backup-test/src/test2/test2.1
* rdiff-backup -v7 address@hidden::/tmp/rdiff-backup-test/src/
/tmp/rdiff-backup-test/dest/

At this point everything should be fine and working as expected.  The
following directory structure exists in the desination directory:

|-- rdiff-backup-data
|   |-- ......................
|-- test1
|   |-- test1.1
|   |   |-- a
|   |   |-- b
|   |   `-- c
|   `-- test1.2
|       |-- d
|       |-- e
|       `-- f
`-- test2
    |-- test2.1 -> /tmp/rdiff-backup-test/src/test1/
    |-- test2.1.old
    |   `-- test1.1
    |       |-- g
    |       |-- h
    |       `-- i
    `-- test2.2
        |-- j
        |-- k
        `-- l

Note the symlink from test2.1 to a file outside the destination path.

However if the backup fails (eg. it is interrupted halfway through)
then the desintation directory needs checking:
* rdiff-backup -v7 --check-desintation /tmp/rdiff-backup-test/dest

It is at this point the problems begin.  If you check
/tmp/rdiff-backup-test/src/test1 (a directory outside of the
destination) you will find that the test1.1 directory has been
deleted.  This only happens for the directories mentioned in the
original (non-linked) version of test2.1, which is why test1.2
remains.  The problem here seems to be that the check-destination-dir
option follows the symlinks rather than treating them as files.  If
the link is changed to a relative one then sure enough no directories
outside of the destination seem to be modified, however after the
destination check test1.1 is missing from the destination/backup - ie.
it has _not_ been backed up.  Performing  subsequent backups will also
not back that information up, even if the relative symlink is removed,
thus the backups remain incomplete for what I assume is ever more.