From owner-freebsd-questions@FreeBSD.ORG Mon Aug 6 15:28:03 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC73B16A417 for ; Mon, 6 Aug 2007 15:28:03 +0000 (UTC) (envelope-from wmoran@potentialtech.com) Received: from mail.potentialtech.com (internet.potentialtech.com [66.167.251.6]) by mx1.freebsd.org (Postfix) with ESMTP id B84DD13C46A for ; Mon, 6 Aug 2007 15:28:03 +0000 (UTC) (envelope-from wmoran@potentialtech.com) Received: from vanquish.pitbpa0.priv.collaborativefusion.com (pr40.pitbpa0.pub.collaborativefusion.com [206.210.89.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.potentialtech.com (Postfix) with ESMTP id 8B325EBC78; Mon, 6 Aug 2007 11:28:02 -0400 (EDT) Date: Mon, 6 Aug 2007 11:28:01 -0400 From: Bill Moran To: Jerry McAllister 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> X-Mailer: Sylpheed 2.4.4 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: User Questions , Victor Sudakov Subject: Re: dump -L X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2007 15:28:03 -0000 In response to Jerry McAllister : > 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