Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!YALE.ARPA!LEICHTER-JERRY
From: LEICHTER-JERRY@YALE.ARPA.UUCP
Newsgroups: mod.computers.vax
Subject: Re: Backup didn't get ALL my files
Message-ID: <8702270328.AA09884@ucbvax.Berkeley.EDU>
Date: Thu, 26-Feb-87 22:28:44 EST
Article-I.D.: ucbvax.8702270328.AA09884
Posted: Thu Feb 26 22:28:44 1987
Date-Received: Sat, 28-Feb-87 07:48:39 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: <LEICHTER-JERRY@YALE.ARPA>
Distribution: world
Organization: The ARPA Internet
Lines: 53
Approved: info-vax@sri-kl.arpa


    ...I do image backups about every 6 months. Every day I do a daily backup
    with the input qualifier "/SINCE=BACKUP", except on Friday, I do a weekly
    backup with the input qualifier "/SINCE=20-FEB-1987:18:00" - of course
    using the exact date and time of last Friday's backup.  I rotate the daily
    tapes every couple of weeks.  So I should be able to restore my disk from
    the Image tapes + the Weekly tapes + the Daily's since last Friday. Right?

    ...[A] couple of weeks ago I restored a file to my account from a private
    backup saveset.  It was picked up by the daily backup, but was *NOT*
    written to the Weekly backup [because the last modified date was some time
    in the distant past].

    ...

    Am I doing something wrong?  And even though /BACKUP works as documented,
    I think it would be better behaviour for "/SINCE=date/BACKUP" to recognize
    empty backup dates as valid selections, rather than NOT valid selections,
    such as "/SINCE=BACKUP" does.

Well, if /BACKUP/SINCE=date was changed to pick up files that were never
backed up, what would you have /BACKUP/BEFORE=date do?  Also pick them up
(as it does now, since "never backed up" is the same as "backed up a very
long time ago")?

Adding /BACKUP to your weekly backups doesn't seem like a good idea - both
because files created since the last backup will be missed, and because if
for some reason your daily backup failed on some files, they wouldn't get
backed up by the weekly either, as their date of last backup would remain
unchanged.

The real problem here is that BACKUP on a regular schedule doesn't interact
perfectly with private uses of BACKUP.  When restoring files, BACKUP restores
files EXACTLY - including dates of last modification and last backup.  This
makes a file restored privately by BACKUP "different" from a newly-created
or modified (or even copied) file - it sort of "appears out of nowhere".
There's really no simple solution as things stand - private backups can make
files appear and disappear in a way that reasonable backup strategies really
can't track well.

It would be nice if BACKUP had an option that caused it to set the last
modification date to the current date, not the date in the saveset.  Unfor-
tunately, it doesn't.  A simple workaround is to make sure the modification
date is updated whenever you do a private file restoration.  A quick way to
do this is to set the file's protection - even setting it to its current
value will work.  I use a one-line command file, TOUCH.COM, to do this:

	$ set file/prot=('f$file(p1,"PRO")') 'p1'

Of course, the drawback here is that you have to remember to do it.

							-- Jerry
-------