From owner-freebsd-questions@FreeBSD.ORG Mon Feb 22 14:38:58 2010 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B356106568F for ; Mon, 22 Feb 2010 14:38:58 +0000 (UTC) (envelope-from jerrymc@gizmo.acns.msu.edu) Received: from gizmo.acns.msu.edu (gizmo.acns.msu.edu [35.8.1.43]) by mx1.freebsd.org (Postfix) with ESMTP id 574EE8FC0C for ; Mon, 22 Feb 2010 14:38:57 +0000 (UTC) Received: from gizmo.acns.msu.edu (localhost [127.0.0.1]) by gizmo.acns.msu.edu (8.13.6/8.13.6) with ESMTP id o1MEUTB1043709; Mon, 22 Feb 2010 09:30:29 -0500 (EST) (envelope-from jerrymc@gizmo.acns.msu.edu) Received: (from jerrymc@localhost) by gizmo.acns.msu.edu (8.13.6/8.13.6/Submit) id o1MEUTXQ043708; Mon, 22 Feb 2010 09:30:29 -0500 (EST) (envelope-from jerrymc) Date: Mon, 22 Feb 2010 09:30:29 -0500 From: Jerry McAllister To: Aiza Message-ID: <20100222143028.GA43687@gizmo.acns.msu.edu> References: <4B80ABBA.9000707@comclark.com> <20100221110358.9ec8b286.freebsd@edvax.de> <20100222030127.GA41439@gizmo.acns.msu.edu> <4B8206AE.8080105@comclark.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B8206AE.8080105@comclark.com> User-Agent: Mutt/1.4.2.2i Cc: Jerry McAllister , freebsd-questions Subject: Re: Dump questions 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, 22 Feb 2010 14:38:58 -0000 On Mon, Feb 22, 2010 at 12:23:10PM +0800, Aiza wrote: > Jerry McAllister wrote: > >On Sun, Feb 21, 2010 at 11:03:58AM +0100, Polytropon wrote: > > > >On Sun, 21 Feb 2010 11:42:50 +0800, Aiza wrote: > >>1. Using the -L flag to create a snapshot of the > >>live running file system. > >> > >>... > >> > >>Is this the limiting factor that forces a user > >>to use (single user mode) for running dump? > > > >The snapshot, as far as the dump is concerned, essentially freezes > >the condition of the file system so that dump does not see any changes > >while dump is running. > > > >Without the snapshot, files could change or be deleted during the time > >it takes dump to finish. Dump starts by making its own list, by inode, > >of all the files to dump. Then it writes out, first the list, then the > >directories and finally the files and links to the media. If the files > >change between the time that list is made and things get written to the > >media, you will have an inaccurate representation of the file system. > >This can result in error messages if files it expects to be there are > >missing > >It can mean that a mangled image of a file is written in the dump. > > > >Doing a dump in Single User Mode means stopping activity on the system > >so there are fewer chances of the above happening. > > > >Using -L and doing a snapshot will not prevent a dump from being > >technically obsolete by the time it gets done, but it will mean that > >what gets written to media is internally consistent. The list it made > >will be exactly what is on the backup media and the files are all written > >completely as they were when the snapshot was taken with no mangling. > > > >>>2. What is the worse that will happen if dump is > >>run on live file system with out the -L flag? > >> > > > >The index list that is written as part of the dump will not reflect > >what is on the dump media. It may claim a file is there, but it > >really is not. > > > >A file or some files are mangled because they are open and being modified > >by another process as the dump is reading them. The file may be either > >an inaccurate image or even completely unreadable. > > > >Restore is smart enough to skip over these problems if the file[s] you > >are looking to restore are not the ones mangled or deleted. But, you > >could get in to a situation of not being able to restore some things > >that you have on media. > > > >>Can dump recognize this situation and issue > >>an error message? > >> > > > >I don't remember if dump puts out any useful diagnostic. I think it might > >tell you if it cannot file a file whose inode is in its list to write. > >But, it is restore that really notices and complains. If you have room, > >you can use restore to 'verify' a dump just by doing a restore of it to > >some extra space (maybe even to /dev/null, though I have never tried that > >one) and seeing if it makes any complaints. This, of course, is a long > >way to do this, but it might be valuable if it is essential for that > >dump to be completely readable in a later situation where the original > >is not longer available. > > > >But, in this situation, then making a -L dump (using a snapshot) is > >really important or even a single user, filesystem unmounted -L dump. > > > >>3. Can dump be told to only dump a particular > >>directory tree? IE /var/log or /usr/port? > > > >dump only workes on filesystems/partitions. If you know you will want to > >make dumps on just that directory tree, that is a reason to make a separate > >partition/filesystem for it and mount it up. There is no reason that > >/var/log cannot be in its own partition/filesystem separate from /var > >and just mounted that way. Of course, you have to make sure that /var > >gets mounted before /var/log. But, that is not strange. Many people > >make a separate partition for /usr/home inside of /usr or a /var/db that > >is mounted inside of /var. > > > >Now, you can restore just a single file, group of files or a directory > >tree out of a dump. You do not have to restore the whole dump. > >So, you can make a dump of a '/var' filesystem if that is what you have > >and then if you need to restore just '/var/db' out of it, that is > >no problem. Just make sure you understand where you are putting it > >and how you specifiy it in the restore. > > > >But, if you just want a backup copy of a directory tree that is not its > >own partition/filesystem, you must use some other tool, such as tar or > >possibly rsync. > > > >////jerry > > > > > Thank you for the detail insight of how dump functions. > Now one more question. > > Is the dump -L backup file made in a multiple-user-mode environment just > as dependable as dump backups made in single-user-mode? > No. In multi-user, files are still changing. The snapshot could possibly be made between parts of a change - between different writes to the file, so there could be some inconsistency. In practice this is not a big problem, but, single user with filesystems unmounted is still the most absolute way of making sure a filesystem is quiescent during a dump. ////jerry