Port-i386 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Mounting a dump file



>> dump(8) has race conditions when used to dump live filesystems: it's
>> possible to get skew between what dump reads at one point and what
>> it reads at a later point.
> In short, dump(8) isn't a good solution to backup a live file system
> ?

It can be.  Only certain kinds of inconsistencies are possible, and,
while some of them produce warning messages such as you reported, dump
and restore are prepared to deal with them.

There _are_ other options; depending on your tradeoffs, one of them
might be better.

> What are the alternative ?

One is to get help from the kernel.  Either use a different filesystem,
one which has support for such things in it, or use something like
filesystem snapshots to get a consistent view of the filesystem.

Another is to go entirely through the filesystem interfaces.  Programs
like tar and pax do this; their major downsides are that they don't get
sparse files entirely right and they usually can't help touching ctimes
and/or atimes for files.

I even once built a sort of unholy hybrid of the two approaches, a tar
which read the raw disk to get file contents.  I did this back when
Elizabeth Zwicky's paper on torture-testing backup programs was new; I
spent a good deal of time running it with her tests and fixing bugs
until I got it to the point where it passed all the static tests and
did as well as could be expected on the dynamic tests.  A site I know
actually used it for their backups for some years.  (It's
filesystem-specific, of course (FFSv1 in its case).  But anyone who
wants is welcome to a copy; git://git.rodents-montreal.org/mtar, or if
a git repo is no help let me know so we can work out something else.
You can ignore the build machinery in the repo and just compile mtar.c;
read the comment header first, though.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index