• Please review our updated Terms and Rules here

Advice on backup/clone of AIX 3.2.5 on RS/6000 Model 320...

T

Thatsmanjear

Member
Joined
May 9, 2023
Messages
18
Hi. I have a mint IBM RS/6000 7012-320 that I have enjoyed using to recreate some software I wrote WAY back in 1990 in college. The HW and OS are all configured perfectly, so I want to be protected with a good backup so if/when the SCSI drives die I can continue on with a ZuluSCSI or SCSI2SD. I could use some advice. The machine is in a standard configuration that IBM sold back in 1990, it has one 400MB SCSI disk (SCSI ID 0), and a 320MB SCSI disk (SCSI ID 1). These two physical drives are combined to make a ~700MB root volume group (rootvg). Currently my setup uses about 500MB of storage, including paging file so it spans both of these disks. What I could use is some advice on a strategy for how to make simple backup of this rootvg so that it is easy to restore if one of these 33 year old SCSI drives dies. I use ZuluSCSI for a lot of my other vintage projects that require a SCSI drive, so ideally I'd like to just make a .img of the rootvg that I can then put on my ZuluSCSI and boot.

While I would prefer to just collapse the rootvg into one physical volume of a larger size, what I instead tried first was to just boot the system into maintenance mode from the AIX 3.2.5 installation CD, then make images of the two disks on an NFS drive, e.g.,

dd if=/dev/hdisk0 of=/nfs/backups/torreys/hdisk0.img bs=512K conv=noerror,sync
dd if=/dev/hdisk1 of=/nfs/backups/torreys/hdisk1.img bs=512K conv=noerror,sync

I then disconnected the physical SCSI drives, attached my ZuluSCSI with hdisk0, and hdisk1 images (renamed to HD0.img and HD1.img) and attempted to boot (key in service mode). After normal POST the system started to boot from the ZuluSCSI but then it sits a while on LED code 551 "IPL vary-on in running" then eventually stopping on LED code 552 "IPL vary-on failed".

So I then booted again from the maintenance CD and tried to import the root file system from the ZuluSCSI clones images and it shed some light on why the vary-on failed during boot:

# getrootfs
usage: /usr/sbin/getrootfs [-f] diskname
-f disregard status of hd5

Available disks: location:
hdisk0 00-01-00-00
# getrootfs hdisk0 sh
Importing Volume Group ...
PV Status: hdisk0 000005060b0b6196 PVMISSING
hdisk1 000000032641d6ba PVACTIVE
0516-052 varyonvg: Volume group cannot be varied on without a
quorum. More physical volumes in the group must be active.
Run diagnostics on inactive PVs.
0516-780 importvg: Unable to import volume group from hdisk0.

So it shows that hdisk0 is available at SCSI ID 0, but then when trying to import it says hdisk0 physical volume is "PVMISSING".

Question 1: Any ideas as to why this simply hdisk0 and hdisk1 clone strategy didn't work?

Question 2: Any better suggestions on what I'm trying to accomplish? Again, goal is to be able to do backups easily (like every week or so just make new images), so if/when physical drives die I have a somewhat recent clone.

I'd really like to just have one physical volume, say, 1GB, merge the two current PVs onto the single PV, and clone the single PV so I can just boot off my ZuluSCSI.
 
Would it be possible to tell lvm to mirror the two physical volumes to two LUNs (ie two different scsi ids) on a zuluscsi ?

Later versions of AIX allows to mirror a volume group on another PV, mirrorvg is the command in that case.

I know that i stretched my rootvg in my machine.
 
My first thought is that there might be a unique ID, such that even if you have the dd'ed image the boot loader or LVM stuff is still not able to determine that the first volume is legitimate. However you would need someone with more AIX knowledge than me to determine if that is the case.
 
stefan-lokeldarn said:
Would it be possible to tell lvm to mirror the two physical volumes to two LUNs (ie two different scsi ids) on a zuluscsi ?

Later versions of AIX allows to mirror a volume group on another PV, mirrorvg is the command in that case.

I know that i stretched my rootvg in my machine.
Click to expand...
Hi, I was thinking of this as well (extend, mirror then break), but got spooked at the idea of even touching the existing two physical volumes (or metadata about them either in OS files, NVRAM, etc). If I mess up those two disks I'll lose some software that I can't find anywhere to reinstall.
 
MrImprovement said:
My first thought is that there might be a unique ID, such that even if you have the dd'ed image the boot loader or LVM stuff is still not able to determine that the first volume is legitimate. However you would need someone with more AIX knowledge than me to determine if that is the case.
Click to expand...
That's where I am as well. AIX 3.2.5 has nice clean tools for backup/restore/clone from tape, and I can get a tape drive + 500MB worth of tapes for about $100, so that's where I'm heading!
 
Thatsmanjear said:
That's where I am as well. AIX 3.2.5 has nice clean tools for backup/restore/clone from tape, and I can get a tape drive + 500MB worth of tapes for about $100, so that's where I'm heading!
Click to expand...

How did you ever make out with this? I'm in a similar situation with a box running 3.2.5 and the case is locked so I can't remove the drive with damaging the lock.
 
epitaxial said:
How did you ever make out with this? I'm in a similar situation with a box running 3.2.5 and the case is locked so I can't remove the drive with damaging the lock.
Click to expand...
Hi, I used a Seagate 4/8GB 4mm DDS-2 SCSI Tape Drive (STD28000N) with mksysb to make a bootable tape image of the rootvg. I then tested restoring that to actual SCSI drives and it worked. I still can't restore to ZuluSCSI SD drives, which would be my preference, but I'm now resting easy knowing I won't lose the software on these drives. I connected the tape drive to the system using an external IBM SCSI cable that I had to find on EBay because it's a funky plug. It isn't a nice 50 or 68 pin plug regular or half-pitch. The IBM cable I got has sort of a T-connector at the end, the tape drive connects to one end of the T, and a terminator to the other side of the T.

I have a couple of RS/6000s that I did not have the key for. One of them (a POWERstation 220) I could just use a big slotted screwdriver and forcefully change the position of the lock between Normal, Secure and Service. My other two systems without keys I couldn't force with a screwdriver, so I had to use a small 1/8" drill bit to drill out the very center of the locks. The locks have three pins inside, and if you're careful you can drill out the lock and get those little pins removed. Then with the pins removed you can use just about any small key or just a small screwdriver to turn the lock accordingly. And if you drill carefully it doesn't destroy the aesthetic of the lock either, still looks like a keyslot in a lock. Just don't drill too deep and hit the electronics behind (don't go further than about 5/8" into the lock).
 
Hi, I used to work on these when they were new in the early 90s... Splitting rootvg across disks is obviously a risk as either disk going down takes out rootvg and it won't boot... With your mksysb restored to a larger disk, that is resolved now - so I would move to that installation as the default, if it is all working as it should. ZuluSCSI boards have a lot of configurable options (I use them on PDP-11 SCSI controllers) and I would start with the very latest firmware and see if you can get one working in addition to the single disk rootvg as an extra drive and volume group - don't add it to rootvg!

Once you can see it like that, you should be in a good position to boot a mksysb backup and restore to it...
 
You must log in or register to reply here.
Back
Top