[SUMMARY] Dump or restore dropping/missing files?

From: Jim Seymour (jseymour_at_linxnet.com)
Date: 12/19/04

  • Next message: ert weerr: "Raid Manager 6 error messages" 
    To: sunmanagers@sunmanagers.org
Date: Sun, 19 Dec 2004 17:23:11 -0500 (EST)

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

  • Next message: ert weerr: "Raid Manager 6 error messages"
    • Quantcast