I would disagree that the backup set would serve little reason other than a 
portable backup media (though this is a good enough reason in itself).

Coming from a mainframe back round I tend to emulate the storage management 
processes that have evolved with the mainframe over the past decade or two. 
Ignoring the scenario of operating two remote sites,  the most common mainframe 
method to prepare for a DR recovery is to create full backups of your storage 
volumes once per week and incr for the remainder.

This method allows for;
a) a percentage of your storage to be restored to it's most current point in 
time in a single restore process, therefore minimising the total recovery time
b) minimise the amount of data to be recovered from incr media which can 
involve a large number of tapes and network bandwidth - again minimising the 
total recovery time

Because most of us still backup over the network the ability to create 
"regular"  full backups was restricted or totally prevented by bandwidth 
limitations. This then brings into question the ability to perform a full 
recovery.

Backupsets have solved this restriction and allow for the creation of the 
"weekly backup" removing the major bottleneck being the network. 

I am testing a  plan to implement the afore mentioned methodology  by  creating 
the backupsets to a "transportable" media on a weekly basis. For example, 
backupsets  for server A B and C will be created on Mondays, E, F and G on 
Tuesdays etc etc.

For what would be considered the most critical servers the backupset would be 
created more regularly than the weekly cycle. However,  because of other 
technologies such as EMC's timefinder / SRDF  being available to these critical 
servers this probably will  not be required.

Hopefully the major benifit of this process  - a full serve restore, will not 
be required however a more immediate benifit I hop to realise is being able to 
turn off collocation.

Wait, there is more....

In the near future a SAN infrastructure will be implemented which allows for 
greater flexibility.


The scenario I would like to investigate is; (for servers not normally 
participating in the SAN)

on the storage create a minimal DR boot image of each of the operating systems  
- including the TSM code
create the backup set to devc type of file (located on the SAN storage )
in the event of a failure the server or the replacement server would be 
temporarily connected to the SAN and booted from the appropriate boot image on 
the SAN storage (standardisation is the key)
the volume on which the backupset was create will be made available to the 
server
restore via normal BMR processes



Peter Griffin

>>> rdearm1 AT UIC DOT EDU 04/11/01 07:28am >>>
Currently I do regular TSM ncremental backups of my servers every night.  I
was wondering is there any reason I should start creating Backup Sets.  I
still have the ability to restore my server to its last backed up state if
it were to fail.  Therefore I don't see much reason for doing Backup Sets
accept for the ability to restore the downed server from portable media if
TSM isn't available.  Does anyone have any opinoins on types of backups to
do on NT, and AIX systems that will give me the best recoverablity in case
of a failure.

Thanks
***************************EMAIL  DISCLAIMER**************************
This e-mail and any files transmitted with it may be confidential and are
intended solely for the use of the individual or entity to whom they are
addressed.   If you are not the intended recipient or the individual
responsible for delivering the e-mail to the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken
in reliance on it, is strictly prohibited.  If you have received this e-mail
in error, please delete it and notify the sender or contact Health
Information  Management (312) 996-3941.