Hi Milton,

It's been a long time since we talked.  You know you could have just
called me and I would have helped you out.  But anyway here is what I
recommend:

DBSNAPSHOT - should be used for your DR backups of the DB.  They should
be to a tape and taken offsite with your DR tapes.  DBSNAPSHOT is
effectively a full backup of the DB, but it does not involve the LOG in
any way.  Therefore, it can only be used for a PIT (point in time)
restore.  Also, please note that a DBSNAPSHOT does not reset the LOG
like a DBB (full or incremental) does if the LOG is set to ROLLFORWARD.
This makes it perfect for a DR type restore since in a disaster you
would expect that the LOG would be lost.  Please note if you are using
DRM then you should update your scheduled Prepare command to include
"Prepare Source=DBSnapshot" so that it manages the correct tapes for
you.  I sure do wish that the ITSM developers would make this the default!

DBB(full and incremental) - should be kept onsite for rapid DB recovery
including restore to the most recent time using a ROLLFORWARD log.  I
prefer to do these DBB to a device of type FILE.  This allows for much
faster backups and restores.  Furthermore, I can schedule a full once a
week and incrementals the rest of the week with no penalty on the
restore time for multiple volumes since they are all coming from disk.
This methodology offers a few more not so obvious advantages, you could
easily schedule multiple DBB incrementals a day thus reducing the size
requirement of you LOG.  Also, if you use DEFine DBBackuptrigger you can
set your triggered backups to go to the same device of type FILE which
means in a triggered event your DBB will take place much faster and a
rapidly growing DB would be less likely to trigger the DB spacetrigger.
Remember when defining your DBBackuptrigger to make sure you specify
NUMINCremental to 32 allowing for as many incrementals as possible
between fulls, again there is no penalty here for multiple volumes since
it is going to a device of type FILE.

BTW, based on your note you were doing DBSNAPSHOT's daily which takes as
much space as a DBB full does.  If you switch to the method described
above, you will use far less space on disk since you will be doing
mostly incremental backups of the DB.

If you are anyone else has any questions about this please feel free to
contact me either by this list or send me email directly.

--
Regards,
Mark D. Rodriguez
President MDR Consulting, Inc.

===============================================================================
MDR Consulting
The very best in Technical Training and Consulting.
IBM Advanced Business Partner
SAIR Linux and GNU Authorized Center for Education
IBM Certified Advanced Technical Expert, CATE
AIX Support and Performance Tuning, RS6000 SP, TSM/ADSM and Linux
Red Hat Certified Engineer, RHCE
===============================================================================



Johnson, Milton [IT] wrote:

All,

    TSM: Storage Management Server for AIX-RS/6000 - Version 4, Release 2,
Level 1.7
     OS: AIX 4.3.3 ML 9
Log Mode: RollForward
         (Upgrade project planned in near future, but that's another story)

Everyday I do a full backup of the database to 3590E tape, immediately
followed by a DBSNAPSHOT to a file on disk.  The 3590E tape promptly goes
offsite.  My question is if I experience a loss of the database can I then
restore from the DBSNAPSHOT and recover to the point of failure using the
RECOVERY LOG?  I would like to avoid the time delay of returning the 3590E
tape, containing the database backup, from the vault.

Anyone done this?

Thanks,
H. Milton Johnson
UNIX Systems Administrator - USCC San Antonio, TX
Email: milton.johnson AT citigroup DOT com