HP3000-L Archives

January 2001, Week 2

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:
Thomas Burger <[log in to unmask]>
Reply To:
Thomas Burger <[log in to unmask]>
Date:
Wed, 10 Jan 2001 17:02:47 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (49 lines)
Doug,
      Not necessarily so. At least on 6.5. We are doing incremental backups with turbostore on a 'test' system that doesn't see much change on a daily basis. It actually realizes the root file is the only file in the database with a mod date greater than the cutoff date and does not backup the database. there is no 'partdb' in the sore statement. Here's an example of the message we get in the stdlist:

/AMISYS/DATA/ACCTNG STORED BECAUSE ONLY ROOT FILE QUALIFIED FOR DATE OPTION

Tom Burger
CDPHP

>>> Doug Werth <[log in to unmask]> 01/10/01 04:47PM >>>
Patrick Mullen writes:

> There are run time fields in the root file that get modified during a
> DBOPEN (regardless of Mode)...They revert back to zero (in the cases I
> examined) upon DBCLOSE...So in effect, no lasting modification transpired
> although a run time modification took place (returned to its/their
> initial/default values upon DBCLOSE, in the fields I examined)...
>
> I must say that I, too, was surprised but now understand how it happened.
>
> The coresponding/underlying datasets do *not* get an updated 'mod date'
> during dbfind/dbget on a Mode 5 opened database, however...

A side effect to this behavior is that an incremental backup will consider
this root file modified today, thus backing it up. Moreover, using the
default TurboStore option ";FULLDB" will cause TurboStore to write the
entire database to tape, even though none of it has been modified. This can
be quite a surprise to find a large archive database on a partial backup.

Another issue is that TurboStore sets the DBSTORE flag and writes the last
logfile and datestamp to each root file it backs up. In doing so, TurboStore
is also updating the access and modify dates of the root file in the file
label. Consequently, databases appear to have been modified just because
they have been backed up.

I suspect that because of the speed and capacity of DDS2, DDS3, and DLT
drives that most users are just doing daily full backups and no longer
running incremental backups or this issue would have received a lot more
attention. And those that are concerned about the length of daily backups
are selectively backing up files rather than using the ";DATE=" parameter of
TurboStore.

Has anyone else noticed this behavior? Has it been a problem for you? Just
curious.

Doug.

Doug Werth                             Beechglen Development Inc.
[log in to unmask]                               Cincinnati, Ohio

ATOM RSS1 RSS2