Mike, backupsets... back in version 3.7... where mainly designed for server/network less restores, if these restores are part of the everyday workload/design then fine, they will do the job, if they are part of the DR scheme/design then again is fine, it all depends on yr overall design. Backupsets are reliable and they are working as advertised and designed, maybe not as user/admin friendly as we would like to have them, however reliable.
The excessive number of objects can be resolved in the Operating System level and design, with a packaging/zipping tool. Also, since I was part of the TSM 5.1 Beta testing, I would like to inform you that in TSM 5.1.x there are a couple performance enhancements for the backupset processing, therefore the future is there as well. Cheers. Say Hi to Brad Virgil... Othonas Xixis "Intelligence, imagination, and knowledge are essential resources, but only effectiveness converts them into results. By themselves, they only set limits to what can be attained", Peter F. Drucker. Michael Moore <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 05/01/2002 01:28:31 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: 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. **********************************************************************