Monte, I echo everything that Juraj and Joe suggest, stressing the importance of nailing down your customers'/business' recovery requirements, and then designing a backup solution around those, rather than the other way around.
I trust that when you say 'NT' servers, you mean Win2K and above, otherwise TSM Journalling Engine isn't going to work for you. In the event of a 'disaster, would you really be required to restore *all* of the data, or would the server be rebuilt from the OS/image upwards, and only key data need to be recovered. I commonly ask the question 'do we really need to have 1000's versions of notepad.exe in our TSM server'. Look at the main recovery scenarios that you are putting in a backup solution for: single file corruption/deletion should be possible in a short amount of time. Directory deletion again should be fine for any moderately sized directories. Otherwise, just work out the maths and ask the business if they can wait x hours for a full 40GB restore. Assuming 33% compression and a real-life average of just above 15KB/s (might be more if you're lucky) over your 256Kb line, you're looking at a maximum of 80MB/hour restore rate. If your 40GB server happens to be at the end of this one, you have a little over 20 days to get back your 40GB! Or perhaps my maths is a little skewed here... Rgds, David McClelland Tivoli Storage Manager Certified Consultant Operations Backup and Recovery Projects Shared Infrastructure Development Reuters 85 Fleet Street London EC4P 4AJ -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Salak Juraj Sent: 24 November 2004 16:51 To: [EMAIL PROTECTED] Subject: AW: Remote Backups.... perfect! in addition to this points, do make some planning & tests for restore. Basically, your problem is full restore. Either you can afford to wait long enoung to restore over remote line, (learning about "restart restore" may be important) or produce backup sets and send them per post to the remote location. best regards Juraj > -----Ursprüngliche Nachricht----- > Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag > von Joe Crnjanski > Gesendet: Mittwoch, 24. November 2004 17:25 > An: [EMAIL PROTECTED] > Betreff: Re: Remote Backups.... > > -Use compression > > -Use sub-file backup. (doesn't work on files larger than 2GB; > otherwise enormous improvements) > > -Encryption doesn't hurt if you are moving the data over public > network > (Internet)- will be improved in TSM 5.3 > > -Don't backup system object every day (around 200MB-300MB). > Make additional schedule for system object and C drive (maybe on > weekends) > > -Choose carefully what you need to backup (include/exclude) > > Regards, > Joe C. > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf > Of Michael, Monte > Sent: Tuesday, November 23, 2004 3:32 PM > To: [EMAIL PROTECTED] > Subject: Remote Backups.... > > Fellow TSM administrators: > > My company is currently looking at backing up approximately 40 NT > servers at our remote locations, back to our local data center. Each > location has around 10gb - 40gb of storage, and very minimal daily > change activity on the files. Some of the locations are 256k data > lines, and some are t1 lines. > > Does anyone have a list of best practices? What are some of the > options that you have found to improve the process of remote backups > via TSM to a central location. Any help and input that you can > provide is much appreciated. > > > Thank You, > > > > Monte Michael > > > This communication is for use by the intended recipient and contains > information that may be privileged, confidential or copyrighted under > applicable law. If you are not the intended recipient, you are hereby > formally notified that any use, copying or distribution of this > e-mail, in whole or in part, is strictly prohibited. Please notify > the sender by return e-mail and delete this e-mail from your system. > Unless explicitly and conspicuously designated as "E-Contract > Intended", this e-mail does not constitute a contract offer, a > contract amendment, or an acceptance of a contract offer. > This e-mail does not constitute a consent to the use of sender's > contact information for direct marketing purposes or for transfers of > data to third parties. > > Francais Deutsch Italiano Espanol Portugues Japanese Chinese > Korean > > http://www.DuPont.com/corp/email_disclaimer.html > ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
