Opinions: root mirror recovery
Bliss, Kevin L
bliss.kevin@emeryworld.com
Mon, 19 Jul 1999 20:35:33 -0000
We use VM to mirror the root disk and I have replaced failed root disks more
than once. I don't see a problem with VM. Yes, you do need a prtvtoc of
the root disk and yes you do need to do a couple of reboots of the server to
be back to the original configuration (this can be done at your convenience
if you were mirrored, as you will be running on the mirror). This low level
information should be something that you are keeping copies of anyway, for
true disaster recovery (this is true no matter how you decide to handle root
disk failures).
If you are mirrored using VM and your root drive fails you should stay up
and running on the mirror. VM should notify you that the disk has failed.
You follow the directions for removing and replacing the disk. Once the
disk is replaced, format the drive using the prtvtoc you have saved. Now
there are different ways to get where you want to be (restore from tape and
encapsulate, your preferred copy method and encapsulate, or my preference -
remirror). To remirror, at a convenient time (probably scheduled with
users/management) you encapsulate the disk. After the required reboots for
encapsulation, drag the plexes out of the new bogus volumes (created by the
re-encapsulation) and drop them in the corresponding original volumes. One
the mirrors sync you are back to normal.
If you are as anal as my company you can create your root disk mirror in
this fashion and have both sides of your mirror be encapsulated partitions.
For our critical servers we have 3 of these encapsulated partitioned disks.
One is separated (mirror broken) most of the time, and is mirrored and
broken nightly. This provides the protection of having a mirror active at
all times to protect in the event of hardware failure and a broken mirror to
protect in the event of corruption (unless the corruption just happens to
occur while this mirror is attached for update, then, it is restore time).
For disaster recovery you should be keeping copies of lots of information
including: vfstab, prtvtoc of all partitioned disks, output of vxdisk list,
vxprint -ht, vxprint -g diskgroupname -vpshmQq (for each disk group) as well
as a significant amount of other system related information. This data
should be updated frequently so that it is current.
> -----Original Message-----
> From: Ray Voight - Commercial SE McLean VA [SMTP:Ray.Voight@East.Sun.COM]
> Sent: Wednesday, July 14, 1999 6:13 AM
> To: bulmer@theALLIEDgroup.com; Stuart.Remphrey@Aus.Sun.COM
> Cc: Robert.Cross@scottish-newcastle.co.uk; ssa-managers@Eng.Auburn.EDU
> Subject: Re: Opinions: root mirror recovery
>
> Quick note:
>
> Several customers are big fans of the disk copy protection scheme, and
> in certain cases I absolutely agree. But dd will copy the maps from
> one disk to another. The scripts written around ufsdump/ufsrestore are
> a better practice.
>
> HIH,
>
> Ray
>
>
> >X-Authentication-Warning: dns.eng.auburn.edu: majordom set sender to
> owner-ssa-managers@Eng.Auburn.Edu using -f
> >Date: Wed, 14 Jul 1999 20:36:35 +1000 (EST)
> >From: Stuart Remphrey - Sun Computer Systems SE - QLD Australia
> <Stuart.Remphrey@Aus.Sun.COM>
> >Subject: Re: Opinions: root mirror recovery
> >To: Steve Bulmer <bulmer@theALLIEDgroup.com>
> >Cc: Robert.Cross@scottish-newcastle.co.uk, ssa-managers@Eng.Auburn.EDU
> >MIME-Version: 1.0
> >X-Info: To unsubscribe, send 'unsubscribe ssa-managers' to
> majordomo@Eng.Auburn.EDU in message body
> >
> >Steve,
> >
> >On your last point, yes I've also seen this (dd or cpio -p or
> ufsdump|ufsrestore).
> >Has the advantage if say done overnight with cron that it guards against
> >"finger trouble" by the sysadmin, deleting the wrong file etc.
> >
> >These days with 9 GB system disks one could consider loading Solaris onto
> >3 partitions at the front of the disk (maybe /, /var and /opt ??); having
> >a copy to another 3 at the back of the disk; having a metadb replica
> slice;
> >and mirroring the lot with DiskSuite.
> >
> >Doing the same with SEVM/VxVM could also be done, though it can be more
> >complicated to recover/upgrade. Might reduce partition limit though?
> >(questionable if encapsulated vs initialised)
> >
> >Rdgs,
> >
> >Stuart.
> >
> >
> >` As a practice, we take a prtvtoc of the system disks before we
> encapsulate
> >` so you can get the low level partition table in the event of an
> emergency.
> >`
> >` Be aware of a couple things, primarily you can only get to the raw
> >` partititions on the encapsulated disk. We've seen sites where the
> "primary"
> >` (encapsulated) boot drive fails and is replaced and synched to the
> remaining
> >` mirror. Once this is done, there is no going back to the original
> partitions
> >` for DR or even a Solaris upgrade. At this point, be sure to have good
> >` ufsdumps of the OS as you will need them.
> >`
> >` The other thing is that if you are looking at Disksuite, it really does
> keep
> >` everything in the pre-determined partitions making recovery easier.
> Using DS
> >` to mirror your boot drives means you will need at least another disk
> for the
> >` VXVM/SEVM rootdg (or at least a partitition).
> >`
> >` As someone else mentioned, there is no golden rule. I have even seen
> sites
> >` which "dd" there OS disk to another hard drive for safe keeping.
> >`
> >` Steve
> >`
> >` Robert.Cross@scottish-newcastle.co.uk wrote:
> >`
> >` > Small question for all the experts out there.
> >` >
> >` > We have an E4000 here with an attached SSA114, running Volume Manager
> 2.6.
> >` Now, > for
> >` > resiliancy/performance reasons I've encapsulated and mirrored the
> root
> >` volume, > one copy
> >` > on a SCSI disk tray, and another on the SSA itself.
> >` >
> >` > Talking to one of our Disaster Recovery suppliers yesterday, and he
> was
> >` saying > that he's been told
> >` > that if the root volume gets trashed, it's very difficult to recover
> the
> >` system > if the root volume is under
> >` > VM control. He's further been told that it's actually better to
> install
> >` > DiskSuite from the Solaris 2.6 CD,
> >` > and use THAT to mirror the root volume. The problem with VM is that
> >` apparently > to recover rootvol
> >` > you need to know what the low level organisation of the disk is. This
> >` > information was given to him
> >` > by a lecturer on a Sun Volume Manager course he attended recently.
> >` >
> >` > Has anyone out there got any experience or opinions one way or
> another on
> >` this? >
> >` > Thanks
> >` >
> >` > Robert Cross, Systems Programmer, Scottish & Newcastle plc.
> >` >
> >` >
> **********************************************************************
> >` > The information contained in this message and any attachments:
> >` >
> >` > 1. does not constitute an offer or an acceptance of an offer or a
> >` > representation or warranty, nor shall it form any part of a legally
> >` > binding contract.
> >` >
> >` > 2. has been compiled with care but no representation or warranty
> >` > (express or implied) is made as to its accuracy or completeness and
> no
> >` > liability can be accepted for any loss arising from the use of any of
> >` > the information.
> >` >
> >` > 3. may include opinions or views, which unless expressly stated
> >` > otherwise, are not those of the company or any person in relation to
> >` > whom the company would have vicarious liability or responsibility.
> >` >
> >` > 4. is not guaranteed to be free from any so-called computer viruses
> >` > and it is strongly recommended that you check for such viruses before
> >` > down-loading it to your computer equipment.
> >` >
> >` > 5. may include hypertext links to the sites of other companies or
> >` > persons, the content of which this company has no control over and
> >` > accepts no liability for.
> >` >
> >` > 6. is for the exclusive use of the addressee and may contain
> confidential,
> >` > privileged, work product immunity and/or non-disclosable information.
> >` > If you are not the intended recipient and receive this message and
> any
> >` > attachments, you must not read, copy, transmit, disclose or otherwise
> use
> >` > any of them (or part of them) in any way (to do so may be unlawful)
> and
> >` > we would be grateful if you could inform us immediately of any such
> >` > receipt and subsequently entirely and permanently erase the message
> and
> >` > any attachments from your equipment.
> >` >
> >` > E-mail is an informal method of communication and is subject to
> >` > possible data corruption. For these reasons it will normally be
> >` > inappropriate to rely upon information contained in an e-mail without
> >` > obtaining tangible written confirmation of it.
> >` >
> **********************************************************************
> >`
> >
> >
> >
> >---------------------------------------------------------------------
> > ,-_|\ Sun Microsystems Australia Stuart Remphrey, Systems Engineer
> >/ # P.O. Box 86, Albert St stuart.remphrey@Aus.Sun.COM x.56308
> >\_,-\_/ Level 10, 80 Albert St Ph (07) 3238 8308 Fax (07) 3238 8320
> > v Brisbane QLD 4002 +61 7 3238 8308 +61 7 3238 8320
> >---------------------------------------------------------------------
> >
> >