bugrdiff-backup - Bugs: bug #16526, rdiff overwriting/deleting data on...

 
 

bug #16526: rdiff overwriting/deleting data on restore [user error]

Submitter:  None
Submitted:  Thu 04 May 2006 11:21:49 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Wont Fix
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 13 Nov 2006 09:10:18 PM UTC, comment #3: 

Now that I have a Savannah account, I want to mention that I posted comment #1 and comment #2 below.

Andrew Ferguson <owsla>
Group administrator
Mon 13 Nov 2006 02:54:42 AM UTC, comment #2: 

Frankly, it's the --force option that got you into trouble. If we leave out --force, we get:

Fatal Error: Restore target . already exists, specify --force to overwrite.

So, this is really a user error. If this seems to bite lots of people, maybe someone will step-up and write a patch.

Here's another example (DON'T RUN :-) --

ln -s /mydir foo
rm -rf foo

Funny how the force option destroys /mydir ...

Anonymous
Mon 13 Nov 2006 02:46:49 AM UTC, comment #1: 

If we look at how rdiff-backup wants to restore files, eg,
"rdiff-backup -r now host.net::/remote-dir/file local-dir/file"

then I think what happened here is that rdiff-backup wanted to restore the file ./my_rdiff_repository/path/single_file to the file called '.' -- that is, like saying:

cp -f /backup/my_rdiff_repository/path/single_file /backup

where cp decides to delete the directory 'backup' and replace it with single_file, renamed to 'backup. However, rdiff-backup didn't quite manage to finish this before failing.

Anonymous
Thu 04 May 2006 11:21:49 PM UTC, original submission:  

also see http://lists.gnu.org/archive/html/rdiff-backup-users/2006-04/msg00025.html



hello!

i'm new to rdiff-backup (great tool, though!) - i never did testing the restore in depth, but i was playing with this today - and i accidentally killed my complete rdiff-backup repository!

OUCH!


fortunately, i did this in /backup with a non-priviledged account - and not in / with the root account - furthermore i'm just "still testing" - otherwise......

I think what i did is just sort of little error (i.e. using --force left over from previous tries - and using "." as i was just used to ), but this gave very unexpected result.

SO - WHAT I`M DEMONSTRATING HERE - TAKE CARE IF YOU WANT TO TRY TO REPRODUCE!

ok - lets go.....


$ cd /backup


$ ls -la
drwx------   3 backup root  96 Apr 13 01:33 .
drwxr-xr-x  28 root root 664 Apr  1 15:28 ..
drwx------   4 backup root 112 Apr 13 01:39 my_rdiff_repository


ok - let`s restore a single file from my repository


$ rdiff-backup --force -r 2D ./my_rdiff_repository/path/single_file . (DON`T DO IT THIS WAY!)

(ok - i did "--force", but that was just because i needed to use it in previous restore-tests and i didn`t expect that it could lead to such serious behaviour)

this command ran for quite a while - i was just wondering why - then giving

Exception '[Errno 22] Invalid argument: '.'' raised of class 'exceptions.OSError':
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 295, in error_check_Main
try: Main(arglist)
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 315, in Main
take_action(rps)
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 281, in take_action
elif action == "restore-as-of": Restore(rps[0], rps[1], 1)
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 490, in Restore
inc_rpath, dest_rp, time)
File "/usr/lib/python2.3/site-packages/rdiff_backup/restore.py", line 37, in Restore
TargetS.patch(target, diff_iter)
File "/usr/lib/python2.3/site-packages/rdiff_backup/restore.py", line 291, in patch
ITR.Finish()
File "/usr/lib/python2.3/site-packages/rdiff_backup/rorpiter.py", line 247, in Finish
to_be_finished.end_process()
File "/usr/lib/python2.3/site-packages/rdiff_backup/restore.py", line 669, in end_process
self.base_rp.rmdir()
File "/usr/lib/python2.3/site-packages/rdiff_backup/rpath.py", line 873, in rmdir
self.conn.os.rmdir(self.path)

Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.error_check_Main(sys.argv[1:])
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 295, in error_check_Main
try: Main(arglist)
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 315, in Main
take_action(rps)
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 281, in take_action
elif action == "restore-as-of": Restore(rps[0], rps[1], 1)
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 490, in Restore
inc_rpath, dest_rp, time)
File "/usr/lib/python2.3/site-packages/rdiff_backup/restore.py", line 37, in Restore
TargetS.patch(target, diff_iter)
File "/usr/lib/python2.3/site-packages/rdiff_backup/restore.py", line 291, in patch
ITR.Finish()
File "/usr/lib/python2.3/site-packages/rdiff_backup/rorpiter.py", line 247, in Finish
to_be_finished.end_process()
File "/usr/lib/python2.3/site-packages/rdiff_backup/restore.py", line 669, in end_process
self.base_rp.rmdir()
File "/usr/lib/python2.3/site-packages/rdiff_backup/rpath.py", line 873, in rmdir
self.conn.os.rmdir(self.path)
OSError: [Errno 22] Invalid argument: '.'

huh ?


vmhost:/backup # ls -la
total 1
drwx------   2 root root  48 Apr 13 01:54 .
drwxr-xr-x  28 root root 664 Apr  1 15:28 ..


damn - what ?


:'-(


trying to restore a single file to current directory recursively seems to have killed my complete backup repository.

imho, a backup program in "restore" mode should never delete dirs/files recursively - not even with a --force option.
a backup program should better save our data, not deleting it.

in the output i see
File "/usr/lib/python2.3/site-packages/rdiff_backup/rpath.py", line 873, in rmdir
is this necessary that this tool does "rmdir" in restore mode - without any option on the commandline which tells "--delete" or "--force-delete" or "--force-overwrite" ?
furthermore, from all sorts of errors i have seen with rdiff-backup, i always see lots of python error-stuff which is difficult to interpret for the end user.
looks like there hasn`t been spend much work in error handling!? is this just something which needs improvement, or is it due to "nature" of python ?

to avoid other people loosing data, i would recommend improving this by changing this or by doing double-checking.
maybe i`m just the "unlucky first one" experiencing this - or i`m just too lazy - but i don`t really feel that i made a big mistake here.

could someone give a comment about what i did or about rdiff-backup's unexpected behaviour ?

thank you!


greetings
roland


ps:
please see this posting just as "constructive criticism" to help improving rdiff-backup


Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by owsla (Updated the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2006-12-18 owsla StatusNone Wont Fix
        Open/ClosedOpen Closed
        Summaryrdiff overwriting/deleting data on restore rdiff overwriting/deleting data on restore [user error]

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code