| Hi Robin,
As an example, here is the BACKUP strategy in use in the Southern States
Region on their six production ALL-IN-1 clusters:
Incremental BACKUP's of all disks are done 4 nights per week and full
BACKUP's are done one night per week (scheduled for 7:00 P.M. local time),
all using the /IGNORE=INTERLOCK switch.
Each morning at 12:30 A.M., ALL-IN-1 maintenance processing is performed.
Some of the daily activities are done without ALL-IN-1 shut down, however,
all system file convert activities require ALL-IN-1 to be shut down. We
do the SDAF converts by using BACKUP to copy the SDAF(s) to a designated
work disk, then deleting the source copy of the SDAF, then RMS CONVERTing
the copy back to the live SDAF location with a temporary name, renaming
the newly converted SDAF to the correct filename. The next evening's
regularly scheduled BACKUP will pickup a copy of the SDAF(s) from the
convert work disk. (An extract of this morning's logfile is included
after the <FF>)
The net result of this activity is minimum unavailability of ALL-IN-1,
a reliable, restorable BACKUP of the system files, and a contiguous
SDAF that helps in all electronic mail processing by both our customers
and the ALL-IN-1 Sender/Fetcher processes.
By the way, this same information could be obtained from your local CNS
(nee' IM&T, nee' DIS, nee' IS, nee' MIS) group, who do these activities
for their customers (you are one!) every day, with minimum disruption.
Hthy,
Ron
Converting OA$SHARA:OA$DAF_A.DAT - starting at 10-JUN-1993 00:49:12.18
%DELETE-I-FILDEL, CONV$WORK:[ALLIN1]OA$DAF_A.TMP;1 deleted (750000 blocks)
%BACKUP-S-CREATED, created CONV$WORK:[ALLIN1]OA$DAF_A.TMP;1
%DELETE-I-FILDEL, NEWDAF:[OA$SHARA]OA$DAF_A.DAT;1 deleted (750000 blocks)
CONVERT Statistics
Number of Files Processed: 1
Total Records Processed: 344066 Buffered I/O Count: 12
Total Exception Records: 0 Direct I/O Count: 67457
Total Valid Records: 344066 Page Faults: 299
Elapsed Time: 0 00:27:22.92 CPU Time: 0 00:08:05.06
%RENAME-I-RENAMED, NEWDAF:[OA$SHARA]OA$DAF_A.NEW;1 renamed to (my <CR><LF>)
NEWDAF:[OA$SHARA]OA$DAF_A.DAT;1
File converted using FDL file OA2$:[ALLIN1]OA$DAF_A.FDL;1.
Originally was 750000 blocks - current is 748000 blocks.
...end...
|
| I have been unable to find any information in the Vol Shadowing or VMS
Notes conference files on this topic so here's a question for the
inhabitants of ALL-IN-Wonderland.
I have a customer who, at present, doesn't like the idea of shutting
down ALL-IN-1 each night to do backups - I think he's had problems
restarting in the past. Instead, he sets off batch jobs at around
22h00 which break up his shadow sets and then take copies of the
'lower' disks to tapes and then remounds the shadow sets when he's
done.
I know that /IGNORE=INTERLOCK is potentially damaging to your ALL-IN-1
Systems health and an I know why, but is the breaking of a shadow set
with, say, open SDAF's, PENDING.DAT's etc. a good move.
My own view is that he'd be much better off shutting everything down
and doing proper backups. I can, so far, talk him out of backing up
with /IGNORE=INTERLOCK as I can explain why he shouldn't do it but can
anyone come up with a reason whey the Shadow Set split option isn't a
good idea either?
I can't explain why I don't like it... I just have a very bad
feeling..!
All input gratefully received!
Regards,
Peter.
|
| One thing that occurs to me is that it would be worth *briefly*
shutting down ALL-IN-1 whilst you take the shadow set members off-line,
in order that the SDAF, DOCDBs etc., are in a consistent state. I
presume that you could bring the shadow sets back whilst the system was
still running.
Otherwise, it seems like a good idea.
Graham
PS a reply to the previous note in its original location suggested
other discussion in notes 1271 and 2508.
|
| Actually, you need to dismount the shadow set first, then remount it
excluding the member to be used as the backup source. This is to
insure that all in-memory caches have been flushed and the physical
disks are in a consistant state. Otherwise, you risk restoring a
corrupted set of files. You can add the backup source to the shadow
set at any time after you/ve finished the backup.
Good luck,
David
|
|
Hi,
I think I'd have to agree with Graham's comments...
I would not dismount a member of the shadow set for BACKUP while
ALL-IN-1 is up.
There are a few reasons for this:
1. Even though RMS I/O is write-thru on the ALL-IN-1 data files, it
is still possible that you could get RMS structure
inconsistencies from the dismounted shadow set member. This is
because some RMS operations such as bucket splits require multiple
bucket I/Os and you could end up dismounting between these
operations. [Of course, if you could guarentee no users, then
that would probably prove sufficient but the best way to do this
is to shutdown ALL-IN-1.]
2. Even if the updates to the RMS file left the RMS structures
consistent, you could catch the ALL-IN-1 DAF operations between
RMS records and still get an inconsistent DAF file.
The best way of backing up ALL-IN-1 systems is with ALL-IN-1 shut down.
The worst way of backing up ALL-IN-1 systems is BACKUP/IGNORE=INTERLOCK
Breaking a shadow set is almost equivalent to the latter.
Just one final point on backups:
You should also try to ensure that your cabinet files, shared areas and
user accounts are backed up "in synch". If the user files aren't in
synch with the system files then you will have to make sure that
TRM/TRU are used to get them back in synch in the event that one set is
restored without the other. Otherwise you'll have usage counts way out.
Paul.
|