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

[Stelian P. <st...@po...>]

On Thu, 2005-05-26 at 15:35 -0400, Eric Jensen wrote:

> 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.

This doesn't matter at all for restore. Restore works in regular
filesystem space, meaning it is using regular syscalls to restore the
files. So it doesn't matter if the target filesystem has a different
size, or is located on another partition. All that matters is that it
must have enough space to contain the files to restore.
 
> 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)

All this seems correct.

> 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.

'Final' names ? Do you mean that at the end of restore you end up with
files/dirs called 'RSTTMP...' ? 

If this is the case, then this is clearly a malfunction.

If this is not the case, then the messages are part of the normal
restore process. Remember that restore works with inode *numbers*, and
it is very possible that the inode *number* destination changed between
the 2 dumps (the inode was freed then reallocated to a new file). This
is what you see as a 'rename' in the output.

Example: in the 0-level dump you had ino #42
containing ./usr/X11R6/lib/X11/xkb/symbols/sun/us. For some reason this
file was removed, and the ino #42 was allocated to ./var/lib/xkb/README.
So the 2-level dump contains information about this 'rename'.

Check the contents of /var/lib/xkb/README. If it is correct then all is
good.

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

No. The level 0 contains all the files.

> 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.

No, each subsequent level 2 dump replaces the information contained in
the previous one.

> 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), 

I think you did indeed find the issue here. Instead of 'ls -l' do a
'stat' on the incriminated files and check the 'mtime'. Regular dump
looks at both 'ctime' and 'mtime', dump -m looks only at 'mtime'.

> 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. 

See above.

Stelian.
-- 
Stelian Pop <st...@po...>