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

[Alistair Popple]

Ben,

I have just recreated the test directory on my computer again to
verify that my instructions at least made sense to me :)  I was
successful in doing so using version 0.13.4.  If you want some more
help recreating this let me know as it is something that needs to be
sorted out (the example may seem somewhat contrived, but this bug was
found on a production system after it caused the deletion of /usr). 
One thing to note is that the problem is only after rdiff-backup
--check-destination-dir /tmp/rdiff-backup-test/dest has been run -
that is you have to run a backup (using rdiff-backup -v7
address@hidden::/tmp/rdiff-backup-test/src/
/tmp/rdiff-backup-test/dest/) and interrupt it half way using Ctrl-C
or similar so that the directory check is required.

Regards,
Alistair



On Sat, 26 Mar 2005 12:23:49 -0800, Ben Escoto <address@hidden> wrote:
> >>>>> Alistair Popple <address@hidden>
> >>>>> wrote the following on Mon, 4 Oct 2004 21:11:17 +1000
> 
> > Hi,
> > 
> > I was just wondering if anything is happening with this?  Thanks.
> >
> > > 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.
> > >
> 
> This seems to be the most serious unresolved bug on the mailing list,
> and one that wouldn't be fixed by moving to the stable branch, or the
> CVS of the development one.
> 
> Can anyone reproduce this?  I've tried making the test directory and
> variations of it without success (i.e. rdiff-backup seemed to behave
> correctly).  Also looking at the code the relevant bit checks whether a
> file is a symlink or a directory.
> 
> 
> -- 
> Ben Escoto
> 
>