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 lind...@tsmworks.com On Wed, Dec 9, 2009 at 2:02 AM, Roger Deschner <rog...@uic.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 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. >>> >> >