HP3000-L Archives

September 2001, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Sorenson, Bob" <[log in to unmask]>
Reply To:
Sorenson, Bob
Date:
Tue, 25 Sep 2001 11:13:44 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (97 lines)
Greg,

Exactly my dilemma!  It's a mix--some files regardless of when they were
modified and some files stored by modify date.  For several reasons, two
separate backups are not feasible now.  I've written a job that will run
every Sunday at 1:00 a.m. with the "Rename solution".  This way, if we need
to know if the file was truly modified or not, we can be pretty certain (not
full-proof, I admit).  If it was "modified" during the time my job ran, it
probably wasn't really changed because we don't have any other processes
running then

Thank you again for your great input, Greg!

Bob Sorenson

-----Original Message-----
From: [log in to unmask] [mailto:[log in to unmask]]
Sent: Tuesday, September 25, 2001 12:01 PM
To: [log in to unmask]
Subject: RE: Partial Backup Issue

Well, it sounds like you aren't performing a store of files modified by a
certain date! You want store to backup some files regardless of whether or
not they've been modified by a certain date. Perhaps you have mutually
exclusive criteria: one subset of some files, but of that subset, only those
that have been modified, and another subset of files, stored regardless of
their modification date. Is that correct? If so, I'm pretty sure that STORE
just does not do that.

That said, you have some options, if you need to do this. Do two separate
backups. That may not be feasible, for a lot of reasons. Buy a backup
product that can do this, or that can append two backups to one tape. That
may not be feasible, either. If you HAVE STORE To Disk, you could STD one
set, and then include THAT STD file in the other STORE. Or, you could copy
one set of files into a group or directory, and include that group or
directory in the STORE job.

Greg Stigers
http://www.cgiusa.com

-----Original Message-----
From: Sorenson, Bob [mailto:[log in to unmask]]
Sent: Tuesday, September 25, 2001 12:13 PM
To: Stigers, Greg [And]
Subject: RE: Partial Backup Issue

Greg,

Thanks so much for the input.  I echo your bias against using MPEX to change
the modification date.  After all, the file may not have been modified.  I
considered a store list.  But when you're performing a backup of files
modified since a certain date, how would the backup know to store the files
in the file set if they aren't tagged as modified since the last full
backup?

Regards,

Bob Sorenson

-----Original Message-----
From: [log in to unmask] [mailto:[log in to unmask]]
Sent: Tuesday, September 25, 2001 11:06 AM
To: [log in to unmask]; [log in to unmask]
Subject: RE: Partial Backup Issue

X-no-Archive:yes
Bob wrote:
> I need to force selected file sets to be stored on partial
> backups regardless of whether or not they have been modified since the
last
> full backup date.  Any ideas?

How about a store list, preferably kept in an indirect file? If these are
known files or file sets, then either explicit lists of filenames, or
appropriately wildcarded arguments, ought to get you exactly the files you
need.

One important caveat is, that if you go with explicit filesets, and someone
adds a new file to this application, that file will not get picked up.
Whereas, if you go with wildcards, and someone adds a file that fits the
wildcard, but this is not a file you want backed up, you get it anyway. So,
this requires some attention. It's not set it and forget it. But I cannot
imagine a solution that could be guaranteed to be bullet-proof.

My own bias is that using MPEX to change the modified date loses some
important information, when the file was actually modified. Sure, you would
have the files on backup tape, but you wouldn't know for sure which copy of
the file was the same as or different from another. If one tape, or several
tapes in a row, proved bad, you could never be sure that the copy you
recovered from a good tape was a good copy.

Greg Stigers
http://www.cgiusa.com

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2