Date: Mon, 22 Feb 2010 12:23:10 +0800 From: Aiza <aiza21@comclark.com> To: Jerry McAllister <jerrymc@msu.edu> Cc: freebsd-questions <questions@freebsd.org> Subject: Re: Dump questions Message-ID: <4B8206AE.8080105@comclark.com> In-Reply-To: <20100222030127.GA41439@gizmo.acns.msu.edu> References: <4B80ABBA.9000707@comclark.com> <20100221110358.9ec8b286.freebsd@edvax.de> <20100222030127.GA41439@gizmo.acns.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <aiza21@comclark.com> 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B8206AE.8080105>