Edit: The link no longer works.
Originally posted June 28, 2011 on AIXchange
In the “good old days” of AIX administration, companies had standalone servers, and rootvg lived on internal disks. We always had at least one pair of internal disks, mirroring them to one another. In the event of a disk failure, you’d unmirror the disks and then replace the failing/failed disk. This was usually accomplished on the fly with hot swap disks. Typically the end users never even knew there was a problem.
Those who still run servers on physical internal disks still need to make sure that they’re mirrored in the event a disk needs to be replaced. But even with companies that have moved on to virtualization technology, much of this thinking is preserved today with dual VIO servers and virtual SCSI devices. If you lose one physical path to the storage, the VIO client uses the path provided by the redundant VIOS to keep running.
Most customers I work with these days boot their LPARs (I know, I’m supposed to call them virtual servers, but old habits are hard to break) from SAN. The disk protection and physical disk replacement happens on the back end with a SAN team. Although I do see customers where the SAN guy and the AIX admin are the same person, in all cases the data protection occurs behind the scenes as far as AIX is concerned. The hdisk isn’t affected as far as the OS knows.
When installing your VIOS and booting it from internal disks, it’s still a good idea to mirror that disk to the other internal disk that’s assigned to the same bus on the VIOS. With split backplanes and dual VIO servers, this thinking just needs to be taken a step further: be sure to mirror all of the disks on all of your VIO servers, assuming they’re booting locally.
To help in this regard, VIOS has a built-in command called called mirrorios. When you run it, you’ll be prompted to reboot your machine when the mirror operation completes. However, that can be deferred by simply running the command, mirrorios –defer.
When this command completes, check your bootlist. You’ll find that it hasn’t been updated with the disk that you just mirrored to. To remedy this, you must manually run a bosboot on the new disk you mirrored to, and then update your bootlist to reflect the change. If you’re wondering why mirrorios can’t perform both steps, you’re not alone. This is supposed to be an appliance, after all.
So what other methods do you use to protect your data? Surely you take mksysb images and backup your system using TSM or some other method. This of course, brings up the familiar but important question: Have you tested your restore procedures lately? Are you sure they work?
Finally, have you made sure your VIO servers are set up correctly? As with a high availability cluster, the wrong time to find out that things aren’t set up correctly is when you really need them to work.