Subject: Some files corrupted from remote dump/restore reproducably

From: Jenny Barna <[email-masked]>
Date: Mon, 23 Mar 2009 17:14:34 +0000

Package: dump
Version: 0.4b41-5+b1
Severity: critical
Justification: causes serious data loss

I set up dump using a SLT24 tape system and tested local and remote
dump and restore with restoring single files OK. When I restored a user's
lost file I discovered I had got back text from another (unrelated?) file.

Therefore I restored the whole of /etc (critical) locally from a typical dump
and cannot see a problem, on the system where the tape drive is. But when I 
dump/restore from this system to the remote tape drive (same OS) I am 
reproducably finding some files corrupted (using /etc for all tests). When I do 
file * in the restored etc I find two files listed as Vim swap files. These 
seem in some way related eg hosts.allow is full of the wrong contents and one 
of my old copies (I dated them .0902xx etc) is reported as a Vim file. This 
behaviour happens with the default block size, with a block size of 64 and one 
of 256. The files in question are not open when I do the test dump though it 
is true the file system is mounted. I have not proved no files are corrupted 
on any local dump. I have read that dump may not be as reliable for a mounted 
file system under Linux as with Solaris, which I was using before, but if
this is a feature not a bug then I am unsure how to avoid it. hosts.allow has 
definitely been edited with vi but another file that seems corrupted is mailcap 
and I do not think I have edited that. The key thing is that the same 
corrupted files are seen each time I do this test ie from /etc on this system
to the remote tape drive on the same OS. dump and restore give no errors. 
Thanks.

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dump depends on:
ii  e2fslibs                  1.41.3-1       ext2 filesystem libraries
ii  libblkid1                 1.41.3-1       block device id library
ii  libc6                     2.7-18         GNU C Library: Shared libraries
ii  libcomerr2                1.41.3-1       common error description library
ii  libncurses5               5.7+20081213-1 shared libraries for terminal hand
ii  libreadline5              5.2-3.1        GNU readline and history libraries
ii  libuuid1                  1.41.3-1       universally unique id library
ii  tar                       1.20-1         GNU version of the tar archiving u

dump recommends no packages.

dump suggests no packages.

-- no debconf information

---

From: Bdale Garbee <[email-masked]>
Date: Thu, 18 Jun 2009 13:54:31 -0600

> lost file I discovered I had got back text from another (unrelated?) file.

Which rmt are you using?  On Debian systems, there are several packages
that can provide rmt, so the 'alternatives' mechanism is used to allow
you to choose which one you want.  By default, you probably get the one
provided by the 'tar' package.  It would be interesting to know whether
you're configured to use the rmt that comes with dump, with tar, or some
other version.

Bdale

---

From: Jenny Barna <[email-masked]>
Date: Fri, 19 Jun 2009 09:24:27 +0100 (BST)

> you're configured to use the rmt that comes with dump, with tar, or some

It appears to be using /usr/sbin/rmt-dump

Since I wrote that in March I switched to using tar for my two remote
machines whereas I stayed with dump for the machine that has the tape
system on it.

Jenny Barna            | Email 	               [email-masked]
SBS Computing Facility | Web computing.bio.cam.ac.uk
Dept of Biochemistry   | Telephone (Direct)   +44 1223 333644
Tennis Court Road      | Switchboard          +44 1223 333600
Cambridge, CB2 1QW, UK | Fax:                 +44 1223 333345

---

From: Bdale Garbee <[email-masked]>
Date: Fri, 19 Jun 2009 09:20:31 -0600

> machines whereas I stayed with dump for the machine that has the tape

That's interesting.  So are you using rmt with tar, or some other
transport mechanism?  If you're using rmt-dump in all cases, that would
certainly help point the finger squarely at dump itself!

I personally use amanda, so while I run both dump and tar for different
system needs, I don't ever actually use the built-in remote support...
remote transport is handled by amanda.

Bdale

---

From: Jenny Barna <[email-masked]>
Date: Fri, 19 Jun 2009 16:41:42 +0100 (BST)

> certainly help point the finger squarely at dump itself!

I guess so.

After I reported this I had found to my horror that my remote dumps were 
useless with multiple corrupted files eg in /etc whereas remote tar
seemed ok.