Hello Wanda, Thank you very much for detailed and helpful answers. Fortunately, I have new TSM Server 6.3.3.100 and TSM Client 6.4.0. In addition, I have used recommended way of upgrade for all Windows 2008 servers - perform full backup to new server and keep old server for some time till data is expired. Of course, I have not set SYSTEMSTATEBACKUPMETHOD FULL yet and continue to run incremental SYSTEMSTATE backup on new server. I do not think it is critical. How about proposal to run selective backup for SYSTEMSTATE periodically to expire old backup together with all pointers?
Grigori G. Solonovitch Senior Systems Architect Ahli United Bank Kuwait www.ahliunited.com.kw Please consider the environment before printing this E-mail -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: 01 04 2013 6:37 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] FW: Export node to another server is slow for Windows 2008 R2 64 bit node Hi Grigori, This is a known performance problem with 5.5 servers and 6.2+ Windows clients on Win2K8 (and Win2K12). I've run into it at 3 customers, and it's very painful. http://www-01.ibm.com/support/docview.wss?uid=swg21470662 Easy to prevent the problem with the workaround (described below). Not so easy to fix once you are in the mess. Here's my 2-cent interpretation of the hit: The TSM 5.5 client backed up system state as 1 object. That became a problem when people started implementing Win2K8, because the Win2K8 system state starts at 8G and gets larger on systems with SQL, IIS, etc. So the 6.2 clients started trying to do a true incremental of the system state, backing up only the pieces that actually changed. However, unlike regular flat files, when you restore system state, Microsoft requires that you restore all the pieces at once, even if the pieces were backed up separately. So apparently that requires a lot of pointers connecting the pieces in the TSM DB. On a TSM 5.5 server, all the extra pointers eventually cause the server DB to get tangled in its underwear, causing backup, export, and expiration for system state backups to run very, very slow. I've had 2 customers whose symptom was expiration running for up to a week without finishing. Solutions: * Upgrade the client code to 6.2.3 or later (6.4.0 is good for Win2K8, recommended for Win2K12) and add to the dsm.opt: SYSTEMSTATEBACKUPMETHOD FULL What that does is cause the backup of systemstate to behave the way it used to - that is, back up the system state as 1 chunk with 1 DB entry. You'll get more GB of systemstate, but avoid the pointer tangle. This prevents future problems, but doesn't clean up your existing one. * Upgrade the server to 6.2.3 or higher, as the new V6 DB can handle the pointers without the performance hit. * In your case, I'd suggest not exporting the systemstate filespace at all. Move the client to the new server, back up systemstate there, and allow the old systemstate backups to sit on the old server until they naturally expire. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Grigori Solonovitch Sent: Monday, April 01, 2013 7:00 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] FW: Export node to another server is slow for Windows 2008 R2 64 bit node I think I have identified source of problem. TSM Client/Server is doing incremental backups for Windows 2008 SYSTEMSTATE by saying "ANS4085I Assigned '90236' objects from previous systemstate backup to the new systemstate backup." Assigned objects are not visible in occupancy reports, but visible during export/import or "delete filespace..." operations. Export is sending all assigned SYSTEMSTATE objects to be imported on a target server. Number of objects is huge, but there is no real files. So network speed is extremely low. Is this correct behavior? Or some bug in 5.5.6 with client 6.2.4? Grigori G. Solonovitch Senior Systems Architect Ahli United Bank Kuwait www.ahliunited.com.kw<http://www.ahliunited.com.kw> Please consider the environment before printing this E-mail From: Grigori Solonovitch Sent: 27 03 2013 11:57 AM To: ADSM: Dist Stor Manager (ADSM-L@VM.MARIST.EDU<mailto:ADSM-L@VM.MARIST.EDU>) Subject: Export node to another server is slow for Windows 2008 R2 64 bit node Source: TSM 5.5.6 for AIX 5.3-12-06 Target: TSM 6.3.3.100 for AIX 7.1-01-06 It looks "export node" is very slow when I am trying to move all data for Windows 2008 R2 64 bit (speed is less than 1MB/s). It is almost unbelievable, but I have moved a few Windows 2003 servers with speed 10-20MB/s, but all Windows 2008 nodes which I tried to move have speed at least 10 times less. Maybe somebody can comment this? Grigori G. Solonovitch Senior Technical Architect Ahli United Bank Kuwait www.ahliunited.com.kw<http://www.ahliunited.com.kw<http://www.ahliunited.com.kw<http://www.ahliunited.com.kw>> Please consider the environment before printing this E-mail ________________________________ CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software. Please consider the environment before printing this Email. ________________________________ CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software.