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

Bug#466416: marked as done (backuppc corrupts its data if they are on a reiserfs partition)



Your message dated Mon, 26 May 2008 15:32:06 +0200
with message-id <20080526133206.GG21309@stro.at>
and subject line Re: backuppc corrupts its data if they are on a reiserfs partition
has caused the Debian Bug report #466416,
regarding backuppc corrupts its data if they are on a reiserfs partition
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
466416: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466416
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: backuppc
Version: 2.1.2-6
Severity: important


I can state the problem this way: "backuppc corrupts a reiserfs 
partition" and "a ls or find command running on a corrupted reiserfs
partition hangs the server".

I'm using backuppc since 2004, under sid; that time I had compiled
backuppc by miself, since it was not in the package list.
Then I migrated to sarge (using backuppc included in the release) and
now I'm using it with etch. I'm always been using reiserfs for the data
partition, with two HD in RAID 1 configuration.

More or less one time a year, backuppc hanged the backup server.
Looking for a solution I discovered that the data partition was
corrupted and simply by running an "ls" or a "find" command in
the incriminated dir, the server hangs and stops responding to
the console or the network.
The problem was caused by the BackupPC script that was running an
ls or similar command in that dir, and it hanged the system.

I'm not able to determine the cause of the corruption. The server is
powered using an UPS, and I'm (almost) sure that has no other problem
(that is, excluding the problem that I'm now reporting); smartmontools
is up an running, no HD error or HW falure was detected.

I can imagine only three possible causes for these hangs:
- the high number of links that backuppc creates in its data directory;
- the too nested directory structure that backuppc uses for the backupped pc;
- the long names that backuppc uses for the linked filenames

The backupped network has only 6 machines, all running debian linux.
The backup server has also a SCSI adapter that holds a 4GB streamer
that I use for a weekly tape backups.

I know that people is making bigger backups (mine is only 60 GB for data
partition) and on bigger networks (more than 100 pc, according to
various mailing list), so I'm not pushing neither backuppc nor reiserfs
to their limits.

I know also that reiserfs should not have problem on managing data
directory; also, we use it as our fs for all machines, and since 2003 we
had no problem with it, excluding 2 HD that were defective (and that were
detected by smartmon tool, so it was not a problem of reiserfs).

In my understanding the problem it's caused by the interaction between
them (reiserfs and backuppc).

The problem was solved by running reiserfsck --rebuild-tree; this is the
log that was produced:

####### Pass 0 #######
block 6428678: The number of items (26624) is incorrect, should be (1) -
corrected
block 6428678: The free space (500) is incorrect, should be (4048) -
corrected
pass0: vpf-10110: block 6428678, item (0): Unknown item type found
[666668288 0 0xfffce853 ??? (15)] - deleted
pass0: vpf-10590: block 13076527, item 3: Wrong order of items - change
the object_id of the key [10156796 10156879 0x1 DIR (3)] to 10156815
5229398 directory entries were hashed with "r5" hash.
####### Pass 1 #######
####### Pass 2 #######
####### Pass 3 #########
####### Pass 3a (lost+found pass) #########

Please, if you think that this is a bug of reiserfs, direct me to the
reiserfs package that I shoud file this bug (or it is a kernel problem?)

Thanks, Luca


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages backuppc depends on:
ii  adduser                    3.102         Add and remove users and groups
ii  apache2-mpm-prefork [apach 2.2.3-4+etch3 Traditional model for Apache HTTPD
ii  debconf [debconf-2.0]      1.5.11etch1   Debian configuration management sy
ii  dpkg                       1.13.25       package maintenance system for Deb
ii  exim4                      4.63-17       metapackage to ease exim MTA (v4) 
ii  exim4-daemon-light [mail-t 4.63-17       lightweight exim MTA (v4) daemon
ii  libarchive-zip-perl        1.16-1        Module for manipulation of ZIP arc
ii  libcompress-zlib-perl      1.42-2        Perl module for creation and manip
ii  perl [libdigest-md5-perl]  5.8.8-7etch1  Larry Wall's Practical Extraction 
ii  perl-suid                  5.8.8-7etch1  Runs setuid Perl scripts
ii  samba-common               3.0.24-6etch9 Samba common files used by both th
ii  smbclient                  3.0.24-6etch9 a LanManager-like simple client fo
ii  tar                        1.16-2etch1   GNU tar
ii  wwwconfig-common           0.0.48        Debian web auto configuration

backuppc recommends no packages.

-- debconf information:
* backuppc/add-lines: true
* backuppc/configuration-note:



--- End Message ---
--- Begin Message ---
Version: 2.6.24-1

reiserfs is not the safest fs on earth. anyway suse reiserfs patches
got merged upstream after they switched to ext3 as default fs.
see how to get newer linux image for etch
-> http://wiki.debian.org/EtchAndAHalf

-- 
maks


--- End Message ---

Reply to: