RE: Does anyone shut down for system disk backup any more?
From: Bochnik, William J (William_Bochnik_at_acml.com)
Date: 11/06/03
- Next message: Bob Koehler: "Re: VUP?"
- Previous message: Bob Koehler: "Re: Piping X-Windows traffic over ssh on OpenVMS"
- Maybe in reply to: Scott Vieth: "Does anyone shut down for system disk backup any more?"
- Next in thread: Wayne Sewell: "Re: Does anyone shut down for system disk backup any more?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 6 Nov 2003 08:42:31 -0500
not to split hairs, but unless you do a periodic restore to another disk,
you are always reasonably sure your backups are ok, not 100%. Things
happen. Tapes go bad, hidden issues with the backup or restore procedures
go unnoticed, etc.
-----Original Message-----
From: Mike Rechtman [mailto:michael.rechtman@hp.com]
Sent: Thursday, November 06, 2003 5:09 AM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: Does anyone shut down for system disk backup any more?
JF Mezei wrote:
>
> > >> An interesting experiment would be to find an old disk with an
> > >> easily accessible "write protect" button on the outside. Boot up
> > >> VMS from such a disk, get your applications going (yes, even if
> > >> they are on a different disk), and then write protect your system
> > >> disk.
>
> The audit server would get mighty mad at not being able to write its
> logs and probably freeze the system. OPCOM woudl also get mighty mad
> with inability to write to operator.log, and the queue manager would
> also complain bitterly. You woudln't have a happy family :-)
I've tried something similar - actually I was trying to build a minimal
OpenVMS system on a CD - If SYSUAF.DAT is not writeable you cannot login.
SYSUAF is also a file I have seen corrupted after a restore from backup done
with /IGNORE=INTERLOCK. You always have _some_ applications on the system
disk - they're put there when you install OpenVMS. They're just not 3-rd
party. To quiesce the system disk sufficiently to close all
files/applications you might as well shutdown
Basic question has already been asked: If your system is critical enough to
be up 24x365, then surely you should be _entirely_ sure of the quality of
your backups, not 'reasonably' sure? Of course you could always restore a
previous backup, and and one previous to that ... until you hit a good one,
with a decreasing risk of failure. But it sounds inconvenient and open to
error.
Mike
-- --------------------------------------------------------------------- Usual disclaimer: All opinions are mine alone, perhaps not even that. Mike Rechtman *rechtman@tzora.co.il* Kibbutz Tzor'a. Voice (home): 972-2-9908337 "20% of a job takes 80% of the time, the rest takes another 80%" --------------------------------------------------------------------- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCM/CS d(-)pu s:+>:- a++ C++ U-- L-- W++ N++ K? w--- V+++$ PS+ PE-- t 5? X- tv-- b+ DI+ D-- G e++ h--- r+++ y+++@ ------END GEEK CODE BLOCK------ ----------------------------------------- The information contained in this transmission may contain privileged and confidential information and is intended only for the use of the person(s) named above. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message. Please note that we do not accept account orders and/or instructions by e-mail, and therefore will not be responsible for carrying out such orders and/or instructions.
- Next message: Bob Koehler: "Re: VUP?"
- Previous message: Bob Koehler: "Re: Piping X-Windows traffic over ssh on OpenVMS"
- Maybe in reply to: Scott Vieth: "Does anyone shut down for system disk backup any more?"
- Next in thread: Wayne Sewell: "Re: Does anyone shut down for system disk backup any more?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]