[SUMMARY] Dump or restore dropping/missing files?

The question:
> 
> $ uname -a
> SunOS jimsun 5.7 Generic_106541-29 sun4u sparc SUNW,UltraSPARC-IIi-Engine
> 
> Trying to upgrade the system from a Seagate ST39175LW (9GB) to an
> ST318436LW (18GB).  Created the slices on the new drive, then ran a
> script to, one-by-one:
> 
>     . Create the new filesystems with newfs
> 
>     . Use the following to "clone" the old, smaller partitions to the
>       new, larger ones:
> 
>       mount /dev/dsk/$dst /mnt || exit
>       cd /mnt || exit
>       ufsdump 0f - /dev/rdsk/$src |ufsrestore xf -
> 
> This mechanism (which is in a script) worked fine on a 2.5.1 system I
> did this with not long ago, but this time I'm having something *very*
> strange happen: The cloned filesystems are missing seemingly random
> files.  (How did Sun manage to break dump/restore?)
> 
> Has anybody seen this before?  Any (other) suggestions on how I might
> faithfully clone one (smaller) filesystem into a larger space w/o
> having to worry about mount-point traversal and so-on?

Several suggestions that I should be using "r", rather than "x" for the
restore.  All the suggestions/examples I've seen on-line use "x" and,
looking at the manpage, "x" should be fine for this application.
Nonetheless, I tried it with "r" in place of "x", with the same
results.

One question as to whether the missing files were active at the time of
the "cloning."  No, this was done in single-user mode.

One suggestion for using gnu tar, instead of ufsdump/ufsrestore.  (I'll
file that one for future reference.)

The solution was to apply patch 106793-07.  Though the patch docs don't
mention my symptoms exactly, some looked "close enough" to warrant
trying it.

I noticed something on one directory that was missing better than half
its files.  After applying the patch, I tested with just one
filesystem  After a certain amount of time into the process, the
directory in question had the same contents as it had on the other
tries.  I assumed the patch had had no effect.  But by the time the
ufsdump/ufsrestore was finished, the directory was complete.

I verified that the entire filesystem was complete by doing a
file-by-file and directory-by-directory compare between the source and
destination filesystems.  After re-running the script to clone the
entire set of filesystems, I ran tripwire in check mode to verify that
nothing was missing and the only things that had changed were things
that were supposed to have changed (e.g.: /etc/vfstab).

So there you have it: Under Solaris 7, ufsdump/ufsrestore with patch
106793-05 (or earlier?) would seem to be seriously broken.

Thanks to Anthony D'Atri, Ric Anderson, Osvaldo Carvalho de Santana and
Casper Dik for their replies.

I do *so* hope Jeffrey Dunn, Navi Sirisena, Roland Merk, Dietmar
Swoboda, Dave D Ballesteros and Stephen Moccio are enjoying their time
away from the office.  Perhaps Santa will bring them each proper email
systems for Christmas ;).

Regards,
Jim
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers