Booting from backup - old batch jobs

[John Gillings]

Both Ian and Bob may be correct, depending on circumstances...

A completely automated startup may be appropriate. Consider, if your site loses power. When it comes back, do you want/need all your OpenVMS systems to come back on line unattended? If it's a self contained environment, that may be appropriate

On the other hand, if you're one lobe of a multi site data centre, most of the time you DO NOT want systems to boot unattended. If you have shadow set members on multiple sites, booting in the wrong order, or booting without communications to a site which is still live can potentially corrupt data bases. In this case you want to have a human make the decision as to when and how a system is booted.

Regardless, if you value your data, you should have a procedures manual (on paper) which documents the startup, shutdown and recovery procedures under a variety of scenarios. For "simple" systems it doesn't have to be highly detailed, but the effort taken should at least reflect the value of your the system to your corporation.

[Duane Sadowski]

Thanks for the additional comments, Bob and John.

I'm mulling over what John Gillings wrote in his first message, and I'm thinking about the specific scenario that John just presented. Suppose a standalone VMS system is running and a batch job is executing, when the system goes down during a weekend because of an electrical blackout. I'm wondering whether in this scenario a VMS system (in my case, a standalone AlphaServer 2100A) will boot by itself when power comes back up and start running batch jobs - perhaps batch jobs that depend on the successful completion of the job that bombed when the system went down.

I see that there's a console variable called auto_action. If I'm interpreting the documentation correctly, I could set its value to HALT if I'm concerned about this particular scenario. (I just checked the value of this on the running system, by using F$GETENV, and I see that it currently has the value BOOT.)

However, I'm wondering if setting auto_action to HALT would mean that someone would have to travel to the computer site to boot the system. (I recall that some people here told me previously about the ability to connect the AlphaServer console to a DECserver, which if I understand things correctly, would permit remote access if I can telnet into the DECserver.)

- Duane

[Ian Miller.]

If you don't start the batch queues then the batch job will not restart. If your batch queues are not autostart enabled then they wont start until explictly started. This can be a useful control. Autostart queues start when the AUTOSTART ENABLE command is executed (usually in SYSTARTUP_VMS).

Having a DECserver connected to the console port is invaluable. A DECserver 700, or DECserver 90 both allow telnet. A DECserver that can boot from internal flash memory is recommended as it will not need a load host after a powerdown.

[Wim Van den Wyngaert]

I wonder if there are other things to verify except queues (e.g. restored on another system with other hardware names, is db recovery to be applied, ...).

Anyway ...

Our system has a list of everything that will be started and you can indicate where to stop the startup.

E.g. stop after startup of network (but before applications and middleware).

So, we should have to do a minimal boot, change the file and continue.

But we still didn't do the restore test.

Wim

[Robert Gezelter]

Duane,

Your reasoning is why I mentioned the USERx parameters.

You can leave the automatic boot enabled, and bring the system up in whatever safe state is desired (e.g., any combination of batch queues stopped, shadow sets unmounted, applications down). But, you DO have a running system at that point.

Unless you have set up a secure access to the console LAN (where the server providing telnet access to the console is), then you have a whole new area of security vulnerability. My preference is to bring up the system in such a case. Then you are able to use all the features of your security system.

In the case of OpenVMS clusters, this does require some care. Partitioned clusters can occur if parameters relating to cluster quorum are not set correctly. This is particularly a danger if during an emergency, parameters are altered. Personally, I prefer to have pre-planned alternative boot roots on the system disk, to deal with different situations. The most errors occur when changes are made in haste under pressure.

Just my US$ 0.02.

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Duane,

did I ever agree with Bob!

When things are going well, it is all so easy.

But, _WHEN_ thing are derailing, it is better to STOP first thing, and go forward from there ever so carefull.

Remember: time lost is a (maybe big) nuisance, but data corrupted takes orders of magnitude more time to detect, sort out, and repair. In that case the words that replace "nuisance" in the above sentence are not fit for this forum!

Proost.

Have one on me.

jpe

[Duane Sadowski]

Thanks to those who elaborated on things they and others wrote previously. I will be discussing with the people with whom I work the things that you shared with me, voicing questions about our current philosophy and practices.

- Duane

[Duane Sadowski]

Thanks again to those who answered my questions.