Michael, We successfully perform DR on NT4.0 and W2K clients successfully without using backupsets and others on this list do as well. We use them on a couple of larger nodes once a month for snapshots of file data, but that's about it.
So if you are worried about being able to do a disaster recovery of a Windows based client, I don't think you should be. It can, and has been successfully performed. My two cents..... Matt Adams Tivoli Storage Manager Team Hermitage Site Tech Deloitte & Touche USA LLP 615.882.6861 -----Original Message----- From: Michael Moore [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 12:29 PM To: [EMAIL PROTECTED] Subject: Re: Using Backupsets for Disaster Recovery John, To answer your questions.: Yes, MPThreading is turned on. Yes, it is getting plenty of processor. Region is set at 512M. I have sent to IBM dumps that were taken during the "hung" periods. What I have been told, is that there is a large number of locks being generated during that period, and that everything is working as designed. I can see why there are a large number of locks. The backupset that causes this has 1.6+ million objects (and growing daily). I have also been told that soon there will be another client node the same size (200+gb). The biggest hurdle for me to overcome is the reliance on these backupsets for DR purposes. As far as I can tell, they were not originally designed for DR purposes. If they were, I believe they would be managed under DRM. Michael Moore VF Services Inc. 121 Smith Street Greensboro, NC 27420-1488 Voice: 336-332-4423 Fax: 336-332-4544 "Seay, Paul" <seay_pd@NAPTH To: [EMAIL PROTECTED] EON.COM> cc: Sent by: Subject: Re: Using Backupsets for Disaster Recovery "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] IST.EDU> 05/01/02 11:59 AM Please respond to "ADSM: Dist Stor Manager" My situation is very different from many TSM sites. I have no tape drives in my servers so I have no way to create backupsets that can be read by the client because 3590 is not supported based on what I know. And, anyway, it would not be feasible. Sorry, I did not fully explain why they are too cumbersome for my environment. When you have as many servers as I do and they all have hundreds of gigabytes it is just not feasible. Different strokes for different folks. That is the beauty of TSM. Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 -----Original Message----- From: John Naylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 5:49 AM To: [EMAIL PROTECTED] Subject: Re: Using Backupsets for Disaster Recovery Michael, At last, something I do not entirely agree with from Paul. I would not use backupsets for everything, but they are excellent for speading up the restore of large data servers. Provided you take them regularly and I think twice weekly is overkill, then the fromdate overhead to bring in subsequent backups is not too great. I think weekly or every two weeks would be adequate, but I suppose the answer for you is to test to see what meets your recovery requiremnts. I do not think that your server should be hanging. Are you running "MPThreading Yes" ? If you are satisfied that TSM is getting enogh processor,check with your OS390 performance person, then the other thing to check is how long since TSM was recycled, It is common for OS390 systems not to need an IPL for months at a time and for TSM only to be recycled when these IPLs come along. In my experience TSM does get slower if not regularly recycled, and I would suggest that this should be done on a monthly basis. Hope this helps, John "Seay, Paul" <[EMAIL PROTECTED]> on 05/01/2002 09:20:13 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: (bcc: John Naylor/HAV/SSE) Subject: Re: Using Backupsets for Disaster Recovery We do not because it is too cumbersome. The answer is what were Backupsets really created for? When Tivoli Sales comes in they sell backupsets as a way to send a remote user/site (laptop users are the main ones) a place to start a recovery from so that the transmission of the entire system over a slow link is eliminated. The backupset is restored first then a restore to bring in all the updates. Dramatic savings for those slow line connected users (56K). It can be used for servers, but that was not the backupsets' original mission in life. Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 -----Original Message----- From: Michael Moore [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 4:21 PM To: [EMAIL PROTECTED] Subject: Using Backupsets for Disaster Recovery Does anyone use Backupsets of NT/W2K machines for Disaster Recovery purposes? We are currently running TSM v4.1.5.3, on OS/390 v2.8. Most of our NT/W2K clients are running v.4.2 of the Backup/Archive client. Currently we backup approximately 150 client nodes, and generate backupsets for 28 of those. The backupsets are not created daily, but approximately 2 per week for each node. It does cause some problems with the server. The server seems to "hang" during certain backupsets (mostly large nodes). They are requesting additional backusets, and some daily. I fear this will only cause additional problems with the server. They do rely on the backupsets for Disaster Recovery, but I would like to get them away from that. Any ideas? Thanks! Michael Moore ********************************************************************** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric, Southern Electric, SWALEC and S+S are trading names of the Scottish and Southern Energy Group. ********************************************************************** - This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. - If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.