Dump questions
Aiza
aiza21 at comclark.com
Mon Feb 22 04:23:21 UTC 2010
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?
More information about the freebsd-questions
mailing list