RE: Backup performance

We have a 3581 Model H17 tape library. We don't utilize it to it's
potential at all. Our BP told us that we could use it for an enterprise
backup solution. They never mentioned the software required though. My boss
was under the impression that it could be done directly with OS/400. She,
obviously, was sadly mistaken.

Thanks,

Mark

Mark D. Walter
Senior Programmer/Analyst
CCX, Inc.
mwalter@xxxxxxxxxx
http://www.ccxinc.com

|---------+------------------------------->
|         |           Glenn Ericson       |
|         |           <Glenn-Ericson@xxxxx|
|         |           et>                 |
|         |           Sent by:            |
|         |           midrange-l-bounces@m|
|         |           idrange.com         |
|         |                               |
|         |                               |
|         |           01/15/2004 11:30 AM |
|         |           Please respond to   |
|         |           Midrange Systems    |
|         |           Technical Discussion|
|         |                               |
|---------+------------------------------->

>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>, "'Midrange Systems Technical Discussion'" |
| <midrange-l@xxxxxxxxxxxx> |
| cc: |
| Subject: RE: Backup performance |

>------------------------------------------------------------------------------------------------------------------------------|

Jeff
a  3580 is  a  cost effective  alternative to  the 3590. It  should  do
well in a B/U  RST  environment. Like large streaming type objects
.The  3590 does well with both  large and small objects but there is
a  different price to  pay.

At 11:10 AM 1/15/2004 -0500, Jeff Crosby wrote:
> > We quiesce the libraries one group at a time.  Remember that
> > we are running multiple divisions.  Once quiesced, using a
> > regular save to tape (not save while active), only shuts down
> > that group for about 4 minutes on our 3590.  Yes, when you
> > look at the total time of our DB2 backup, it may stretch a
> > few hours, but each division is only locked out for a few
> > minutes.  Personally I don't think the save to a *SAVF would
> > be that much faster than the 3590.
>
>Since we're running a 270, I highly doubt a 3590 is in the offing. <g>
>
>Use a 3570 tape drive.  We run a complete save every night, no problem.
We
>run a SAVCHGOBJ on the entire system (libs, IFS, etc) every afternoon at
>1:30(see note 1).  This afternoon backup keeps everybody off 15-20
minutes,
>including restrict system, backup, and restart QCTL.  Since we do every
lib,
>we can't do it to a *SAVF, it must be tape.  It's this window I was trying
>to figure out some way to reduce.
>
> > Again, you'd be spending how much on disk to reduce
> > 4 minutes to what?
>
>3:55.  But hey, it's an improvement. <g>
>
>(note 1) The reason for this backup?  About a year ago, on a Friday
>afternoon at 3pm the system died.  What died was the backplane and it went
>so hard (and instantly) that the whole system was hosed.  Had to do a
>scratch install.  Saturday I reloaded the entire system from backups which
>took us to Friday morning status.  Sunday morning management came in and
we
>redid everything that had been done on Friday (orders, inventory receipts,
>A/P, A/R, you name it) and created all invoices to be delivered on Monday.
>If it had happened any other day of the week, we would not have had the
>luxury of a weekend to get all this done and still take care of our
>customers on a timely basis.  The only way to reduce that recover time if
>the system died again was to do additional backup.  By 1:30pm, all A/R,
all
>A/P, 75% of inventory receipts, and 50-70% of orders are in, so that time
>was selected.  Yes I suggested disaster recovery to no avail.
>
>--
>Jeff Crosby
>Dilgard Frozen Foods, Inc.
>P.O. Box 13369
>Ft. Wayne, IN 46868-3369
>260-422-7531
>
>The opinions expressed are my own and not necessarily the opinion of my
>company.  Unless I say so.
>
>
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx
> > [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> > Sent: Thursday, January 15, 2004 10:36 AM
> > To: Midrange Systems Technical Discussion
> > Subject: Re: Backup performance
> >
> > Jeff,
> >
> >
> > Rob Berendt
> > --
> > "All creatures will make merry... under pain of death."
> > -Ming the Merciless (Flash Gordon)
> >
> >
> >
> >
> > "Jeff Crosby" <jlcrosby@xxxxxxxxxxxxxxxx>
> > Sent by: midrange-l-bounces@xxxxxxxxxxxx
> > 01/15/2004 10:19 AM
> > Please respond to
> > Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> >
> >
> > To
> > "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
> > cc
> >
> > Fax to
> >
> > Subject
> > Backup performance
> >
> >
> >
> >
> >
> >
> > This talk about backing up \QNTC\ directories leads me to ask
> > a question
> > I've been thinking about.
> >
> > To reduce the backup window on the iSeries, is there anyone
> > out there who
> > is
> > backing up to disk (*SAVF) and, when the system is brought back from a
> > restricted state, then transferring the *SAVF files to tape?
> >
> > I was curious as to whether something like this reduces the
> > backup window
> > as
> > far as restricted state is concerned.  And I know what tape
> > drive is used
> > makes a big difference.  Plus backing up to a *SAVF is a '1
> > library at a
> > time' thing.
> >
> > --
> > Jeff Crosby
> > Dilgard Frozen Foods, Inc.
> > P.O. Box 13369
> > Ft. Wayne, IN 46868-3369
> > 260-422-7531
> >
> > The opinions expressed are my own and not necessarily the
> > opinion of my
> > company.  Unless I say so.
> >
> >
> >
> > _______________________________________________
> > This is the Midrange Systems Technical Discussion
> > (MIDRANGE-L) mailing
> > list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> >
> >
> > _______________________________________________
> > This is the Midrange Systems Technical Discussion
> > (MIDRANGE-L) mailing list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> >
> >
> >
>
>
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
>To post a message email: MIDRANGE-L@xxxxxxxxxxxx
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>or email: MIDRANGE-L-request@xxxxxxxxxxxx
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.