RE: Reducing downtime for backups

Phil,

If BRMS is specifying compression on the save to savefile, you would be
able to shorten your save by turning this off.  Compression to a save
file is entirely software-based and can be _very_ processor intensive.
I have no knowledge of how this would be configured in BRMS, but it
could save a non-trivial amount of time.  Obviously, you would require
more disk space for your save files.

There was a time in my life as tech support for hardware sales, when I
would not recommend some of the fastest tape drives on the smaller
AS/400's because the AS/400 could not present data to the drive fast
enough and the tape drive would spend too much time waiting.  Good
drives, but the customer would not realize much benefit for the
additional dollars.  So yes, in some cases it is possible for the tape
drive to be equivalent to disk access.  In other words, the limiting
factor of the save is the collection and formatting of the SAVLIB data,
not the writing to storage media.  It would depend on your processor.

If you look at performance during your save, check on the CPU
utilization.  If you are close to 100% and you're not using software
compression, you may not realize much benefit from a faster storage
device.  In that case, the save-while-active might be your best choice.

Regards,
Andy Nolen-Parkhouse



> Subject: Reducing downtime for backups
>
> I am investigating options for reducing the length of time that the
system
> is
> unavailable to users during our nightly backup job.  Not long ago we
added
> disks
> and started creating *SAVF files in a separate ASP for the backups,
> copying the
> *SAVF's to tape later.  This reduced downtime to about 1 hour, but
this
> continues to grow as we add files and the existing files grow.  We are
> doing
> full SAVLIB's using BRMS and have split out all of the program and
non-
> essential
> libraries into a separate job.  We backup 50 GB of data which
compresses
> to
> about 30 GB in the *SAVF format.  We are a single AS/400 shop running
JD
> Edwards.