[Dump-users] Problem with restore -r (and dump -m)

[Eric J. <eje...@sw...>]

Hi all,

Well, after six years of using dump every day, it finally paid off - had
a full disk failure, and we were able to restore almost everything
relatively straightforwardly.  So, thanks to Stelian for a nice program,
and to people on the list for useful support.

But... we seem to be having problems restoring the incremental backups
on top of the level 0.  It may be that there's something I don't
understand about how this works, but perhaps someone can help out.  

We have a level 0 and a level 2 (no intervening level 1) for the
partition in question; these dumps were made with dump 0.4b28-7 from
Redhat.  (I don't know if that "-7" after the 28 represents Redhat's
patches; they have a tendency to do things like that, though.  We've
since upgraded to 0.4b40 for the restore.)

To restore, we did the following:

1- reboot using Redhat EL AS (ver.3) CD in rescue mode
2- Used fdisk (v. 2.11y) to setup the partitions
   Note:  The partitioning of the drive changed between the dump and
          restore (we got a bigger replacement drive). The
          root partition is on the same device (/dev/sda2) and is
	  the same size as before, but it's not on the same sectors of
	  the disk due to other partitions changing size.
3- Used mkfs.ext3 (v. 1.32  09-Nov-2002) to make the filesystems.  Only
   option used was -L (label the filesystem).
4- Mounted /dev/sda2 on /mnt/root  Listing shows only lost+found directory
5- cd into /mnt/root   use mt to advance to the proper tape file.
6- run restore.static (v. 0.4b40):
   restore.static -r -b 64 -f user@tapehost:/dev/nst0
7- restoresymtable is created by the restore.
8- load the level 2 tape and advance to the right file (there is no
   level 1 dump for this partition)
9- run restore.static again:
   restore.static -r -b 64 -v -f user@tapehost:/dev/nst0
   (output from stdout and stderr are attached)

Problem: many files are missing after the level 2 restore.  stdout from
the level 2 restore shows many "file ... is metadata only", yet in some
cases that file is not in the level 0 backup (i.e., it was created
between the time of the level 0 and the level 2 dump).  There are also
many files being renamed where the original and final names have little
to do with one another.

Example output lines:

rename ./usr/share/config/language.codes to ./var/lib/ntp/drift
rename ./var/lib/xkb/README to ./var/lib/xkb/RSTTMP01273294
rename ./usr/X11R6/lib/X11/xkb/symbols/sun/us to ./var/lib/xkb/README
rename ./var/lib/menu/kde/Applications/.directory to ./var/lib/menu/kde/Applications/RSTTMP082279
rename ./usr/X11R6/lib/X11/fonts/100dpi/timR24.pcf.gz to ./var/lib/menu/kde/Applications/.directory

and so on.

Having gone through this, I belatedly thought of the "-m" flag to dump
(to optimize for backing up only metadata if that's all that has
changed).  I *know* that the level 2 was run with -m, since it is run
from a script.  But I ran the level 0 by hand, and I may not have used
the -m flag for that; in fact, I suspect I did not.  My naive
understanding is that it wouldn't matter, since the level 0 has got to
contain all the files anyway.  Would that cause such a problem?

A related scenario - if there are multiple level 2 dumps (again assuming
no level 1's as in my case), all with -m, does one need to restore all
of them (i.e. does only the first one have the real file data, and the
rest metadata)?  I wouldn't have thought so, but again, there's clearly
something I'm not getting here.

One more related question - if an RPM package installed after a level 0
installs a new file and sets its date to a date *before* the level 0
date, what will happen with that file in an incremental dump using -m ?
That does in fact appear to be the case for some (if not all) of the
"metadata only" files in the level 2 - they were installed after the
level 0, but have dates (as listed with 'ls -l') that are before the
level 0.  If this is the explanation for the "metadata only" problem, I
see why (and won't use -m in the future), but I still don't fully
understand the confusing renaming output above - it must be
inode-related at some level, but I'd like to understand it better. 

Thanks in advance for any answers and advice that anyone has.

Thanks,

Eric