 |
Page 1 of 1
|
| Author |
Message |
john
Guest
|
 Bug report: Symbolic link replacing directory
Hi all!
How to confuse a backup system? Maybe you should try this approach, it
worked for me. :-(
Confusion recipe for rdiff-backup V12.6:
Create two directories (dir1 and dir2).
Create two files, dir1/file1 and dir2/file2.
Backup the stuff.
Move file2 to dir1/file2.
Remove dir2.
Symlink dir2 -> dir1
Backup the stuff.
This gives the following error message:
UpdateError dir1/file2 File changed from regular file before signature.
And file2 is not in the backup.
I cannot see any mention of this behaviour in the changelog of V12.7,
so I gues this version should do the same. Otherwise I would have
updated and tested again.
As a workaround to this bug, I thought about deleting dir2 in the
increment directory. That way I would lose old history, but that
doesn`t really matter. But what to do with the metadata, so the whole
backup remains consistent?
Open Christmas
John
|
| Thu Dec 23, 2004 2:16 am |
|
 |
Finn-Arne Johansen
Guest
|
 Bug report: Symbolic link replacing directory
john wrote:
Hi all!
How to confuse a backup system? Maybe you should try this approach, it
worked for me. :-(
Confusion recipe for rdiff-backup V12.6:
Create two directories (dir1 and dir2).
Create two files, dir1/file1 and dir2/file2.
Backup the stuff.
Move file2 to dir1/file2.
Remove dir2.
Symlink dir2 -> dir1
Backup the stuff.
This gives the following error message:
UpdateError dir1/file2 File changed from regular file before signature.
And file2 is not in the backup.
I cannot see any mention of this behaviour in the changelog of V12.7,
so I gues this version should do the same. Otherwise I would have
updated and tested again.
As a workaround to this bug, I thought about deleting dir2 in the
increment directory. That way I would lose old history, but that
doesn`t really matter. But what to do with the metadata, so the whole
backup remains consistent?
Wouldnt it be better to remove dir2 , and not create the symlink until
after a backup has run.
Another approach, depending on how much data there is, is to first do a
hardlink. something like:
mkdir dir1 dir2
for FILE in dir1/file1 dir2/file2 ; do
echo $FILE > $FILE
done
rdiff-backup --add-your-options
ln dir2/file2 dir1
rdiff-backup --add-your-options
rm -rf dir2
rdiff-backup --add-your-options
ln -s dir1 dir2
rdiff-backup --add-your-options
I guess that will cause less pain to your backup, but I'm not sure.
// faj
|
| Thu Dec 23, 2004 2:55 am |
|
 |
Maarten Bezemer
Guest
|
 Bug report: Symbolic link replacing directory
Hi,
On Thu, 23 Dec 2004, john wrote:
How to confuse a backup system? Maybe you should try this approach, it
worked for me. :-(
There have been other threads about problems with special files (like
symlinks). Even so far as deleted _source_ trees because of symlink
handling. As a workaround (and no, I do not quite like it this way) I make
a .tgz of all special files and then exclude all special files when
invoking rdiff-backup.
Restoring is a bit more compilated that way though, so make sure you know
what's going on.
What I'd like to see, is an option to have special files exist _only_ in
metadata, not on disk. This would enable backing up to file systems
without notion of ownership and file types, like vfat.
Kind regards,
Maarten Bezemer
|
| Thu Dec 23, 2004 6:44 am |
|
 |
ruttmannn
Guest
|
 Bug report: Symbolic link replacing directory
There have been other threads about problems with special files
(like symlinks).
Okay, I do not read the mailing list regularly. On the other hand: The
feature list on the homepage does clearly say, that symlinks are
supported, which they definetly are, but I couldn`t find any bug list on
the homepage. Isnīt there any?
I consider this bug as severe, as quite a lot of files can be missing
in the backup set (and were missing). I`m currently fixing that by
deleting those files and the metadata of the current backup, so the
next backup run should recreate them synchron to the source.
Even so far as deleted _source_ trees because of symlink
handling.
Are you sure? This would be worse than severe. As long as my source
data is untouched I always can run diffs between source and backup and
find rdiff errors, like that one, and can fix it. Not very nice, but
kinda save.
But an error condition like that is untrackable without a
backup... Can you give me a pointer to that kind of error, I really
want to know what I am dealing with here. Maybe I have to drop
rdiff-backup, because it`s to risky to use.
What I'd like to see, is an option to have special files exist _only_ in
metadata, not on disk. This would enable backing up to file systems
without notion of ownership and file types, like vfat.
Would be nice, agreed. But shouldn`t it first work correctly on unix
filesystems?
cu
John
|
| Fri Dec 24, 2004 2:45 am |
|
 |
|
|
The time now is Fri May 25, 2012 4:01 pm | All times are GMT - 8 Hours
|
Page 1 of 1
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|