[dwolf]

I've set up my NIM master and am taking weekly mksysb's of my standalone clients. These mksysb's are placed in my /export/mksysb filesystem which is part of my rootvg. So far, so good. As my AIX farm continues to grow, so does my /export/mksysb. So now I need to put maintenance on my NIM server. I'm a big fan of alt_disk_install and when running phase 1 to clone my rootvg, I realize how much it has grown due to the number if mksysb images that are now stored. Of course my target disks for phase 1 are now much too small to hold the rootvg clone. I do have some SAN attached disk and am considering moving to that. Has anyone else run into this situation or do I need to reconfigure something?

TIA

[kierong]

View the manpage for alt_disk_install and look at the -e option to exclude /exports/mksysb as long as you have the mksysb's backed up via some other method you can always recover them. We keep our mksysb's on a seperate volume group backed by san attached storage. We like to keeo rootvg small.

[dwolf]

Thanks for the reply. That sounds like the solution. I think I'll exclude the mksysb's for now and then look at moving them to a new vg on my san.

[duke900ssd]

You should also consider the merit of weekly mksysb.

If you keep all the old ones (with the associated passwords), no problem.

If you don't keep all the old ones but reboot just before or after each mksysb, also no problem.

Either way you only stand to lose a weeks work.

If you never reboot but take weekly mksysb without keeping the old ones, nightmare.

A problem creeps in, you don't notice because you haven't rebooted in ages. You, or the power distribution, reboots one day and the system fails to come up. Panic. Restore mksysb - but the problem occurred way before your oldest mksysb....

It is all very well taking lots of mksysbs but unless you KNOW they can be restored they are still a gamble rather than a viable backup solution.

[dwolf]

Interesting. Yes, I am taking weekly mksysbs. No, I'm not keeping the old ones. Are you suggesting that the last mksysb might be bad due to some some OS issue that occurred prior to the backup? And that a failed reboot/mksysb restore might find that mksysb unuseable? As my mksysb's have time/date stamp filenames, I could use TSM to keep these longterm on tape.

Thanks for your comment. I'll give this some thought.

[duke900ssd]

With the long uptime of some systems (months, years even, some machines only get a reboot when they are upgraded) and the things that change in that uptime, dynamic reconfiguration commands, tuning of one sort or another, device reconfiguration along with deleting and reconfiguring the device on the fly, odd errors seemingly repaired without a reboot, etc.

You can find a system is still running fine but will fail on the next boot because some inconsistencies have crept in, maybe between the ODM and LVM config for example, stuff that is never checked during runtime.

These things are only properly checked when a system boots, and if there is a problem then it won't boot :-( all you have been doing is backing up the problem, and when you need the system back up in a hurry you are then faced with sorting out the problem that you could have spotted near the time it happened and fixed it rather than months later when you no longer have a recent restore option to fall back on.

There was an industry wide backup strategy survey a while ago and they reported that only 50% of business had a viable backup strategy and of those only 50% actually stood a good chance of a viable recovery. Makes you think. Odds are that even if you think you have everything covered the chances are that you only have a 25% chance of recovering your system without major hassle.

Think outside the box on this one.

Do DR testing...you know it makes sense and you'll spend a lot more weekends and nights at home in the long run.

Sorry, getting off topic here.

I'd keep the nim master small and clean, stick all the nim resource on another system / LPAR - nfs capable machine, san vg, whatever. Don't complicate your nim environment. If you need to restore the nim master the last thing you need is to have to restore all the resource too.

Nice data vg, safe environment like a set of mirrored or raided san disks that allow you to have the master catch fire and all you need is any aix machine that you can configure as a master and all the resource is sitting there waiting to be imported. Then you are installing the rest of the environment in no time

Of course you'd also want a backup of the resources, regularly carried off site in tape form or via a fibre or network link, in case the san goes up in flames with the master :-)

Off topic again...

On that note....I used to know a chap that thought it was OK to take the backup tapes home. Nice, easy, safe, off site storage. He put them in a shopping bag - never transport tapes like this because they get a knock, the tape is compressed against the edge of the cartridge shell and the edge of the tape gets damaged then the drive has a really hard time reading them, if it can at all. Anyway, he took his bag of tapes home on the London underground. He got on the train, found a seat - obviously a long time ago - and sat down to read his newspaper, with the shopping bag sitting snugly between his feet. Being shaken and vibrated by the floor of the tube train. Just under the wooden or aluminium floor of his seat there was.... A BL**DY GREAT ELECTRO MAGNET, the motor that made the train go along....

You get the idea. Think, plan, get out of the box and do it all again. Then test it all, twice if you like your sleep, weekends, job, etc. etc.

[ross.mather]

In other words what is the reason we make backups? To be able to restore them! If you make mksysbs on a regular basis then restore them to a test lpar to verify that they still work!

What you can do with TSM is make your mksysbs locally and write them to tape - best practice is actually not to use a hostname/date timestamp and let TSM maintain the last 4 or 5 versions.

Within TSm enable the NIM server to retrieve the mksysb from all servers and if needed can be retrieved from tape. It of course goes without saying that any restore test starts by retrieving from tape.

And think abot where TSM Server, NIIM Server and VIO Servers are backed up to in the evnt of a disaster - they do happen, be prepared.