ufsrestore root filesystem DR problem - SUN

This is a discussion on ufsrestore root filesystem DR problem - SUN ; Hi all, I have a mirrored disk system with Disksuite 4.2.1 and have OS backup root.dump and var.dump. I lost the both mirrored disks. Now I have 2 new disks reconfigured to original partitions, no OS installed yet and no ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: ufsrestore root filesystem DR problem

  1. ufsrestore root filesystem DR problem

    Hi all,

    I have a mirrored disk system with Disksuite 4.2.1 and have OS backup
    root.dump and var.dump. I lost the both mirrored disks.

    Now I have 2 new disks reconfigured to original partitions, no OS
    installed yet and no mirrored yet.
    Whenever I run #ufsrestore rvf /tmp/dsk/root.dump I go this error
    message:
    Volume is not in dump format

    I guess it is because the disk is not in the mirrored state while the
    OS dump file is (/dev/md/dsk/d0 if I use strings to check the dump
    file).

    How do I do DR on this system? TIA.

    Cong


  2. Re: ufsrestore root filesystem DR problem


    > Whenever I run #ufsrestore rvf /tmp/dsk/root.dump I go this error
    > message:
    > Volume is not in dump format


    It sounds as if the .dump file is corrupted. How did you make it?
    Did you ftp the dump file from another machine perhaps in "text"
    mode instead of binary?

  3. Re: ufsrestore root filesystem DR problem

    On Apr 26, 3:29 pm, Oscar del Rio wrote:
    > > Whenever I run #ufsrestore rvf /tmp/dsk/root.dump I go this error
    > > message:
    > > Volume is not in dump format

    >
    > It sounds as if the .dump file is corrupted. How did you make it?
    > Did you ftp the dump file from another machine perhaps in "text"
    > mode instead of binary?


    No. The dump file is good although I haven't got the chance to verify
    it yet since I was using the same exact syntax for all my other
    production Solaris systems. But the only tricky thing here is the dump
    file was taken while the system is in Disksuite mirrored state
    (strings root.dump |head shows device path as /dev/md/dsk/d0), and now
    I am restoring the dump file to a regular UFS file system. I googled
    around and don't seemed to have a straight answer yet. This is a
    typical DR case: when your system is burned down with your OS backup
    offsite, do you have to recreate the mirror (i.e. reinstall OS and
    setup mirror) again first before restore the OS dump file???? Hope
    someone had done this homework before and can share your experience
    with us. TIA.

    Best regards,

    Cong


  4. Re: ufsrestore root filesystem DR problem

    On Apr 27, 7:51 am, congshen888 wrote:
    > On Apr 26, 3:29 pm, Oscar del Rio wrote:
    > > > Whenever I run #ufsrestore rvf /tmp/dsk/root.dump I go this error
    > > > message:
    > > > Volume is not in dump format

    Then it isnt. No matter how mant times you run it.
    > > It sounds as if the .dump file is corrupted. How did you make it?
    > > Did you ftp the dump file from another machine perhaps in "text"
    > > mode instead of binary?

    > No. The dump file is good

    How do you know? It doesnt look like it.
    > although I haven't got the chance to verify

    Right. ufsrestore already did that for you already anyway
    Whatever you are working on apppears to be corrupted
    > it yet since I was using the same exact syntax for all my other
    > production Solaris systems.

    Maybe. Oscar is probably on to something. You arent working
    with the original dump seems like
    > But the only tricky thing here is the dump
    > file was taken while the system is in Disksuite mirrored state
    > (strings root.dump |head shows device path as /dev/md/dsk/d0), and now
    > I am restoring the dump file to a regular UFS file system.

    ??
    Unless DiskSuite is completely wacked this should no difference
    whether
    a filesystem is catonated, RAID5 RAID10 or RAID5+1
    ufsdump dumps filesystems and knows nothing about metadata overhead
    which is hopefully on another partition anyway.

    > I googled
    > around and don't seemed to have a straight answer yet. This is a
    > typical DR case: when your system is burned down with your OS backup
    > offsite, do you have to recreate the mirror (i.e. reinstall OS and
    > setup mirror) again first before restore the OS dump file????

    If you want things the way they WERE use the last full backup and then
    incrementals if any.. Then alter what DiskSuite does to system files
    to make a root mirror. Then you are up and running.
    Mirrors can be set up after the fact but that does
    require a reboot at least once.
    >Hope someone had done this homework before and can share your experience
    > with us. TIA.

    homework? Sounds like an assignment with a trick question for sure


  5. Re: ufsrestore root filesystem DR problem

    I'm not sure if this is your problem, but ufsdump should *always* be
    run on the raw device, /dev/md/rdsk/d0 in your case.

    There have been issues with using the block device with large
    filesystems.

  6. Re: ufsrestore root filesystem DR problem

    congshen888 wrote:
    > On Apr 26, 3:29 pm, Oscar del Rio wrote:
    >>> Whenever I run #ufsrestore rvf /tmp/dsk/root.dump I go this error
    >>> message:
    >>> Volume is not in dump format

    >> It sounds as if the .dump file is corrupted. How did you make it?
    >> Did you ftp the dump file from another machine perhaps in "text"
    >> mode instead of binary?

    >
    > No. The dump file is good although I haven't got the chance to verify
    > it yet since I was using the same exact syntax for all my other
    > production Solaris systems. But the only tricky thing here is the dump
    > file was taken while the system is in Disksuite mirrored state
    > (strings root.dump |head shows device path as /dev/md/dsk/d0), and now
    > I am restoring the dump file to a regular UFS file system.


    ufsrestore does not care where you are restoring, it could be a NFS mount,
    a tmpfs, even a floppy.

    The string in the dump file is just FYI (for ufsrestore "what" command).
    If the dump file got corrupted (e.g. text instead of binary ftp)
    you would still see the string but ufsrestore cannot parse the dump file.

  7. Re: ufsrestore root filesystem DR problem

    On 2007-04-27, congshen888 wrote:
    > On Apr 26, 3:29 pm, Oscar del Rio wrote:
    >> > Whenever I run #ufsrestore rvf /tmp/dsk/root.dump I go this error
    >> > message:
    >> > Volume is not in dump format

    >>
    >> It sounds as if the .dump file is corrupted. How did you make it?
    >> Did you ftp the dump file from another machine perhaps in "text"
    >> mode instead of binary?

    >
    > No. The dump file is good although I haven't got the chance to verify
    > it yet since I was using the same exact syntax for all my other
    > production Solaris systems. But the only tricky thing here is the dump
    > file was taken while the system is in Disksuite mirrored state
    > (strings root.dump |head shows device path as /dev/md/dsk/d0), and now
    > I am restoring the dump file to a regular UFS file system. I googled
    > around and don't seemed to have a straight answer yet. This is a
    > typical DR case: when your system is burned down with your OS backup
    > offsite, do you have to recreate the mirror (i.e. reinstall OS and
    > setup mirror) again first before restore the OS dump file???? Hope
    > someone had done this homework before and can share your experience
    > with us. TIA.
    >


    I've restored ufsdumps from mirrored fs to non-mirrored filesystem
    without trouble.

    Are you able to read archive contents with ufsrestore tf /path/to/archive.dump?

    --
    staf



  8. Re: ufsrestore root filesystem DR problem

    On 2007-04-27 15:51:54 +0100, congshen888 said:

    > No. The dump file is good although I haven't got the chance to verify
    > it yet since I was using the same exact syntax for all my other
    > production Solaris systems.


    I think the evidence is that it isn't good. If I were you I'd have a
    check around the other dump images using ufsrestore tf on them: you may
    not have as many good ones as you think...


+ Reply to Thread