HP3000-L Archives

September 1997, 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:
Steve Dirickson b894 WestWin <[log in to unmask]>
Reply To:
Steve Dirickson b894 WestWin <[log in to unmask]>
Date:
Tue, 23 Sep 1997 14:30:00 P
Content-Type:
text/plain
Parts/Attachments:
text/plain (65 lines)
<<I'm looking at ways to increase protection on my disk "Farm" in case of
a disk-crash. Currently on a HP3000/957SX, I have about 18GB, on 10
drives, in 1 volume-set. Of the 18GB, about 13GB is used (28% free
space), of the 13GB, only 3.5GB is user data. The rest is source-code,
executables, etc., and 2 copies of the user data. All of the user data is
in Image databases (ASK/MANMAN System)

My primary concern is losing user data that has been entered during the
day, before the nightly back-up. We are a manufacturing facility, so
although downtime is a concern, the loss of data is most critical.

One given is to set up User Volume Sets (SYSTEM, PRODUCTION, TEST).>>


How about
   MPEXL_unreasonablylongname
   PRODUCTION
   BACKUP
   TEST

? At the start of the backup, copy the contents of the PRODUCTION volume
set, either the whole thing or the pieces that change, like databases, to
the BACKUP volume set. Then back up the BACKUP volume set to tape. In
addition to giving you an on-line day-old-or-less backup, it gets the
production system back up faster, since a disk-to-disk copy is still
faster than disk-to-tape. If disk space is an issue, the database
copy(ies) on the BACKUP volume set can be purged once the tape backup is
done and verified, though you lose the on-line copy and recovery takes
longer.

The "secret ingredient" in this configuration is that the TurboIMAGE log
files for the databases on the PRODUCTION volume set live on the BACKUP
volume set. With this setup, you start each backup/logging cycle with two
complete copies of the production database(s): one on PRODUCTION, one on
BACKUP. As the users update the PRODUCTION-resident database(s), the
modifications are logged to the BACKUP volume set. If a device in the
PRODUCTION volume set crashes, you use the saved copy from BACKUP plus
the log files on BACKUP to roll the saved copy forward to the state
before the crash.

The "gotcha" in this configuration is that cross-volume-set logging
prohibits ROLLBACK recovery. Many shops don't use ROLLBACK, so it's a
moot point. However, if you're a shop that relies on ROLLBACK, this whole
idea is a non-starter.

<<I'm looking for some feedback from the list about any concerns or
problems in using Mirrored Disk. With adding 4 more disk drives, I can
set up the following configuration:

        System:         2 drives
        Production:     4 drives
        Prod Mirrored:  4 drives
        Test & other    4 drives

My concern is the possibility of an I/O bottleneck by bringing the
production data down to 4 drives, when it used to be spread over 10. >>


That's the downside of RAID1: the 100% overhead "cost" in devices.
Whether or not the reduction in spindle count will cause a reduction in
throughput depends on the usage patterns of the specific system, so the
only feasible way to find out is to try it.

Steve

ATOM RSS1 RSS2