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 rog...@uic.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 >lind...@tsmworks.com > > >On Tue, Dec 8, 2009 at 8:42 AM, Tim Brown <tbr...@cenhud.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: tbr...@cenhud.com <mailto:tbr...@cenhud.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. >> >