DavidKruse.ES@XEROX.COM.UUCP (02/25/87)
I noticed something the other day which upset my confidence in my backup system. Maybe someone can suggest a better way. First some background: We have a single disk (RA81) 11/750. 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? Well a couple of weeks ago I noticed something. I had 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. I can explain the reason why, but that is of little comfort if my backup tapes can't be used to restore the disk to its present state. The file I restored from my private saveset had a create and modified date well in the past, lets say sometime in 1986. The daily backup picked it up because the backup date field was empty. But the weekly backup compared the /SINCE=date with the modified date, and of course, decided it didn't need to be backed up. My first thought was to add the input qualifier /BACKUP with my Weeklys (/SINCE=exactdate/BACKUP), but that means that files created on Friday, (where the backup date field is empty) will not be backed-up. This appears to be the documented behaviour, as the documentation for /BACKUP says it "selects files based on the time recorded in the backup date field" and I guess that a null time can't be since last week. 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. Dave Kruse DavidKruse.ES@Xerox.COM
LEICHTER-JERRY@YALE.ARPA.UUCP (02/27/87)
...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
-------