Great analysis. Thanks!
I have a hard time imagining how file-based restores could be faster
than image-based restores. File restores have to create each of the
300,000 files, right? and file-create, during restore, is a lot slower
than file-open, during backup.
But I guess if you have a lot of tape drives and not so many files
it'll balance out.
Lindsay Morris
Principal
TSMworks
Tel. 1-859-539-9900
lindsay AT tsmworks DOT com
On Wed, Dec 9, 2009 at 2:02 AM, Roger Deschner <rogerd AT uic DOT edu> wrote:
> 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.
>>>
>>
>
|
