Subject: Some files corrupted from remote dump/restore reproducably
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
Acknowledgement sent
to Bdale Garbee <[email protected]>:
Extra info received and forwarded to list.
(Thu, 18 Jun 2009 19:57:05 GMT) (full text, mbox, link).
Subject: Re: Bug#520927: Some files corrupted from remote dump/restore
reproducably
Date: Thu, 18 Jun 2009 13:54:31 -0600
On Mon, 2009-03-23 at 17:14 +0000, Jenny Barna wrote:
> 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.
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
Subject: Re: Bug#520927: Some files corrupted from remote dump/restore
reproducably
Date: Fri, 19 Jun 2009 09:24:27 +0100 (BST)
On Thu, 18 Jun 2009, Bdale Garbee wrote:
> On Mon, 2009-03-23 at 17:14 +0000, Jenny Barna wrote:
>> 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.
>
> 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.
>
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 protected]
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
Acknowledgement sent
to Bdale Garbee <[email protected]>:
Extra info received and forwarded to list.
(Fri, 19 Jun 2009 15:24:06 GMT) (full text, mbox, link).
Subject: Re: Bug#520927: Some files corrupted from remote dump/restore
reproducably
Date: Fri, 19 Jun 2009 09:20:31 -0600
On Fri, 2009-06-19 at 09:24 +0100, Jenny Barna wrote:
> 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.
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
Subject: Re: Bug#520927: Some files corrupted from remote dump/restore
reproducably
Date: Fri, 19 Jun 2009 16:41:42 +0100 (BST)
>
>> 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.
>
> 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 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.
Reply sent
to [email protected] (Bdale Garbee):
You have marked Bug as forwarded.
(Mon, 31 Aug 2009 23:24:10 GMT) (full text, mbox, link).
Hi!
One of the users of my Debian package of dump reported repeatable corruption
when using dump over rmt to a remote tape drive. See the item in our bug
tracking system at http://bugs.debian.org/520927 for more information.
I've poked around a bit, but it won't be easy for me to reproduce the problem.
Does this ring any bells with you?
Bdale
On Mon, Aug 31, 2009 at 05:15:37PM -0600, Bdale Garbee wrote:
> One of the users of my Debian package of dump reported repeatable corruption
> when using dump over rmt to a remote tape drive. See the item in our bug
> tracking system at http://bugs.debian.org/520927 for more information.
>
> I've poked around a bit, but it won't be easy for me to reproduce the problem.
> Does this ring any bells with you?
This sounds a lot like the kind of problems that can be encountered
when dumping a live filesystem.
In order to completly rule out any network related corruptions, I
would suggest to try doing a dumping locally (into a file in /tmp for
example), and try restoring (or comparing) this dump.
As for the live filesystem problem, the only way to confirm that
this is the cause is, well, to umount (or mount R/O) the filesystem
before dumping.
While you're at it, try to force a fsck on this filesystem, just in
case the filesystem is really corrupt...
Stelian.
--
Stelian Pop <[email protected]>
Acknowledgement sent
to Christian Perrier <[email protected]>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <[email protected]>.
(Tue, 16 Mar 2010 07:42:18 GMT) (full text, mbox, link).
Subject: More information needed about this dump corruption bug
Date: Tue, 16 Mar 2010 14:28:57 +0700
tags 520927 moreinfo
thanks
Hello Jenny,
Back in March 2009, you reported a bug about file corruption when
dumping filesystems.
Bdale Garbee, who maintains the relevant package asked the upstream
author (Stelian Pop) whether that rings some bells for him.
Stelian answered the following, which was apparently never forwarded
to you (or at least in a visible way). This sounds like some tests
could be done on your side. Hopefully, you're still in position to do
them...
Stelian Pop's answer:
On Mon, Aug 31, 2009 at 05:15:37PM -0600, Bdale Garbee wrote:
> One of the users of my Debian package of dump reported repeatable corruption
> when using dump over rmt to a remote tape drive. See the item in our bug
> tracking system at http://bugs.debian.org/520927 for more information.
>
> I've poked around a bit, but it won't be easy for me to reproduce the problem.
> Does this ring any bells with you?
This sounds a lot like the kind of problems that can be encountered
when dumping a live filesystem.
In order to completly rule out any network related corruptions, I
would suggest to try doing a dumping locally (into a file in /tmp for
example), and try restoring (or comparing) this dump.
As for the live filesystem problem, the only way to confirm that
this is the cause is, well, to umount (or mount R/O) the filesystem
before dumping.
While you're at it, try to force a fsck on this filesystem, just in
case the filesystem is really corrupt...
Stelian.
--
Stelian Pop <[email protected]>
Subject: Re: Bug#520927: More information needed about this dump corruption
bug
Date: Wed, 17 Mar 2010 12:00:42 +0000 (GMT)
On Tue, 16 Mar 2010, Christian Perrier wrote:
> tags 520927 moreinfo
> thanks
>
> Hello Jenny,
>
> Back in March 2009, you reported a bug about file corruption when
> dumping filesystems.
>
> Bdale Garbee, who maintains the relevant package asked the upstream
> author (Stelian Pop) whether that rings some bells for him.
>
> Stelian answered the following, which was apparently never forwarded
> to you (or at least in a visible way). This sounds like some tests
> could be done on your side. Hopefully, you're still in position to do
> them...
>
No I have no record of this.
> Stelian Pop's answer:
>
> On Mon, Aug 31, 2009 at 05:15:37PM -0600, Bdale Garbee wrote:
>
>> One of the users of my Debian package of dump reported repeatable corruption
>> when using dump over rmt to a remote tape drive. See the item in our bug
>> tracking system at http://bugs.debian.org/520927 for more information.
>>
>> I've poked around a bit, but it won't be easy for me to reproduce the problem.
>> Does this ring any bells with you?
>
> This sounds a lot like the kind of problems that can be encountered
> when dumping a live filesystem.
>
> In order to completly rule out any network related corruptions, I
> would suggest to try doing a dumping locally (into a file in /tmp for
> example), and try restoring (or comparing) this dump.
I had tested local dumps before I reported the problem. Neither a local
dump to a tape, nor a dump piped into restore to a disk, nor to a file
on disk have given any problem I can locate even tho they are from a live
system. And remote tar also seems ok. So as reported then the problem was
confined to remote dump.
> As for the live filesystem problem, the only way to confirm that
> this is the cause is, well, to umount (or mount R/O) the filesystem
> before dumping.
>
It was not the problem. See above.
What I have not done is tried a remote dump to tape again in recent months
so if any patch may have fixed it I could try one again.
Information stored
: Bug#520927; Package dump.
(Wed, 17 Mar 2010 12:03:10 GMT) (full text, mbox, link).
Acknowledgement sent
to [email protected]:
Extra info received and filed, but not forwarded.
(Wed, 17 Mar 2010 12:03:10 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.