MHJohnson@HI-MULTICS.ARPA.UUCP (02/28/87)
The question about BACKUP and how some files might be missed by the general system backup method brought up some old memories and other sources of comments.... In general, I recommend performing an IMAGE backup weekly and using /SINCE=BACKUP for the dailies. This takes all day on our system to perform the IMAGE backup (5 RA81's on cluster, one Eagle on MicroVAX done remotely) but is well worth the time. I had to perform a 3 disk restoration before we used IMAGE backups on a regular basis and spent over a day on the job. The same operation from an IMAGE backup takes about 3 hours. About dates and RMS, I feel that RMS ought to be changed to support four or five dates instead of the three now in use. Multics uses five as: (1) Date/time last accessed (2) Date/time contents modified (3) Date/time entry modified (4) Date/time contents dumped (backed up by the volume dumper) (5) Date/time entry dumped There is a difference between contents modified (I changed the file) and entry modified (I changed its protection, name, or whatever). The first should trigger a backup (& for MMS, regeneration of target files) of the contents of the file. The second should trigger a backup of the INDEXF.SYS headers for the file rather than the contents (since they did not change). I have complained to DEC about this back in the days when BACKUP first came out but have yet to see any change. Since RMS is so pervasive in DEC's product line (like DECNET) I will probably never see any fix for this problem unless the customers widely demand it (not likely). There is another feature of Multics that I wish VMS had and that is a flag that the file is DAMAGED. When I backup a file that has a bad block in it, BACKUP kindly gives me a message about the bad record. When BACKUP restores the file, NO INDICATION that the record was bad is in the new copy of the file. Oh well, if wishes were fishes.... --Mark <MHJohnson @ HI-MULTICS.ARPA>