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
>>> [EMAIL PROTECTED] 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.
