rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[rdiff-backup-users] rdiff-backup crashing


From: Rudy L. Zijlstra
Subject: [rdiff-backup-users] rdiff-backup crashing
Date: Sat, 10 Apr 2004 12:55:06 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040117

Gents,

I am having a problem.

History:
last week on the master file server a disk crashed. Its been returned to the manufacturer under warrenty. Alas, it crashed during the backup. Apparently the backup structure is inconsistent. I restored the data from the backup onto a different disk and have had no complaint of the users. BUT

later backups never completed. They started well, than slowed down to a crawl. I've modified my backup server to let it complete, and after more than 2 days such a backup was still incomplete. And the linux OOM killer killed the running backup instance...
Normal backup time is less than 2 hours.

Version that showed this behaviour was 0.10.2
In an attempt to solve this i upgraded to 0.12.6 (and upgraded librsync to 0.9.6). To do this consistently (and because i had other reasons to do this as well) i've also upgraded from slackware 7 based distro to slackware-current as of 2 weeks ago (which includes an upgrade from python 2.2 to python 2.3.3).

disk mappings are unchanged.

I now get the following error from rdiff-backup:

address@hidden:~# rdiff-backup --force -v 6 /src/garion-public/ /backup/garion-public/ Touching mirror marker /backup/garion-public/rdiff-backup-data/current_mirror.2004-04-10T12:11:10+02:00.data
Warning: Metadata file not found.
Metadata will be read from filesystem.
Processing changed file .
Incrementing mirror file /backup/garion-public
Traceback (most recent call last):
 File "/usr/local/bin/rdiff-backup", line 23, in ?
   rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 250, in Main
   take_action(rps)
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 222, in take_action
   elif action == "backup": Backup(rps[0], rps[1])
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 264, in Backup
   backup.Mirror_and_increment(rpin, rpout, incdir)
File "/usr/lib/python2.3/site-packages/rdiff_backup/backup.py", line 47, in Mirror_and_increment
   DestS.patch_and_increment(dest_rpath, source_diffiter, inc_rpath)
File "/usr/lib/python2.3/site-packages/rdiff_backup/backup.py", line 220, in patch_and_increment
   ITR(diff.index, diff)
File "/usr/lib/python2.3/site-packages/rdiff_backup/rorpiter.py", line 266, in __call__
   else: self.root_branch.start_process(*args)
File "/usr/lib/python2.3/site-packages/rdiff_backup/backup.py", line 610, in start_process
   self.get_incrp(index))
File "/usr/lib/python2.3/site-packages/rdiff_backup/backup.py", line 575, in inc_with_checking
   try: inc = increment.Increment(new, old, inc_rp)
File "/usr/lib/python2.3/site-packages/rdiff_backup/increment.py", line 41, in Increment
   elif mirror.isdir(): incrp = makedir(mirror, incpref)
File "/usr/lib/python2.3/site-packages/rdiff_backup/increment.py", line 94, in makedir
   dirsign = get_inc(incpref, "dir")
File "/usr/lib/python2.3/site-packages/rdiff_backup/increment.py", line 114, in get_inc
   assert not incrp.lstat()
AssertionError
Exception exceptions.TypeError: "'NoneType' object is not callable" in <bound method GzipFile.__del__ of <gzip open file '/backup/garion-public/rdiff-backup-data/file_statistics.2004-04-10T12:11:10+02:00.data.gz', mode 'wb' at 0x40403820 0x4066d7cc>> ignored Exception exceptions.TypeError: "'NoneType' object is not callable" in <bound method GzipFile.__del__ of <gzip open file '/backup/garion-public/rdiff-backup-data/error_log.2004-04-10T12:11:10+02:00.data.gz', mode 'wb' at 0x40403da0 0x4067204c>> ignored Exception exceptions.TypeError: "'NoneType' object is not callable" in <bound method GzipFile.__del__ of <gzip open file '/backup/garion-public/rdiff-backup-data/mirror_metadata.2004-04-10T12:11:10+02:00.snapshot.gz', mode 'wb' at 0x40403d60 0x4068228c>> ignored


This happens only on the backup set which was being backed-up during the disk crash. All other backup sets are unharmed and get a backup without any problem.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]