Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Aug 2007 11:28:01 -0400
From:      Bill Moran <wmoran@potentialtech.com>
To:        Jerry McAllister <jerrymc@msu.edu>
Cc:        User Questions <freebsd-questions@freebsd.org>, Victor Sudakov <sudakov@sibptus.tomsk.ru>
Subject:   Re: dump -L
Message-ID:  <20070806112801.986d8609.wmoran@potentialtech.com>
In-Reply-To: <20070806145726.GA64755@gizmo.acns.msu.edu>
References:  <20070724115401.GA1355@admin.sibptus.tomsk.ru> <20070806025614.GA21368@admin.sibptus.tomsk.ru> <20070806145726.GA64755@gizmo.acns.msu.edu>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
In response to Jerry McAllister <jerrymc@msu.edu>:

> On Mon, Aug 06, 2007 at 09:56:15AM +0700, Victor Sudakov wrote:
> 
> > Victor Sudakov wrote:
> > > 
> > > I always use "dump -L" to dump a live filesystem.
> > > However, when I restore the dump, I sometimes get messages like 
> > > "foo.txt (inode 12345) not found on tape" or
> > > "expected next file 12345, got 23456" 
> > > 
> > > I thought this should _never_ happen when dumping a snapshot.
> > > 
> > > What is it?
> > 
> > Does nobody know the answer, or am I the only one experiencing the
> > problem?
> > 
> > Here is another example:
> > 
> > [root@big ~] restore -b64 -rN 
> > ./spool/samba.lock/wins.dat: (inode 2829098) not found on tape
> > expected next file 267, got 4
> > expected next file 2828988, got 2828987
> 
> Using 'dump -L' doesn't prevent you or something running on the system
> from deleting a file after the directory has been created and written.
> 
> The first thing dump does is create a list of files (including directories)
> to dump.   It creates a list of inodes for the files and then does all
> the dumping from that list of inodes.   If a file is then deleted after
> that inode list is made, then it will not get written to the dump media.
> But, the list will still have the inode for the file.   When restore
> looks for files, it searches in inode order and makes a note if an
> inode is missing from the media that it expected (because of the list) to 
> be there.    It is only a true error if that file really should have been
> there and wasn't.   The only time I have had that happen was when the
> media (tape) couldn't be read properly.   Usually then you also get
> other errors.

Ok, but using -L causes dump to create a filesystem snapshot, which is read-
only, meaning that nobody can delete a file from it during the dump process.

My guess would be that something is causing the snapshot to fail, which
will cause dump to issue a warning and then continue without making a
snapshot.  Can you provide the output of dump while doing the dump?

-- 
Bill Moran
http://www.potentialtech.com



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20070806112801.986d8609.wmoran>