About system backup and restore

[Lionel Liu]

Hello there,

Our system backup strategy is
every six months, We do system and data disk
standalone image backup.
We do daiy rdb database full backup online and aslo we use the following command to backup file every day online

for system disk
BACKUP/IMAGE/IGNORE=(INTERLOCK,LABEL) SYS$SYSDEVICE: -
$1$MIA'TAPE':SYSTEM.SAV/SAVE_SET/REWIND

for data disk,

BACKUP/IGNORE=(INTERLOCK,LABEL) DSA100:[000000...]*.*;* -
$1$MIA'TAPE':DU_100.SAV/SAVE_SET/NOREWIND

We noticed the online file backup with the command BACKUP/IGRNORE could get some corrupted file backed up.

if the system or data disk corrupted,
we are thinking use the image backup restore the disk first, then use daily backup restore the disk again, the last is to do the database restore.

if the file is corrupt from the daily file backup, we just delete the lastest file verion. then the system will use file verion from standalone image backup or we restore the file from standalone image backup

Is there any problem for our backup strategy?

I am really appreciate if you could share your
backup strategy for us.

Thanks very much

Lionel

[Ian Miller.]

sounds like a reasonable approach and its good that you reconsidering the use of /IGNORE=INTERLOCK.
The key thing is to test your backup strategy!
Consider it more from the point of view of that do you need to be able to restore and how much can you afford to loose.

For background reading see
http://h71000.www7.hp.com/openvms/journal/v3/backup_strategies.html
http://h71000.www7.hp.com/openvms/journal/v3/backup_strategies.html

[Lionel Liu]

Thanks fro your reply,

As we know when do the following backup online
BACKUP/IMAGE/IGNORE=(INTERLOCK,LABEL) SYS$SYSDEVICE: -
$1$MIA'TAPE':SYSTEM.SAV/SAVE_SET/REWIND

some files could be corrupted in save set backup file. Is there any way to know which files are corrupted in the save set file?

Thanks

Lionel

[Ian Miller.]

the problem with /IGNORE=INTERLOCK is that it is possible to write junk to the tape without any error messages.

Read the wise words of the VMS Wizard
http://h71000.www7.hp.com/wizard/wiz_2467.html
http://h71000.www7.hp.com/wizard/wiz_9265.html
and in the FAQ
http://h71000.www7.hp.com/wizard/faq/vmsfaq_010.html#index_x_535

Basically for files that are open you have to find another way.

[Joseph Huber_1 · Accepted solution]

>As we know when do the following backup online
>BACKUP/IMAGE/IGNORE=(INTERLOCK,LABEL)
>some files could be corrupted in save set >backup file. Is there any way to know which >files are corrupted in the save set file?

No, You just get warnings for those files open for write, but that does not tell You wether the file is corrupted or not.

I would not follow Your backup strategy at all:
On the one side most files on the system disk are not changing at all, and can be restored from the base backup. And all files frequently changing can't be backup reliably with /ignore=interlock.
Instead of doing an image backup every day,
I would do an incremental backup (?since=backup) only, and copy all essential open files separately using convert.
In my nightly house-keeping job, I do:
convert/share to a save disk of:
sysuaf,rightslist,VMSMAIL_PROFILE,VMS$AUDIT_SERVER,
net$proxy,VMS$PASSWORD_HISTORY,QMAN$MASTER.DAT,
SYS$QUEUE_MANAGER.QMAN$QUEUES.
What can't be converted, is SYS$QUEUE_MANAGER.QMAN$JOURNAL.
One would have to stop the queue manager to backup that reliably. (If You have a long list of batch jobs, then there is no way around).
For audit,accounting,error,operator log , I start a new one every night, then the previous day ones can reliably backup.

[Lionel Liu]

Thanks very much Joseph,

I couldn't find the documenation about how to use CONVERT/SHARE command. Could you plesase check the following procedures if it is correct ( Our system is cluster system)

For each file, run the following procedure

Convert/share DSA50:[SYS0.SYSCOMMON.SYSEXE]rightslist.dat DSA50:[BACKUP.SYS0]rightslist.dat

Convert/share DSA50:[SYS1.SYSCOMMON.SYSEXE]rightslist.dat DSA50:[BACKUP.SYS1]rightslist.dat

Convert/share DSA50:[VMS$COMMON.SYSEXE]rightslist.dat DSA50:[BACKUP.COMMON]rightslist.dat

if the file corrupted on the system, Is that using the COPY command to copy file from the backup directory to its original directory?

Thanks again

Lionel

[Uwe Zessin]

Lionel,
on an intact system disk you would pick up the same RIGHTSLIST.DAT three (3) times, because SYSCOMMON.DIR is an alias to VMS$COMMON.DIR.

You can easily check this out by comparing the file's identifiers:
$ directory/file -
sys$sysdevice:[000000]vms$common.dir, -
[sys*]syscommon.dir

or
$ directory/file -
sys$sysdevice:[vms$common.sysexe]rightslist.dat, -
[sys*.syscommon.sysexe]

[Joseph Huber_1]

As Uwe pointed out, there should be only one
rightslist file, namely the one in sys$common:[sysexe].
In Your systems case it might be so.
In more complicated system(-disk) envrionments it might be somewhere else on a common disk. see the logicals for the common files in sylogicals.template !
So a general "backup" procedure should first
translate the logical RIGHTSLIST, parse the output with the default sys$common:[sysexe]rightslist.dat, and then convert/share the resulting file-specification.

I attach my update_cluster_files.com file running every night, which copies all those common files.

[Joseph Huber_1]

Just to add to my attached command-file in previous reply:
If You have a single common system-disk, then
of course remove the conditional
if nodename.eqs.fnode
Otherwise nothing is copied.
My system is a poor mans Network-only cluster, and to reduce LAN traffic, each member of the cluster has its own local system disk. The cluster common files are served by one of the cluster members.
Every night the files are copied to the local system disk of each member (not "disk$reserve:"
as in my attached file).

[Jan van den Ende]

The way to be _ALWAYS_ sure of using the correct SYSUAF.DAT (and RIGHTSLIST.DAT, and almost all system files) is:
$ targetfile = f$parse("SYSUAF","SYS$SYSTEM:.DAT")
and now use 'targetfile' (of course, choose your own symbols!) for your operation.

f$parse will first try to evaluate the logical name in the first param; if no translation, use that param as string.
Now we treat that as part of a complete filename. Any missing elements a completed using the second param.
In this case, if SYSUAF translates to ALT_SYSDIR:SYSUAF (although I would include ",.DAT" in the logical name for other resons, for this demonstration we leave out the filetype) we get:
nodename -- unspecified, so use default: local-node::
directory -- specified by logical name as "ALT_SYSDIR:"
name: -- specified by logical name as "SYSUAF"
type: -- specified by param 2 as ".DAT"
version -- unspecified. Most (nearly all) programms use ";0" , but eg. directory operations always use ".DIR;1"

Now, same command without defined SYSUAF logical name:

nodename -- default, local-node::
directory -- no logical name, so use param 1 as string. Syntactically evaluates to a string which does not specify directory, so use from param 2: "SYS$SYSTEM:"
name -- param1 syntactically contains filename, use that: "SYSUAF"
type -- like directory, have to use param 2: ".DAT"
version -- unspecified, same as above.

Because RMS file specifying uses the same function, this ALWAYS GUARANTEES the correct file being used!!

(well, minor detail: privileged mode functions use only logical names of at least the same privilege mode. Notably in this context: system RIGHTSLIST operations only use EXEC mode logical names!)

hth

Proost.

Have one on me.

Jan