[comp.os.vms] System backups

leichter@VENUS.YCC.YALE.EDU.UUCP (09/12/87)

After a correct description of standalone BACKUP, the author continues:

	On the other hand, you don't necessarily need a standalone backup.
	Except in the case that a file is open for update in such a way that
	it may be rendered inconsistent (software that takes full advantage of
	RMS capabilities usually doesn't have this problem; software ported
	from other operating systems may), you can simply do a
	"BACKUP/IMAGE/IGNORE=INTERLOCK" instead.

This is NOT true.  By including "/IGNORE:INTERLOCK", you are specifically
telling BACKUP to ignore the protective mechanisms that are there to ensure
file consistency.

The rest of this message is "more than you want to know" about the details of
backing up "live" systems.  Unless you have continuously-running applications
with irreplacable data files, you probably won't care about it.  If no user
programs have files open for write, an on-line backup of a disk is a safe
procedure - while VMS does have files open for write, they either don't matter
to the backup (e.g., page files) or are virtually certain to remain consistent
(e.g., SYSUAF).

If you use BACKUP/IGNORE:INTERLOCK, what you end up with on your BACKUP tape
may be inconsistent at the application level (i.e., if the application
maintains multiple files, or multiple records within a file, that have to be
consistent with each other, BACKUP may save a partially-updated set of data).
It can even be inconsitent at the RMS level:  If you catch an indexed file in
the middle of a bucket split, you may not even be able to read the file with
RMS after you restore it.

It IS possible to write applications that can be told:  "Put your files into
a consistent state and do nothing until I tell you to go ahead".  (One way
to do this is to use blocking AST's.)  While the files are in a consistent
state, they can be backed up safely.  HOWEVER, this requires (a) non-trivial
programming effort; (b) that such application "pauses" be acceptable in the
particular environment.  (In some on-line transaction processing environments,
they may not be.  Backups in such environments are VERY difficult to do.)

BACKUP/IGNORE:INTERLOCK will PROBABLY work MOST of the time.  Unfortunately,
we all know that if you do such backups every day for 3 years, the one time
you need to restore the data will be the one time you caught the files in an
inconsistent state.

A common misconception is that you can do backups of "live" files by using
disk shadowing:  Put a disk in the shadow set, wait for it to be brought up to
the current state of the rest of the set, the pull it from the shadow set.
This won't work either, for exactly the same reason that BACKUP can fail:
Without some coordination with the applications involved, there is no reason
to believe that there is ANY time while the application is running at which
the actual data on the disk is consistent.  Again, MOST of the time, it MAY
work, but....

The only complete solution is provided by journaling.  Not cheap, but appro-
priate - essential! - in some situations.
							-- Jerry
------