From owner-freebsd-questions@FreeBSD.ORG Mon Feb 22 03:14:56 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 030A8106566B for ; Mon, 22 Feb 2010 03:14:56 +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 B6CAD8FC17 for ; Mon, 22 Feb 2010 03:14:55 +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 o1M31R69041593; Sun, 21 Feb 2010 22:01:27 -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 o1M31RnY041592; Sun, 21 Feb 2010 22:01:27 -0500 (EST) (envelope-from jerrymc) Date: Sun, 21 Feb 2010 22:01:27 -0500 From: Jerry McAllister To: Aiza Message-ID: <20100222030127.GA41439@gizmo.acns.msu.edu> References: <4B80ABBA.9000707@comclark.com> <20100221110358.9ec8b286.freebsd@edvax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100221110358.9ec8b286.freebsd@edvax.de> User-Agent: Mutt/1.4.2.2i Cc: 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 03:14:56 -0000 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 > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"