Alright. I admit it. I've been studying up how to improve my blog post titles. So let me give some disclaimers:
- (a) your OS is probably not about to self-destruct (but would you be ready for it if it did?)
- (b) this is only to do with AIX
- (c) you probably care about your career, so you're going to read on just in case
- (d) I've written blog posts and articles about this before (but I'm hoping you don't remember them). Here are four blog posts about the mksysb and how it can save your life:
- The AIX (junior) detective: When was the last mksysb?
- 'rm -r' and your career
- Ready for AIX Recovery with mksysb and mkdvd
- Can you recover rootvg without media or NIM?
But there's no harm rehashing content. Just call it rebranding. So here we go.
The mksysb you meant to do
You know that you should have a mksysb. You know that it's a backup of your AIX operating system. And that means every operating system that is important for your business. So unless you enjoy rebuilding your OS from scratch with senior people frowning and asking: "what's the ETA?" (isn't that the dumbest question an IT guy ever gets asked?), you'd better either have an up-to-date mksysb backup, or a high-tech random excuse generator.
Hint: just get a current mksysb.
How can you tell that you have one? More importantly, how can you tell that someone else's AIX system has an up-to-date mksysb backup?
Here comes the infallible sign.
Check the /image.data file.
What's the deal with /image.data?
When you create a mksysb backup, it creates a small text file called /image.data - in other words, you type in:
and then look at the date of the image.data file.
ls -l image.data
Now if you've never heard of that file, or never heard of the mksysb command, I suggest you go away and fix that now. Because if you lose your OS and can't recover it without a whole lot of avoidable pain, you're toast. And if you don't do something about that very soon, your OS may destroy itself. And you with it. Because you won't be ready for it. QED.
"But what about ... ?"
Alright. I did say that the /image.data file was an almost infallible sign of when your last mksysb backup was done.
You see, that file contains a list of the file systems in the root volume group (rootvg). The /image.data usually gets created as part of the mksysb backup. Except when it doesn't.
So usually, when a mksysb backup is run, you run it with the -i flag which creates an up-to-date /image.data file.
But maybe not ... reason #1: mksysb without the -i flag
But some people run the mksysb without the -i flag. A bit risky in my books. You see, file systems get increased. Or new ones get created. Yes, even in rootvg. You don't want to do a mksysb restore and find your target file systems are hopelessly inadequate for the mksysb data that needs to be restored.
So run the mksysb with the -i flag.
reason #2: the mkszfile command
In fact, that -i flag calls a script called mkszfile and yes, you can run that mkszfile command without running a mksysb. So your /image.data is looking good, but the mksysb backup hasn't been run. The lights are on but nobody's home.
reason #3: an alternate image.data file
Or, the mksysb backup could be run using an alternate image.data file. You can do that using the mkdvd command. You might do that because you are backing up from a rootvg that is on mirrored disk and only want to restore to a single LUN on the target.
reason #4: neat freak sys admin (thankfully rare)
Or you could run your mksysb backup with the -i flag, and then randomly remove or rename that /image.data file. But why would you? Because you like to keep your system clean and tidy?
Get the idea? If I come in to check your latest mksysb backup, you can probably deceive me by showing me your /image.data file.
Once more for the dummies
Do your mksysb backup. Schedule it. Test it. Restore from it. Time it. Document it. Hand it to someone else to recover when you're not available. If they do a good job, you're a hero. If they make a mess of it, you're indispensible.
Keep calm and do your mksysb.