The basic principle of backup is that it must be separated from its
source. Anything else is just RAID-xx. It should be separated by both
distance and time, with time being more important. TSM makes time
separation easier, storing multiple previous copies of only the
different data with minimal overhead. TSM "point-in-time" restore is
perhaps the miracle that best proves the ingenuity of the basic TSM
database-based progressive backup architecture.
It has been my experience in actual disaster scenarios, that a restore
from traditional TSM progressive backups, will run at "network speed"
from collocated tape with properly grouped collocation groups. (or from
disk) Image backups would not increase restore speed much, and could
even slow down a restore compared to a restore from TSM collocated tape
if you can get several tapes mounted at once. In that disaster I had
about 8 years ago, I got 4 tape drives reading tapes at once and pushing
files onto the net to the client node. The client couldn't believe it,
but restoring individual files was faster than restoring an image.
The most frequent thing that real backups protect you from is someone
having an "oops moment". I am perfectly capable of manually corrupting
the config file for a vital app while trying to change it. Going back to
last night's backup copy is necessary. That's the time separation.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
Academic Computing & Communications Center
=================== "If you open that Pandora's Box, ===================
=========== all sorts of Trojan Horses will jump out of it." ===========
(from a "bad writing" competition)
On Tue, 8 Dec 2009, Lindsay Morris wrote:
>Good point.
>Similarly, we're all happy with lightning-fast restores from remotely
>mirrored disks.
>But thinking of that as a BACKUP solution leaves you open to at least these
>scenarios:
>-- viruses corrupt the primary disk, and the mirror at the same time;
>-- A database maintenance script gets run with "2009" instead of "2008" (for
>example), and trashes the database AND its mirror as above
>-- brownouts can do similar things (so I've heard; never been through one)
>
>Would anybody else offer scenarios where we would need traditional backups
>even though Mirroring, VCB backups, etc. are in place?
>
>Lindsay Morris
>Principal
>TSMworks
>Tel. 1-859-539-9900
>lindsay AT tsmworks DOT com
>
>
>On Tue, Dec 8, 2009 at 8:42 AM, Tim Brown <tbrown AT cenhud DOT com> wrote:
>
>> I just want to emphasize the importance of having multiple backup
>> scenarios.
>>
>> This includes TSM incremental, image and VCB backups for VMWare servers.
>> We recently incorporated VCB backups. One week after that we had a critical
>> VMEare server fail and the VCB backup saved us !!
>>
>> We could of restored with typical TSM incremental backups but the VCB
>> restore
>> was quicker.
>>
>> Tim Brown
>> Systems Specialist - Project Leader
>> Central Hudson Gas & Electric
>> 284 South Ave
>> Poughkeepsie, NY 12601
>> Email: tbrown AT cenhud DOT com <mailto:tbrown AT cenhud DOT com>
>> Phone: 845-486-5643
>> Fax: 845-486-5921
>> Cell: 845-235-4255
>>
>>
>> This message contains confidential information and is only for the intended
>> recipient. If the reader of this message is not the intended recipient, or
>> an employee or agent responsible for delivering this message to the intended
>> recipient, please notify the sender immediately by replying to this note and
>> deleting all copies and attachments. Thank you.
>>
>
|
