Peter,
Backup set is designed to have LAN-free restore capability for small and
remote clients. If you are going to use same resources
(library,tsm-server,network) to restore client then it's better not to
create backup sets. We can always schedule multiple threads to restore that
significantly reduces restore time. Backup set restore needs TSM client in
place prior to restore it doesn't need database.
It's not secure, if someone gets backup set media, they can steal your
sensitive data. It's not useful to restore OS unless you go for some
additional products like Bare metal restore.
Bandu
-----Original Message-----
From: PETER GRIFFIN [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 10, 2001 6:56 PM
To: [EMAIL PROTECTED]
Subject: Re: Backup Sets
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.
"WorldSecure Server <baking.bestfoods.com>" made the following
annotations on 04/10/01 19:07:11
----------------------------------------------------------------------------
-
The origin of this electronic mail message was the Internet.
Bestfoods Baking cannot validate the authenticity
of the sender and therefore cannot be held accountable
for any content within.
======================================================
"WorldSecure Server <baking.bestfoods.com>" made the following
annotations on 04/23/01 12:29:14
-----------------------------------------------------------------------------
This message may contain confidential and trade secret information of Bestfoods
Baking, and be subject to the Economic Espionage Act of 1996. For recipient's use
only. If you have received this message in error, please delete immediately, and alert
the sender.
=======================================================
