Re: Using mksysb at DR Site

From: Green, Simon (Simon.Green_at_EU.ALTRIA.COM)
Date: 05/27/04

  • Next message: Green, Simon: "Removing excessive print jobs" 
    Date:         Thu, 27 May 2004 13:00:11 +0200
To: aix-l@Princeton.EDU

    Here are some more thoughts, having seen Bill's post.

    When I first started, I used to re-build the other VGs using savevg/restvg.

    You do a savevg using an exclude file containing "/*". This doesn't back up
    any data, and you end up with a 50kB file, or there abouts. (Back it up to
    a filesystem in rootvg, so it's included in your mksysb.)

    Then do a restvg from this file, and you get an empty Volume Group, ready
    for TSM (or whatever) to restore your data.

    This is a very simple method, but has some limitations.

    DR sites tend not to have exactly the same hardware. So maybe you've got
    36GB SSA disks, and they've got some sort of SCSI array with 18GB disks.
    Not a big deal, if you've got the same disk space in total. Except that if
    your external VG has 30 36GB disks, it would need 60 18GB disks, which is
    more than a normal VG can handle. So either you have to split the VG in two
    - which means more effort - or you have to convert to BigVGs, which will
    cost you a lot of time. (It just takes a lot longer to create filesystems
    in a BigVG. They're horrible, but sometimes convenient.)

    Long term, having some sort of scripts which can re-build filesystems and
    are not dependent on particular VGs will be helpful. savevg/restvg WILL be
    quicker, but as I said: it's limited.

    Don't stint on the information you collect in advance. On my systems I have
    a small filesystem in rootvg which contains the savevg output and also
    output from lsvg and anything else I can think of. I have a script which
    runs just before the mksysb to re-create all of this information, so it's up
    to date. The basics are lsvg and lsvg -l for each VG, and lsfs -q for each
    filesystem. You'll want network info as well.

    Oh! Something else I just remembered: make absolutely certain that you
    don't have any hard NFS mounts. Everything should be a soft, interruptible
    mount or you may find that the first boot at the recovery site takes
    forever. Check regularly: it only takes one careless administrator to add a
    couple of hours to your recovery time.

    DR tests can be an awful lot of work, but they're an invaluable opportunity
    to learn about the system. 

    --
Simon Green
Altria ITSC Europe Ltd
AIX-L Archive at https://new-lists.princeton.edu/listserv/aix-l.html
New to AIX? http://publib-b.boulder.ibm.com/redbooks.nsf/portals/UNIX
N.B. Unsolicited email from vendors will not be appreciated.
Please post all follow-ups to the list.
  • Next message: Green, Simon: "Removing excessive print jobs"