Re: Very slow restores (days), hours to locate files
Hello Robin, the TSM server does not maintain the LTO memory cartridge and would therefore not be the source of the corruption. A corrupted memory cartridge comes from defective media, faulty/dirty hardware/drive or firmware/microcode problem. As others have already recommended, you should consider upgrading the firmware of the LTO drives to take care of past problems with LTO CM. It appears the latest firmware for the LTO GenII drives at this time is 53Y2, for fiber attached drives. You can verify the firmware of your drives using lscfg -vl rmt*. For a list of what is fixed in 53Y2, see here : http://www-1.ibm.com/support/docview.wss?rs=0uid=ssg1S1002360 Have a great day ! Rejean Larivee IBM Tivoli Storage Manager support Robin Sharpe [EMAIL PROTECTED] LEX.COM To Sent by: ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager [EMAIL PROTECTED] Subject .EDU Re: Very slow restores (days), hours to locate files 07/06/2005 04:12 PM Please respond to ADSM: Dist Stor Manager Sorry about the omission, Rich. These restores were started via the Windows GUI. I believe they just selected the C: drive and specified Restore if newer (an option which I don't think is available via the command line!). I believe this created a No-Query Restore, because it did create a Restartable Restore AFAIK there is a one-to-one correspondence (right?) In the meantime, I checked the Technote... Then, I checked my Activity Log for the last 24 hours... and I found 33 LTO volumes that presented the cartridge memory message! So, now I have the smoking gun, and I suppose I could do move data against those volumes, but I suspect there are many more, and I would like to know what's causing the corruption and how to prevent it! If I don't hear anything from the group, I'll open a call with Tivoli. Thanks very much for the information! -Robin Richard Sims [EMAIL PROTECTED] Sent by: ADSM: To: ADSM-L@VM.MARIST.EDU Dist Storcc: Manager Subject: [EMAIL PROTECTED] Re: Very slow restores (days), hours to locate files T.EDU 07/06/2005 10:30 AM Please respond to ADSM: Dist Stor Manager Please, everyone, when posting questions about restorals, give details about the manner in which the restoral was invoked so that we can get a sense of what kind is involved (NQR, Classic) and what is involved. Now... Robin, have a look at IBM Technote 1209563, which I ran across in doing research yesterday. I recall such long-duration- restores in the past, and as I recall they have involved the factors noted in the Technote. LTO is also known for backhitch delays, so that's another contributor in positioning on tape. Richard Sims
Re: Very slow restores (days), hours to locate files
TO identify the volumes with the corrupted CM, just do a checkin with CHECKL=YES. This will then issue a tapealert message for a tape that has a bad/corrupted CM. If it's a scratch tape, then the CM will be written as you write to the tape. For tapes with data on them, you can MOVE DATA to another drive and let it go scratch, or use the tapeutil utility to mount the tape and forward to the end of the tape. That causes the drive to re-write the CM index. That is after you've identified the problem that is corrupting your CM chips. It could be firmware, but at one client site of mine, it was a faulty drive. Bill Boyer Some days you're the bug, some days you're the windshield - ?? -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Rejean Larivee Sent: Thursday, July 07, 2005 10:51 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Very slow restores (days), hours to locate files Hello Robin, the TSM server does not maintain the LTO memory cartridge and would therefore not be the source of the corruption. A corrupted memory cartridge comes from defective media, faulty/dirty hardware/drive or firmware/microcode problem. As others have already recommended, you should consider upgrading the firmware of the LTO drives to take care of past problems with LTO CM. It appears the latest firmware for the LTO GenII drives at this time is 53Y2, for fiber attached drives. You can verify the firmware of your drives using lscfg -vl rmt*. For a list of what is fixed in 53Y2, see here : http://www-1.ibm.com/support/docview.wss?rs=0uid=ssg1S1002360 Have a great day ! Rejean Larivee IBM Tivoli Storage Manager support Robin Sharpe [EMAIL PROTECTED] LEX.COM To Sent by: ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager [EMAIL PROTECTED] Subject .EDU Re: Very slow restores (days), hours to locate files 07/06/2005 04:12 PM Please respond to ADSM: Dist Stor Manager Sorry about the omission, Rich. These restores were started via the Windows GUI. I believe they just selected the C: drive and specified Restore if newer (an option which I don't think is available via the command line!). I believe this created a No-Query Restore, because it did create a Restartable Restore AFAIK there is a one-to-one correspondence (right?) In the meantime, I checked the Technote... Then, I checked my Activity Log for the last 24 hours... and I found 33 LTO volumes that presented the cartridge memory message! So, now I have the smoking gun, and I suppose I could do move data against those volumes, but I suspect there are many more, and I would like to know what's causing the corruption and how to prevent it! If I don't hear anything from the group, I'll open a call with Tivoli. Thanks very much for the information! -Robin Richard Sims [EMAIL PROTECTED] Sent by: ADSM: To: ADSM-L@VM.MARIST.EDU Dist Storcc: Manager Subject: [EMAIL PROTECTED] Re: Very slow restores (days), hours to locate files T.EDU 07/06/2005 10:30 AM Please respond to ADSM: Dist Stor Manager Please, everyone, when posting questions about restorals, give details about the manner in which the restoral was invoked so that we can get a sense of what kind is involved (NQR, Classic) and what is involved. Now... Robin, have a look at IBM Technote 1209563, which I ran across in doing research yesterday. I recall such long-duration- restores in the past, and as I recall they have involved the factors noted in the Technote. LTO is also known for backhitch delays, so that's another contributor in positioning on tape. Richard Sims
Re: Very slow restores (days), hours to locate files
Thanks for the tip, Bill. But in our environment, (618 tapes in the L700 library, plus over 1000 on a rack), that would take quite a long time... BTW, we think it's a firmware problem... We are running 38D0 on our LTO-2 drives. I just spoke to my STK CE, and he said the latest STK has certified is 4C60, which we will install tomorrow. We're also upgrading the library code from 3.07.00 to 3.09.00. -Robin William Boyer [EMAIL PROTECTED] T.NET To: ADSM-L@VM.MARIST.EDU Sent by: ADSM: cc: Dist StorSubject: Manager Re: Very slow restores (days), hours to locate files [EMAIL PROTECTED] T.EDU 07/07/2005 11:11 AM Please respond to ADSM: Dist Stor Manager TO identify the volumes with the corrupted CM, just do a checkin with CHECKL=YES. This will then issue a tapealert message for a tape that has a bad/corrupted CM. If it's a scratch tape, then the CM will be written as you write to the tape. For tapes with data on them, you can MOVE DATA to another drive and let it go scratch, or use the tapeutil utility to mount the tape and forward to the end of the tape. That causes the drive to re-write the CM index. That is after you've identified the problem that is corrupting your CM chips. It could be firmware, but at one client site of mine, it was a faulty drive. Bill Boyer Some days you're the bug, some days you're the windshield - ?? -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Rejean Larivee Sent: Thursday, July 07, 2005 10:51 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Very slow restores (days), hours to locate files Hello Robin, the TSM server does not maintain the LTO memory cartridge and would therefore not be the source of the corruption. A corrupted memory cartridge comes from defective media, faulty/dirty hardware/drive or firmware/microcode problem. As others have already recommended, you should consider upgrading the firmware of the LTO drives to take care of past problems with LTO CM. It appears the latest firmware for the LTO GenII drives at this time is 53Y2, for fiber attached drives. You can verify the firmware of your drives using lscfg -vl rmt*. For a list of what is fixed in 53Y2, see here : http://www-1.ibm.com/support/docview.wss?rs=0uid=ssg1S1002360 Have a great day ! Rejean Larivee IBM Tivoli Storage Manager support Robin Sharpe [EMAIL PROTECTED] LEX.COM To Sent by: ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager [EMAIL PROTECTED] Subject .EDU Re: Very slow restores (days), hours to locate files 07/06/2005 04:12 PM Please respond to ADSM: Dist Stor Manager Sorry about the omission, Rich. These restores were started via the Windows GUI. I believe they just selected the C: drive and specified Restore if newer (an option which I don't think is available via the command line!). I believe this created a No-Query Restore, because it did create a Restartable Restore AFAIK there is a one-to-one correspondence (right?) In the meantime, I checked the Technote... Then, I checked my Activity Log for the last 24 hours... and I found 33 LTO volumes that presented the cartridge memory message! So, now I have the smoking gun, and I suppose I could do move data against those volumes, but I suspect there are many more, and I would like to know what's causing the corruption and how to prevent it! If I don't hear anything from the group, I'll open a call with Tivoli. Thanks very much for the information! -Robin Richard Sims [EMAIL PROTECTED] Sent by: ADSM: To: ADSM-L@VM.MARIST.EDU Dist Storcc: Manager Subject: [EMAIL PROTECTED] Re: Very slow restores (days), hours to locate files T.EDU 07/06/2005 10:30 AM Please respond to ADSM: Dist Stor Manager Please, everyone, when posting questions about restorals, give details about the manner in which the restoral was invoked so that we can get a sense of what kind is involved (NQR, Classic) and what is involved. Now... Robin, have a look at IBM Technote 1209563, which I ran across in doing
Re: Very slow restores (days), hours to locate files
Robin, I hope the LTO firmware resolves your problem. However, I have seen a similar situation for Windows clients in our shop and it was not a tape drive issue. The situation here was that we had a tape stgpool, 3590Ks /3590E1A drives, collocated by node, that reached its maxscratch value. This led to what some folks call imperfect collocation where even though the stgpool is setup to collocate by node, data for more than one node can end up on the same tape. The problem we had with the node intermix in a collocated by node pool showed itself with a situation that sounds similar to yours. We attempted to run a restore of an 8GB Win2k C: drive about 50% full and saw very long delays where nothing appeared to be happening. A tape change would occur, some data would transfer, and then a VERY long pause before a mount request for the next tape. Query Session while tape was mounted showed what your Q SE showed below, session in Run state, zero seconds wait time, but send and recv byte counts remain unchanged. While not as many but similar to you, our incremental backups of the servers C: drive had files spread around a number of tapes. We never determined the root cause of the think time between tape mount requests. We resolved the issue by moving tapes in our stgpool to a new pool with a high MAXSCR value effectively re-collocating the data. All restores ran very happy after that. Sorry I could not provide a root cause of our situation but that's how we addressed it. Just curious but do the 310 tapes you identified also contain data for other nodes and are you using collocation? Jeff Connor National Grid USA -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Robin Sharpe Sent: Wednesday, July 06, 2005 10:10 AM To: ADSM-L@VM.MARIST.EDU Subject: Very slow restores (days), hours to locate files Hi guys, We're having problems restoring some windows servers (W2K)... The servers in question had some disk problems and are being rebuilt, so the Windows admins are restoring the C: drive. It is an 8GB drive and less than 50% used, so only 4GB to restore. It has taken several days to restore. I know one of our problems is that the data is spread over hundreds of volumes (literally... I counted 310 from a volumeusage query). Another problem is that we have an overflowed library, but we have loaded all of the tapes from the Windows storage pool. What I don't understand is why it takes so long to locate a file once the tape is mounted. We have seen the same tape mounted for hours before any data is transferred. Here is an excerpt from a q se f=d of a restore that is running right now: Sess Number: 1,143 Comm. Method: TCP/IP Sess State: Run Wait Time: 0 S Bytes Sent: 670.9 M Bytes Recvd: 58.2 K Sess Type: Node Platform: WinNT Client Name: WANO01 Media Access Status: Current input volume(s): 200658,(2279 Seconds) User Name: Date/Time First Data Sent: Proxy By Storage Agent: This restore has been running for almost 12 hours now (they have been restarting them periodically). There has been NO DATA transferred from that tape in the 38 minutes it has been mounted... I know this from doing an lsof command and looking at the offset which indicates the number of bytes transferred. I know that when I restore a single file, it can be found within seconds of mounting a tape (these are all LTO-2)... so, why does it take so long in this case? Is TSM actually reading the entire tape? If so, wouldn't I see lots of data being transferred? Or is there some kind of SCSI command that allows the drive to read and compare the data it gets? I thought TSM stored actual locations of the files in the DB, so it could quickly find any file (or aggregate) without reading the whole tape... I've been searching the literature, and I can't find any details on this. The TSM server is on HP-UX 11i, IBM LTO-2 drives, fiber attached, in a STK L700 library. Also, my DB is huge (314GB), and we are currently (for the last year) unable to delete anything, so we have many versions of volatile files. We are planning to split our environment into several TSMs, and in the short term, our windows admins will start doing weekly selective backups of the C: drives to consolidate active versions on few tapes. Thanks for any thoughts on this Robin Sharpe Berlex Labs This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know.
Re: Very slow restores (days), hours to locate files
The pool in question here is not collocated, so I expected to have lots of tape mounts but the long period of inactivity is what puzzles us. I've also seen notes indicating that the No Query Restore may be the cause... I'll suggest to our Windows guys to try a classic restore. -Robin Connor, Jeffrey P. [EMAIL PROTECTED] To: ADSM-L@VM.MARIST.EDU .NGRID.COMcc: Sent by: ADSM:Subject: Dist Stor Manager Re: Very slow restores (days), hours to locate files [EMAIL PROTECTED] EDU 07/07/2005 04:39 PM Please respond to ADSM: Dist Stor Manager Robin, I hope the LTO firmware resolves your problem. However, I have seen a similar situation for Windows clients in our shop and it was not a tape drive issue. The situation here was that we had a tape stgpool, 3590Ks /3590E1A drives, collocated by node, that reached its maxscratch value. This led to what some folks call imperfect collocation where even though the stgpool is setup to collocate by node, data for more than one node can end up on the same tape. The problem we had with the node intermix in a collocated by node pool showed itself with a situation that sounds similar to yours. We attempted to run a restore of an 8GB Win2k C: drive about 50% full and saw very long delays where nothing appeared to be happening. A tape change would occur, some data would transfer, and then a VERY long pause before a mount request for the next tape. Query Session while tape was mounted showed what your Q SE showed below, session in Run state, zero seconds wait time, but send and recv byte counts remain unchanged. While not as many but similar to you, our incremental backups of the servers C: drive had files spread around a number of tapes. We never determined the root cause of the think time between tape mount requests. We resolved the issue by moving tapes in our stgpool to a new pool with a high MAXSCR value effectively re-collocating the data. All restores ran very happy after that. Sorry I could not provide a root cause of our situation but that's how we addressed it. Just curious but do the 310 tapes you identified also contain data for other nodes and are you using collocation? Jeff Connor National Grid USA -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Robin Sharpe Sent: Wednesday, July 06, 2005 10:10 AM To: ADSM-L@VM.MARIST.EDU Subject: Very slow restores (days), hours to locate files Hi guys, We're having problems restoring some windows servers (W2K)... The servers in question had some disk problems and are being rebuilt, so the Windows admins are restoring the C: drive. It is an 8GB drive and less than 50% used, so only 4GB to restore. It has taken several days to restore. I know one of our problems is that the data is spread over hundreds of volumes (literally... I counted 310 from a volumeusage query). Another problem is that we have an overflowed library, but we have loaded all of the tapes from the Windows storage pool. What I don't understand is why it takes so long to locate a file once the tape is mounted. We have seen the same tape mounted for hours before any data is transferred. Here is an excerpt from a q se f=d of a restore that is running right now: Sess Number: 1,143 Comm. Method: TCP/IP Sess State: Run Wait Time: 0 S Bytes Sent: 670.9 M Bytes Recvd: 58.2 K Sess Type: Node Platform: WinNT Client Name: WANO01 Media Access Status: Current input volume(s): 200658,(2279 Seconds) User Name: Date/Time First Data Sent: Proxy By Storage Agent: This restore has been running for almost 12 hours now (they have been restarting them periodically). There has been NO DATA transferred from that tape in the 38 minutes it has been mounted... I know this from doing an lsof command and looking at the offset which indicates the number of bytes transferred. I know that when I restore a single file, it can be found within seconds of mounting a tape (these are all LTO-2)... so, why does it take so long in this case? Is TSM actually reading the entire tape? If so, wouldn't I see lots of data being transferred? Or is there some kind of SCSI command that allows the drive to read and compare the data it gets? I thought TSM stored actual locations of the files in the DB, so it could quickly find any file (or aggregate) without reading the whole tape... I've been searching the literature, and I can't find any details on this. The TSM server is on HP-UX 11i, IBM LTO-2 drives, fiber attached, in a STK L700 library. Also, my
Re: Very slow restores (days), hours to locate files
In a sense, due to reaching maxscr, our pool was not collocated as well. Our issue was not the number of mounts but the long inactivity periods as you described. If you do find the cause, please post it on the listserv. Thanks Jeff -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Robin Sharpe Sent: Thursday, July 07, 2005 4:51 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Very slow restores (days), hours to locate files The pool in question here is not collocated, so I expected to have lots of tape mounts but the long period of inactivity is what puzzles us. I've also seen notes indicating that the No Query Restore may be the cause... I'll suggest to our Windows guys to try a classic restore. -Robin Connor, Jeffrey P. [EMAIL PROTECTED] To: ADSM-L@VM.MARIST.EDU .NGRID.COMcc: Sent by: ADSM:Subject: Dist Stor Manager Re: Very slow restores (days), hours to locate files [EMAIL PROTECTED] EDU 07/07/2005 04:39 PM Please respond to ADSM: Dist Stor Manager Robin, I hope the LTO firmware resolves your problem. However, I have seen a similar situation for Windows clients in our shop and it was not a tape drive issue. The situation here was that we had a tape stgpool, 3590Ks /3590E1A drives, collocated by node, that reached its maxscratch value. This led to what some folks call imperfect collocation where even though the stgpool is setup to collocate by node, data for more than one node can end up on the same tape. The problem we had with the node intermix in a collocated by node pool showed itself with a situation that sounds similar to yours. We attempted to run a restore of an 8GB Win2k C: drive about 50% full and saw very long delays where nothing appeared to be happening. A tape change would occur, some data would transfer, and then a VERY long pause before a mount request for the next tape. Query Session while tape was mounted showed what your Q SE showed below, session in Run state, zero seconds wait time, but send and recv byte counts remain unchanged. While not as many but similar to you, our incremental backups of the servers C: drive had files spread around a number of tapes. We never determined the root cause of the think time between tape mount requests. We resolved the issue by moving tapes in our stgpool to a new pool with a high MAXSCR value effectively re-collocating the data. All restores ran very happy after that. Sorry I could not provide a root cause of our situation but that's how we addressed it. Just curious but do the 310 tapes you identified also contain data for other nodes and are you using collocation? Jeff Connor National Grid USA -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Robin Sharpe Sent: Wednesday, July 06, 2005 10:10 AM To: ADSM-L@VM.MARIST.EDU Subject: Very slow restores (days), hours to locate files Hi guys, We're having problems restoring some windows servers (W2K)... The servers in question had some disk problems and are being rebuilt, so the Windows admins are restoring the C: drive. It is an 8GB drive and less than 50% used, so only 4GB to restore. It has taken several days to restore. I know one of our problems is that the data is spread over hundreds of volumes (literally... I counted 310 from a volumeusage query). Another problem is that we have an overflowed library, but we have loaded all of the tapes from the Windows storage pool. What I don't understand is why it takes so long to locate a file once the tape is mounted. We have seen the same tape mounted for hours before any data is transferred. Here is an excerpt from a q se f=d of a restore that is running right now: Sess Number: 1,143 Comm. Method: TCP/IP Sess State: Run Wait Time: 0 S Bytes Sent: 670.9 M Bytes Recvd: 58.2 K Sess Type: Node Platform: WinNT Client Name: WANO01 Media Access Status: Current input volume(s): 200658,(2279 Seconds) User Name: Date/Time First Data Sent: Proxy By Storage Agent: This restore has been running for almost 12 hours now (they have been restarting them periodically). There has been NO DATA transferred from that tape in the 38 minutes it has been mounted... I know this from doing an lsof command and looking at the offset which indicates the number of bytes transferred. I know that when I restore a single file, it can be found within seconds of mounting a tape (these are all LTO-2)... so, why does it take so long in this case? Is TSM actually reading the entire tape
Very slow restores (days), hours to locate files
Hi guys, We're having problems restoring some windows servers (W2K)... The servers in question had some disk problems and are being rebuilt, so the Windows admins are restoring the C: drive. It is an 8GB drive and less than 50% used, so only 4GB to restore. It has taken several days to restore. I know one of our problems is that the data is spread over hundreds of volumes (literally... I counted 310 from a volumeusage query). Another problem is that we have an overflowed library, but we have loaded all of the tapes from the Windows storage pool. What I don't understand is why it takes so long to locate a file once the tape is mounted. We have seen the same tape mounted for hours before any data is transferred. Here is an excerpt from a q se f=d of a restore that is running right now: Sess Number: 1,143 Comm. Method: TCP/IP Sess State: Run Wait Time: 0 S Bytes Sent: 670.9 M Bytes Recvd: 58.2 K Sess Type: Node Platform: WinNT Client Name: WANO01 Media Access Status: Current input volume(s): 200658,(2279 Seconds) User Name: Date/Time First Data Sent: Proxy By Storage Agent: This restore has been running for almost 12 hours now (they have been restarting them periodically). There has been NO DATA transferred from that tape in the 38 minutes it has been mounted... I know this from doing an lsof command and looking at the offset which indicates the number of bytes transferred. I know that when I restore a single file, it can be found within seconds of mounting a tape (these are all LTO-2)... so, why does it take so long in this case? Is TSM actually reading the entire tape? If so, wouldn't I see lots of data being transferred? Or is there some kind of SCSI command that allows the drive to read and compare the data it gets? I thought TSM stored actual locations of the files in the DB, so it could quickly find any file (or aggregate) without reading the whole tape... I've been searching the literature, and I can't find any details on this. The TSM server is on HP-UX 11i, IBM LTO-2 drives, fiber attached, in a STK L700 library. Also, my DB is huge (314GB), and we are currently (for the last year) unable to delete anything, so we have many versions of volatile files. We are planning to split our environment into several TSMs, and in the short term, our windows admins will start doing weekly selective backups of the C: drives to consolidate active versions on few tapes. Thanks for any thoughts on this Robin Sharpe Berlex Labs
Re: Very slow restores (days), hours to locate files
Please, everyone, when posting questions about restorals, give details about the manner in which the restoral was invoked so that we can get a sense of what kind is involved (NQR, Classic) and what is involved. Now... Robin, have a look at IBM Technote 1209563, which I ran across in doing research yesterday. I recall such long-duration- restores in the past, and as I recall they have involved the factors noted in the Technote. LTO is also known for backhitch delays, so that's another contributor in positioning on tape. Richard Sims
Re: Very slow restores (days), hours to locate files
You are at which firmware on IBM LTO2 FC ? We had last year big problems with firmware 38D0 , until we switched to 4770. You can see that problem if you use tapeutil and skip to EOD and see how long it takes. Should be some minutes, was with our firmware one hour and more. Just a guess. Regards Matthias Robin Sharpe wrote: Hi guys, We're having problems restoring some windows servers (W2K)... The servers in question had some disk problems and are being rebuilt, so the Windows admins are restoring the C: drive. It is an 8GB drive and less than 50% used, so only 4GB to restore. It has taken several days to restore. I know one of our problems is that the data is spread over hundreds of volumes (literally... I counted 310 from a volumeusage query). Another problem is that we have an overflowed library, but we have loaded all of the tapes from the Windows storage pool. What I don't understand is why it takes so long to locate a file once the tape is mounted. We have seen the same tape mounted for hours before any data is transferred. Here is an excerpt from a q se f=d of a restore that is running right now: Sess Number: 1,143 Comm. Method: TCP/IP Sess State: Run Wait Time: 0 S Bytes Sent: 670.9 M Bytes Recvd: 58.2 K Sess Type: Node Platform: WinNT Client Name: WANO01 Media Access Status: Current input volume(s): 200658,(2279 Seconds) User Name: Date/Time First Data Sent: Proxy By Storage Agent: This restore has been running for almost 12 hours now (they have been restarting them periodically). There has been NO DATA transferred from that tape in the 38 minutes it has been mounted... I know this from doing an lsof command and looking at the offset which indicates the number of bytes transferred. I know that when I restore a single file, it can be found within seconds of mounting a tape (these are all LTO-2)... so, why does it take so long in this case? Is TSM actually reading the entire tape? If so, wouldn't I see lots of data being transferred? Or is there some kind of SCSI command that allows the drive to read and compare the data it gets? I thought TSM stored actual locations of the files in the DB, so it could quickly find any file (or aggregate) without reading the whole tape... I've been searching the literature, and I can't find any details on this. The TSM server is on HP-UX 11i, IBM LTO-2 drives, fiber attached, in a STK L700 library. Also, my DB is huge (314GB), and we are currently (for the last year) unable to delete anything, so we have many versions of volatile files. We are planning to split our environment into several TSMs, and in the short term, our windows admins will start doing weekly selective backups of the C: drives to consolidate active versions on few tapes. Thanks for any thoughts on this Robin Sharpe Berlex Labs -- -- Matthias Feyerabend | [EMAIL PROTECTED] Gesellschaft fuer Schwerionenforschung | phone +49-6159-71-2519 Planckstr. 1| privat +49-6151-718781 D-62291 Darmstadt | fax +49-6159-71-2519
Re: Very slow restores (days), hours to locate files
You should investigate the latest LTO2 firmware, 53Y2L2F.ro Our drives were all at 4772 and we were having a variety of problems (much better than 38D0). Since I upgraded to 53Y2, things have calmed down quite a bit. Matthias Feyerabend [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 07/06/2005 01:49 PM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] Very slow restores (days), hours to locate files You are at which firmware on IBM LTO2 FC ? We had last year big problems with firmware 38D0 , until we switched to 4770. You can see that problem if you use tapeutil and skip to EOD and see how long it takes. Should be some minutes, was with our firmware one hour and more. Just a guess. Regards Matthias Robin Sharpe wrote: Hi guys, We're having problems restoring some windows servers (W2K)... The servers in question had some disk problems and are being rebuilt, so the Windows admins are restoring the C: drive. It is an 8GB drive and less than 50% used, so only 4GB to restore. It has taken several days to restore. I know one of our problems is that the data is spread over hundreds of volumes (literally... I counted 310 from a volumeusage query). Another problem is that we have an overflowed library, but we have loaded all of the tapes from the Windows storage pool. What I don't understand is why it takes so long to locate a file once the tape is mounted. We have seen the same tape mounted for hours before any data is transferred. Here is an excerpt from a q se f=d of a restore that is running right now: Sess Number: 1,143 Comm. Method: TCP/IP Sess State: Run Wait Time: 0 S Bytes Sent: 670.9 M Bytes Recvd: 58.2 K Sess Type: Node Platform: WinNT Client Name: WANO01 Media Access Status: Current input volume(s): 200658,(2279 Seconds) User Name: Date/Time First Data Sent: Proxy By Storage Agent: This restore has been running for almost 12 hours now (they have been restarting them periodically). There has been NO DATA transferred from that tape in the 38 minutes it has been mounted... I know this from doing an lsof command and looking at the offset which indicates the number of bytes transferred. I know that when I restore a single file, it can be found within seconds of mounting a tape (these are all LTO-2)... so, why does it take so long in this case? Is TSM actually reading the entire tape? If so, wouldn't I see lots of data being transferred? Or is there some kind of SCSI command that allows the drive to read and compare the data it gets? I thought TSM stored actual locations of the files in the DB, so it could quickly find any file (or aggregate) without reading the whole tape... I've been searching the literature, and I can't find any details on this. The TSM server is on HP-UX 11i, IBM LTO-2 drives, fiber attached, in a STK L700 library. Also, my DB is huge (314GB), and we are currently (for the last year) unable to delete anything, so we have many versions of volatile files. We are planning to split our environment into several TSMs, and in the short term, our windows admins will start doing weekly selective backups of the C: drives to consolidate active versions on few tapes. Thanks for any thoughts on this Robin Sharpe Berlex Labs -- -- Matthias Feyerabend | [EMAIL PROTECTED] Gesellschaft fuer Schwerionenforschung | phone +49-6159-71-2519 Planckstr. 1 | privat +49-6151-718781 D-62291 Darmstadt| fax +49-6159-71-2519
Re: Very slow restores (days), hours to locate files
Sorry about the omission, Rich. These restores were started via the Windows GUI. I believe they just selected the C: drive and specified Restore if newer (an option which I don't think is available via the command line!). I believe this created a No-Query Restore, because it did create a Restartable Restore AFAIK there is a one-to-one correspondence (right?) In the meantime, I checked the Technote... Then, I checked my Activity Log for the last 24 hours... and I found 33 LTO volumes that presented the cartridge memory message! So, now I have the smoking gun, and I suppose I could do move data against those volumes, but I suspect there are many more, and I would like to know what's causing the corruption and how to prevent it! If I don't hear anything from the group, I'll open a call with Tivoli. Thanks very much for the information! -Robin Richard Sims [EMAIL PROTECTED] Sent by: ADSM: To: ADSM-L@VM.MARIST.EDU Dist Storcc: Manager Subject: [EMAIL PROTECTED] Re: Very slow restores (days), hours to locate files T.EDU 07/06/2005 10:30 AM Please respond to ADSM: Dist Stor Manager Please, everyone, when posting questions about restorals, give details about the manner in which the restoral was invoked so that we can get a sense of what kind is involved (NQR, Classic) and what is involved. Now... Robin, have a look at IBM Technote 1209563, which I ran across in doing research yesterday. I recall such long-duration- restores in the past, and as I recall they have involved the factors noted in the Technote. LTO is also known for backhitch delays, so that's another contributor in positioning on tape. Richard Sims
Re: slow restores on recently on AIX machines with recent OS upgrade
There's an IP bug in AIX 5.1 which has this symptom. Latest RML should have the fix. Search the archives, as it has been discussed before. I'd do it myself, but I our http proxy is down again. Steve Steve Harris AIX and TSM Admin Queensland Health, Brisbane Australia [EMAIL PROTECTED] 15/08/2003 5:17:22 Hello, everyone. We run a TSM server v 5.1 level 5.4 on an AIX 4.3 machine. The AIX admins here have been upgrading their other servers to AIX v 5.1 with the 32 bit kerenl. We've found that on the AIX upgraded machines that TSM restores and HSM recalls from tape are performing horribly, with a transfer rate of 200k every 20 - 30 seconds. To confuse the issue more, we've found that with restores work with test files that were backed up and then immediately restored, without being flushed to tape. Backups perform as they always have. Restore performance is great on machines that have not had the OS upgraded. We've tested one server before and after the upgrade and saw the performance drop with the upgrade. The servers are running TSM clients at 5.1.0.6. Has anyone seen these symptons before? -- Michael Lambert [EMAIL PROTECTED] *** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipients(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipients(s), or if you have received this e-mail in error, you are asked to immediately notify the sender by telephone or by return e-mail. You should also delete this e-mail message and destroy any hard copies produced. ***
Re: slow restores on AIX machines with recent OS upgrade
Being aware of this, I should think that your AIX admins would respond by performing network throughput tests to see if their AIX upgrade needs network parameter adjustments, as in Receive Buffers, if not Routing. I would suggest running some benchmark tests in the AIX host where the TSM server is to measure tape drive performance as driven by OS commands (tapeutil; tar of a random-content large file) to help isolate the problem as being drive/tape or network. The impression we have at the moment is that those AIX admins have upgraded systems without performing requisite quality assurance on the result, which is not good. As my previous emails stated, everything but restores are working as expected. The problem must lie in the OS, as the network / tape drives / TSM server are fine. Everyone else here can use TSM as always. It's only on the AIX OS upgraded machines that we're having problems. -- Michael Lambert [EMAIL PROTECTED]
Re: slow restores on recently on AIX machines with recent OS upgr ade
Are you using the Sp Switch? I had a problem the SP Switch after the AIX 5 upgrade. Miles [EMAIL PROTECTED] 14-Aug-03 2:39:02 PM Michael, What I understand that your data transfer rate over network went down to 200k after AIX OS upgrade. What is the level of ML you have upgraded ? What was the previous level? Thanks Balanand Pinni -Original Message- From: Michael Lambert [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 2:17 PM To: [EMAIL PROTECTED] Subject: slow restores on recently on AIX machines with recent OS upgrade Hello, everyone. We run a TSM server v 5.1 level 5.4 on an AIX 4.3 machine. The AIX admins here have been upgrading their other servers to AIX v 5.1 with the 32 bit kerenl. We've found that on the AIX upgraded machines that TSM restores and HSM recalls from tape are performing horribly, with a transfer rate of 200k every 20 - 30 seconds. To confuse the issue more, we've found that with restores work with test files that were backed up and then immediately restored, without being flushed to tape. Backups perform as they always have. Restore performance is great on machines that have not had the OS upgraded. We've tested one server before and after the upgrade and saw the performance drop with the upgrade. The servers are running TSM clients at 5.1.0.6. Has anyone seen these symptons before? -- Michael Lambert [EMAIL PROTECTED]
Re: slow restores on recently on AIX machines with recent OS upgr ade
AIX 5L we run has ML3 .This I migrated from AIX433 of ML10. You can do instfix -i|grep ML .Any one can do this and see the results. See that all the filesets are updated. You need to give instfix -I (Lowercase). You can check this for your self. Balanand Pinni -Original Message- From: Michael Lambert [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 2:51 PM To: [EMAIL PROTECTED] Subject: Re: slow restores on recently on AIX machines with recent OS upgrade Michael, What I understand that your data transfer rate over network went down to 200k after AIX OS upgrade. What is the level of ML you have upgraded ? What was the previous level? Thanks Balanand Pinni To clarify my previous message, the speed of restores and recalls from tape are at 200k every 20 secs or so. Backups run at their normal speed. The AIX 5.1 machines are running at ML 4. According to the AIX admins here, they were previously at either 8, 9 or 10. Are you using the Sp Switch? I had a problem the SP Switch after the AIX 5 upgrade. Miles Although the software is configured, it is not being used. -- Michael Lambert [EMAIL PROTECTED]
Re: slow restores on recently on AIX machines with recent OS upgr ade
Michael, What I understand that your data transfer rate over network went down to 200k after AIX OS upgrade. What is the level of ML you have upgraded ? What was the previous level? Thanks Balanand Pinni -Original Message- From: Michael Lambert [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 2:17 PM To: [EMAIL PROTECTED] Subject: slow restores on recently on AIX machines with recent OS upgrade Hello, everyone. We run a TSM server v 5.1 level 5.4 on an AIX 4.3 machine. The AIX admins here have been upgrading their other servers to AIX v 5.1 with the 32 bit kerenl. We've found that on the AIX upgraded machines that TSM restores and HSM recalls from tape are performing horribly, with a transfer rate of 200k every 20 - 30 seconds. To confuse the issue more, we've found that with restores work with test files that were backed up and then immediately restored, without being flushed to tape. Backups perform as they always have. Restore performance is great on machines that have not had the OS upgraded. We've tested one server before and after the upgrade and saw the performance drop with the upgrade. The servers are running TSM clients at 5.1.0.6. Has anyone seen these symptons before? -- Michael Lambert [EMAIL PROTECTED]
Re: slow restores on recently on AIX machines with recent OS upgrade
Michael, What I understand that your data transfer rate over network went down to 200k after AIX OS upgrade. What is the level of ML you have upgraded ? What was the previous level? Thanks Balanand Pinni To clarify my previous message, the speed of restores and recalls from tape are at 200k every 20 secs or so. Backups run at their normal speed. The AIX 5.1 machines are running at ML 4. According to the AIX admins here, they were previously at either 8, 9 or 10. Are you using the Sp Switch? I had a problem the SP Switch after the AIX 5 upgrade. Miles Although the software is configured, it is not being used. -- Michael Lambert [EMAIL PROTECTED]
slow restores on recently on AIX machines with recent OS upgrade
Hello, everyone. We run a TSM server v 5.1 level 5.4 on an AIX 4.3 machine. The AIX admins here have been upgrading their other servers to AIX v 5.1 with the 32 bit kerenl. We've found that on the AIX upgraded machines that TSM restores and HSM recalls from tape are performing horribly, with a transfer rate of 200k every 20 - 30 seconds. To confuse the issue more, we've found that with restores work with test files that were backed up and then immediately restored, without being flushed to tape. Backups perform as they always have. Restore performance is great on machines that have not had the OS upgraded. We've tested one server before and after the upgrade and saw the performance drop with the upgrade. The servers are running TSM clients at 5.1.0.6. Has anyone seen these symptons before? -- Michael Lambert [EMAIL PROTECTED]
Slow restores
Hi, After issuing node restore command my library spends a lot of time seeking for something on tape. The actual restore takes comparatively little time. Can anybody explain me what is happening? And is it possible to shorten the seeking period? Thank you for your help in advance - Wieslaw
Re: Slow restores
What environement? tsm server ? client? From: Wieslaw Markowiak/Kra/ComputerLand/PL [EMAIL PROTECTED] on 04/23/2002 08:44 AM Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Slow restores Hi, After issuing node restore command my library spends a lot of time seeking for something on tape. The actual restore takes comparatively little time. Can anybody explain me what is happening? And is it possible to shorten the seeking period? Thank you for your help in advance - Wieslaw
Re: Slow restores
Hi Wieslaw! It would help if you provide use some more info, like what kind of tape are you using? Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Wieslaw Markowiak/Kra/ComputerLand/PL [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 14:44 To: [EMAIL PROTECTED] Subject: Slow restores Hi, After issuing node restore command my library spends a lot of time seeking for something on tape. The actual restore takes comparatively little time. Can anybody explain me what is happening? And is it possible to shorten the seeking period? Thank you for your help in advance - Wieslaw ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Re: Slow restores
Wieslaw, A typical reason for long search times is a high reclaimation value and no colocation. If you have a lot of servers, this can really fragment the data across the volumes Regards, Richard -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of Wieslaw Markowiak/Kra/ComputerLand/PL Sent: 23 April 2002 13:44 To: [EMAIL PROTECTED] Subject: Slow restores Hi, After issuing node restore command my library spends a lot of time seeking for something on tape. The actual restore takes comparatively little time. Can anybody explain me what is happening? And is it possible to shorten the seeking period? Thank you for your help in advance - Wieslaw
Re: Slow restores
Another huge contributor to this phenomenon is failure to use DIRMC on disk (and FILE on disk for sequential migration/reclamation) storage pools. A lot of servers and a lot of objects (more common with Windows these days) need all the help they can get; keeping directories on disk (using DIRMC trick) makes a huge difference in the number of tape seeks required... see other posts about restore times. I had a customer with non-collocated DLT backups for 30 servers, spread over 45 tapes; it only took about 30 hours to restore 316 GB, 1.6 million objects -- that's over 10 GB/Hr, faster than most benchmarks! Don France Technical Architect - Tivoli Certified Consultant Professional Association of Contract Employees (P.A.C.E.) San Jose, CA (408) 257-3037 [EMAIL PROTECTED] - Original Message - From: Richard Cox [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 23, 2002 6:40 AM Subject: Re: Slow restores Wieslaw, A typical reason for long search times is a high reclaimation value and no colocation. If you have a lot of servers, this can really fragment the data across the volumes Regards, Richard -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of Wieslaw Markowiak/Kra/ComputerLand/PL Sent: 23 April 2002 13:44 To: [EMAIL PROTECTED] Subject: Slow restores Hi, After issuing node restore command my library spends a lot of time seeking for something on tape. The actual restore takes comparatively little time. Can anybody explain me what is happening? And is it possible to shorten the seeking period? Thank you for your help in advance - Wieslaw
Really slow restores
We are running adsm 3.7.0 on os/390. The client level is for nt servers 4.1.1. Our OS/390 has about 100 nodes backing up between 8PM and 5am. Sometimes a backup session will run long and keep going to 10am but that is not always the case. Over the last week our restores are running very slow somtimes hours to drill down the directory structure and select one file. I am looking for any tips that may improve our performance. Thanks Jason Webb Systems Engineer Premera Blue Cross
Re: Slow restores on Unix
Hi Paul Tivoli Storage Manager offers alot of tools to opimize restore and backup. If you have a high speed network you could try optimizeing the TCPnodelay parameter to YES from NO If you have enugh cpu power and enugh memorry you could try opimizing these parameters Increase the TCPWINDOWZIE parameter If you think this is a communication problem you shold consider the TCPBUFFSIZE parameter, you should be avare tha this parameter requers more memmory. If you are restoring from a multible volumes you could increase the Resourceutilization parameter. this can be wery CPU exensive. But still Paul there is no way of knowing why you have slow restores, from the information you give us. I recommend you try this and if this dosent work you should try focusing on the way you backup youre data then. you could try to backup your directorys to a disk storagepools, enable disk cache, or enable collocation for this client. Hope this helps. Tomas Eugene What can´t happen, happens again Kvedja/Regards Petur Eythorsson Taeknimadur/Technician Kerfisfraedingur IR Tivoli Storage Manager Certified Professional Microsoft Certified System Engineer Nyherji HfSimi TEL: +354-569-7700 Borgartun 37 105 Iceland URL:http://www.nyherji.is - Original Message - From: Paul Bestow [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 17, 2001 1:19 PM Subject: Slow restores on Unix Hello Everybody, We have a customer which can backup up a file of 300mb and get around 12mb/sec but then when they do a restore they only see around 2mb/sec. They also have a number of NT machines when they backup they get around 8-9mb/sec but the restores are the same. The TSM server is an NT4 box running 4.1.3 The client machine is an IBM RS/6000 M80 (AIX 4.3.3) with a TSM client 4.1.3 Any help with the above would be greatly appreciated Cheers Paul http://www.phoenixitgroup.com **Internet Email Confidentiality Footer*** Phoenix IT Group Limited is registered in England and Wales under company number 3476115. Registered Office: Technology House, Hunsbury Hill Avenue, Northampton, NN4 8QS Opinions, conclusions and other information in this message that do not relate to the official business of our firm shall be understood as neither given nor endorsed by it. No contracts may be concluded on behalf of our firm by means of email communications. Confidentiality: Confidential information may be contained in this message. If you are not the recipient indicated (or responsible for delivery of the message to such person), you may not take any action based on it, nor should you copy or show this to anyone; please reply to this email and highlight the error to the sender, then delete the message from your system. Monitoring of Messages: Please note that we reserve the right to monitor and intercept emails sent and received on our network. Warning: Internet email is not 100% secure. We ask you to understand and observe this lack of security when emailing us. We do not accept responsibility for changes made to this message after it was sent Viruses: Although we have taken steps to ensure that this email and any attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
Slow restores on Unix
Hello Everybody, We have a customer which can backup up a file of 300mb and get around 12mb/sec but then when they do a restore they only see around 2mb/sec. They also have a number of NT machines when they backup they get around 8-9mb/sec but the restores are the same. The TSM server is an NT4 box running 4.1.3 The client machine is an IBM RS/6000 M80 (AIX 4.3.3) with a TSM client 4.1.3 Any help with the above would be greatly appreciated Cheers Paul http://www.phoenixitgroup.com **Internet Email Confidentiality Footer*** Phoenix IT Group Limited is registered in England and Wales under company number 3476115. Registered Office: Technology House, Hunsbury Hill Avenue, Northampton, NN4 8QS Opinions, conclusions and other information in this message that do not relate to the official business of our firm shall be understood as neither given nor endorsed by it. No contracts may be concluded on behalf of our firm by means of email communications. Confidentiality: Confidential information may be contained in this message. If you are not the recipient indicated (or responsible for delivery of the message to such person), you may not take any action based on it, nor should you copy or show this to anyone; please reply to this email and highlight the error to the sender, then delete the message from your system. Monitoring of Messages: Please note that we reserve the right to monitor and intercept emails sent and received on our network. Warning: Internet email is not 100% secure. We ask you to understand and observe this lack of security when emailing us. We do not accept responsibility for changes made to this message after it was sent Viruses: Although we have taken steps to ensure that this email and any attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
Slow restores on Unix
Hello Everybody, We have a customer which can backup up a file of 300mb and get around 12mb/sec but then when they do a restore they only see around 2mb/sec. They also have a number of NT machines when they backup they get around 8-9mb/sec but the restores are the same. The TSM server is an NT4 box running 4.1.3 The client machine is an IBM RS/6000 M80 (AIX 4.3.3) with a TSM client 4.1.3 Any help with the above would be greatly appreciated Cheers Paul http://www.phoenixitgroup.com **Internet Email Confidentiality Footer*** Phoenix IT Group Limited is registered in England and Wales under company number 3476115. Registered Office: Technology House, Hunsbury Hill Avenue, Northampton, NN4 8QS Opinions, conclusions and other information in this message that do not relate to the official business of our firm shall be understood as neither given nor endorsed by it. No contracts may be concluded on behalf of our firm by means of email communications. Confidentiality: Confidential information may be contained in this message. If you are not the recipient indicated (or responsible for delivery of the message to such person), you may not take any action based on it, nor should you copy or show this to anyone; please reply to this email and highlight the error to the sender, then delete the message from your system. Monitoring of Messages: Please note that we reserve the right to monitor and intercept emails sent and received on our network. Warning: Internet email is not 100% secure. We ask you to understand and observe this lack of security when emailing us. We do not accept responsibility for changes made to this message after it was sent Viruses: Although we have taken steps to ensure that this email and any attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
Re: Slow Restores on Netware
On Mon, 27 Aug 2001 21:49:52 -0500, you wrote: Is it me or is a restore of Netware data slow? I get at best 5.6g per hour off of a 21g per hour drive. TSM backs it up fast but takes way to long to restore. Does anyone else have this problem and if so what do you do? Rather than just shrugging and saying Netware, I'd like to offer more useful dialog. Not knowing what your network is like, I'd say that a 5GB+/hour restore on Netware is pretty damn good, considering that Netware, like Windows, is comprised of a zillion small files and a rather convoluted directory structure. It takes a while for those Intel-dependent OSs a while to rebuild file structures. -- Mark Stapleton ([EMAIL PROTECTED])
Re: Slow Restores on Netware
On Tue, 28 Aug 2001 09:40:11 -0700, Bill Boyer wrote: Are you compressing the Netware volume? If the Netware is compressed at the volume level, there is no compression going on during the file transfers to or from TSM. The very nature of the volume strucutre itself is compressed, and puts no compression stress on either the client or TSM server. -- Mark Stapleton ([EMAIL PROTECTED])
Re: Slow Restores on Netware
As much as I do agree with the shrug issue at times, I fail to see where the fact that restores take ages is actually connected to the Netware side. We have exactly the same issue, and with all the experts we'v had here testing it out, not one has been able to point to the Netware side being the problem, and every one has managed to find problems with the TSM side. Be it very slow tape access, bad indexing, etc. I would be wrong to point the finger specifically at the TSM, and would go as far as to say that TSM and Netware do not quite mesh as Netware and other backups software do, but that's something I'v been over before on this list. The slow restores I have on some of my NT servers...do I shrug and say NT ? And the Unix's ? Mike -Original Message- From: Cory Heikel [SMTP:[EMAIL PROTECTED]] Sent: â àåâåñè 28 2001 14:18 To: [EMAIL PROTECTED] Subject: Re: Slow Restores on Netware I mostly sigh, shrug my shoulders and say... Netware -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Scott G Davis Sent: Monday, August 27, 2001 10:50 PM To: [EMAIL PROTECTED] Subject: Slow Restores on Netware Is it me or is a restore of Netware data slow? I get at best 5.6g per hour off of a 21g per hour drive. TSM backs it up fast but takes way to long to restore. Does anyone else have this problem and if so what do you do?
Re: Slow Restores on Netware
More $.02 ... Are you compressing the Netware volume? Do you have any virus scanner running while the restore is running? Bill Boyer I haven't lost my mind. It's backed up on tape somewhere. - ?? -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Maurice van 't Loo Sent: Tuesday, August 28, 2001 5:32 AM To: [EMAIL PROTECTED] Subject: Re: Slow Restores on Netware Netware uses A LOT of small files, the Netware filesystem is not fast enough to build the filestructure etc. That's most of the times the performance problems with Netware en NT Fileservers. Greetings, Maurice - Original Message - From: Scott G Davis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 28, 2001 4:49 AM Subject: Slow Restores on Netware Is it me or is a restore of Netware data slow? I get at best 5.6g per hour off of a 21g per hour drive. TSM backs it up fast but takes way to long to restore. Does anyone else have this problem and if so what do you do?
Re: Slow Restores on Netware
To add another thought. Last time I had to restore a NetWare server we ran into a problem of MTU size. Once we fixed that the restore went very quickly. Bruce Kamp -Original Message- From: Richard Sims [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 28, 2001 9:54 AM To: [EMAIL PROTECTED] Subject: Re: Slow Restores on Netware Is it me or is a restore of Netware data slow? I get at best 5.6g per hour off of a 21g per hour drive. TSM backs it up fast but takes way to long to restore. Does anyone else have this problem and if so what do you do? It's you. :-) Seriously, though, we'd need a lot more information to gauge why the restorals are slow, as has been explored innumerable times on the mailing list... Tape drive type, collocation type and locality of data relative to restoral needs, restoral type, networking, disk speed, file system condition, client/server load, etc. (I summarize factors in the Restoral performance entry in ADSM.QuickFacts.) Identifying bottlenecks is one of the tasks for which we all get paid so much. :-$ Richard Sims, BU
Re: Slow Restores on Netware
Is it me or is a restore of Netware data slow? I get at best 5.6g per hour off of a 21g per hour drive. TSM backs it up fast but takes way to long to restore. Does anyone else have this problem and if so what do you do? It's you. :-) Seriously, though, we'd need a lot more information to gauge why the restorals are slow, as has been explored innumerable times on the mailing list... Tape drive type, collocation type and locality of data relative to restoral needs, restoral type, networking, disk speed, file system condition, client/server load, etc. (I summarize factors in the Restoral performance entry in ADSM.QuickFacts.) Identifying bottlenecks is one of the tasks for which we all get paid so much. :-$ Richard Sims, BU
Re: Slow Restores on Netware
We regularly get 8-10gb/hour on Netware restores. These servers typically have 100+gb of disk 1 million+ files on them. Similar performance on NT. A bit more detail on your client server configurations would be helpful. Regards, Greg Scott G Davis Scott.G.Davis@ATo: [EMAIL PROTECTED] LLTEL.COM cc: Sent by: ADSM: Fax to: Dist Stor Subject: Slow Restores on Netware Manager [EMAIL PROTECTED] T.EDU 08/27/2001 21:49 Please respond to ADSM: Dist Stor Manager Is it me or is a restore of Netware data slow? I get at best 5.6g per hour off of a 21g per hour drive. TSM backs it up fast but takes way to long to restore. Does anyone else have this problem and if so what do you do?
Slow Restores on Netware
Is it me or is a restore of Netware data slow? I get at best 5.6g per hour off of a 21g per hour drive. TSM backs it up fast but takes way to long to restore. Does anyone else have this problem and if so what do you do?
