Dump questions

[Jerry McAllister]

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 <aiza21 at 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?
> 

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