Subject: | |
From: | |
Reply To: | |
Date: | Wed, 10 Jan 2001 17:02:47 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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
|
|
|