Re: Dramatic reduction in backup time
I'm running amanda on Red Hat Enterprise 3. I'm a bit new to Linux, but will try and investigate dmesg as you suggested. Otherwise, thanks very much for all your input and help. I'll see how it goes from here on. At least now I know what the probable cause is. Thanks. Michael Loftis wrote: --On August 3, 2006 9:05:03 AM -0700 Joe Donner (sent by Nabble.com) [EMAIL PROTECTED] wrote: Yes, it's the exact same tape drive I've been using extensively for testing, and all that time it had been sitting in the same position on the floor. I moved it on Monday, and then amanda took off like a lightning bolt. Wow, that's something I'll be classing as very weird, but very good. I was impressed by the 9 hours it took to do backups, but now I'm speechless... I've introduced a new tape for tonight's backup run. Will see what it tells me tomorrow. Thanks very much for your help! Yeah it sounds VERY much like a marginal SCSI cablewhat OS do you have? Sometimes termination issues will show up in dmesg, also dmesg will usually show the speed at which the device negotiatesit is shown elsewhere too depending on your OS. -- View this message in context: http://www.nabble.com/Dramatic-reduction-in-backup-time-tf2044425.html#a5646615 Sent from the Amanda - Users forum at Nabble.com.
Re: Dramatic reduction in backup time
I honestly haven't changed anything. The only thing that happened was that I had to run amflush on July 31, because for some reason the amanda-related services on the backup server seemed to have hung (but that's an entirely different issue). That si just a wilkd guess, but how about the amflush has freed space on your holding disk that had been wasted for ages? Olivier
Re: Dramatic reduction in backup time
That was definitely not the case. The holding disk has been empty all this time, except on 31 July. And after I ran amflush it was empty again. What I don't understand is the increase in dump time and tape time? They both more than doubled in speed! How is that possible? Olivier Nicole wrote: I honestly haven't changed anything. The only thing that happened was that I had to run amflush on July 31, because for some reason the amanda-related services on the backup server seemed to have hung (but that's an entirely different issue). That si just a wilkd guess, but how about the amflush has freed space on your holding disk that had been wasted for ages? Olivier -- View this message in context: http://www.nabble.com/Dramatic-reduction-in-backup-time-tf2044425.html#a5629636 Sent from the Amanda - Users forum at Nabble.com.
Re: Dramatic reduction in backup time
On Thu, Aug 03, 2006 at 02:46:06AM -0700, Joe Donner (sent by Nabble.com) wrote: That was definitely not the case. The holding disk has been empty all this time, except on 31 July. And after I ran amflush it was empty again. What I don't understand is the increase in dump time and tape time? They both more than doubled in speed! How is that possible? Olivier Nicole wrote: I honestly haven't changed anything. The only thing that happened was that I had to run amflush on July 31, because for some reason the amanda-related services on the backup server seemed to have hung (but that's an entirely different issue). That si just a wilkd guess, but how about the amflush has freed space on your holding disk that had been wasted for ages? Holding disk issues were going to be my guess also. When the run time (wall clock) and tape time (taper is active) match as the first two: Run Time (hrs:min) 9:43 Dump Time (hrs:min)6:21 Tape Time (hrs:min)9:23 Run Time (hrs:min) 9:43 Dump Time (hrs:min)6:17 Tape Time (hrs:min)9:23 it generally means your dumps are going straight to tape. Contrast that with the last two where time for taping the same amount of data is greatly lower than total run time. Run Time (hrs:min) 4:03 Dump Time (hrs:min)3:12 Tape Time (hrs:min)1:17 Run Time (hrs:min) 4:27 Dump Time (hrs:min)3:37 Tape Time (hrs:min)1:16 However, if the dumps were going straight to tape then I would expect the dump time (cumulative time for dumping of each DLE - thus can be run time if DLEs dump in parallel) to match tape time. So it would appear the dumps were going to the holding disk but were severely constrained by slow tapeing. I wonder about the halving of dump time also. There may still have been a problem with the disk system. Did anyone change any scsi cables or terminators. Or maybe the just jiggled things back there doing other work? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Dramatic reduction in backup time
Well, I may have lied a bit when saying that nothing had changed... What did change was that I moved the server from temporarily sitting on the floor to where it will now stay full-time. So it was a shutdown, unplug the external tape drive and other devices, and then plug them all back in. Also, one of the little screws which connects the SCSI cable to the back of the server has long ago broken off and gone missing. So it's only attached by one screw. Well, do you agree with me that it is still backing up the same amount of data and all the DLEs? It certainly looks that way from the mail reports. I'm a bit worried because it's looking too good to be true. I also don't see how it can dump 130-odd gigabytes of data within a bit more than 3 hours?? Thanks for your help on this. Jon LaBadie wrote: On Thu, Aug 03, 2006 at 02:46:06AM -0700, Joe Donner (sent by Nabble.com) wrote: That was definitely not the case. The holding disk has been empty all this time, except on 31 July. And after I ran amflush it was empty again. What I don't understand is the increase in dump time and tape time? They both more than doubled in speed! How is that possible? Olivier Nicole wrote: I honestly haven't changed anything. The only thing that happened was that I had to run amflush on July 31, because for some reason the amanda-related services on the backup server seemed to have hung (but that's an entirely different issue). That si just a wilkd guess, but how about the amflush has freed space on your holding disk that had been wasted for ages? Holding disk issues were going to be my guess also. When the run time (wall clock) and tape time (taper is active) match as the first two: Run Time (hrs:min) 9:43 Dump Time (hrs:min)6:21 Tape Time (hrs:min)9:23 Run Time (hrs:min) 9:43 Dump Time (hrs:min)6:17 Tape Time (hrs:min)9:23 it generally means your dumps are going straight to tape. Contrast that with the last two where time for taping the same amount of data is greatly lower than total run time. Run Time (hrs:min) 4:03 Dump Time (hrs:min)3:12 Tape Time (hrs:min)1:17 Run Time (hrs:min) 4:27 Dump Time (hrs:min)3:37 Tape Time (hrs:min)1:16 However, if the dumps were going straight to tape then I would expect the dump time (cumulative time for dumping of each DLE - thus can be run time if DLEs dump in parallel) to match tape time. So it would appear the dumps were going to the holding disk but were severely constrained by slow tapeing. I wonder about the halving of dump time also. There may still have been a problem with the disk system. Did anyone change any scsi cables or terminators. Or maybe the just jiggled things back there doing other work? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax) -- View this message in context: http://www.nabble.com/Dramatic-reduction-in-backup-time-tf2044425.html#a5634710 Sent from the Amanda - Users forum at Nabble.com.
Re: Dramatic reduction in backup time
On Thu, Aug 03, 2006 at 08:25:43AM -0700, Joe Donner (sent by Nabble.com) wrote: Well, I may have lied a bit when saying that nothing had changed... What did change was that I moved the server from temporarily sitting on the floor to where it will now stay full-time. So it was a shutdown, unplug the external tape drive and other devices, and then plug them all back in. Also, one of the little screws which connects the SCSI cable to the back of the server has long ago broken off and gone missing. So it's only attached by one screw. Well, do you agree with me that it is still backing up the same amount of data and all the DLEs? It certainly looks that way from the mail reports. I'm a bit worried because it's looking too good to be true. I also don't see how it can dump 130-odd gigabytes of data within a bit more than 3 hours?? Thanks for your help on this. Jon LaBadie wrote: On Thu, Aug 03, 2006 at 02:46:06AM -0700, Joe Donner (sent by Nabble.com) wrote: That was definitely not the case. The holding disk has been empty all this time, except on 31 July. And after I ran amflush it was empty again. What I don't understand is the increase in dump time and tape time? They both more than doubled in speed! How is that possible? Olivier Nicole wrote: I honestly haven't changed anything. The only thing that happened was that I had to run amflush on July 31, because for some reason the amanda-related services on the backup server seemed to have hung (but that's an entirely different issue). That si just a wilkd guess, but how about the amflush has freed space on your holding disk that had been wasted for ages? Holding disk issues were going to be my guess also. When the run time (wall clock) and tape time (taper is active) match as the first two: Run Time (hrs:min) 9:43 Dump Time (hrs:min)6:21 Tape Time (hrs:min)9:23 Run Time (hrs:min) 9:43 Dump Time (hrs:min)6:17 Tape Time (hrs:min)9:23 it generally means your dumps are going straight to tape. Contrast that with the last two where time for taping the same amount of data is greatly lower than total run time. Run Time (hrs:min) 4:03 Dump Time (hrs:min)3:12 Tape Time (hrs:min)1:17 Run Time (hrs:min) 4:27 Dump Time (hrs:min)3:37 Tape Time (hrs:min)1:16 However, if the dumps were going straight to tape then I would expect the dump time (cumulative time for dumping of each DLE - thus can be run time if DLEs dump in parallel) to match tape time. So it would appear the dumps were going to the holding disk but were severely constrained by slow tapeing. I wonder about the halving of dump time also. There may still have been a problem with the disk system. Did anyone change any scsi cables or terminators. Or maybe the just jiggled things back there doing other work? Are you using that SDLT drive for which you reported a tapetype back in early June? If so, you have had a problem since then. In June your tapetype showed 2200 k/s. Similarly, your recent slow dumps had a tapeing speed of about 2500 and 1800 k/s. Your more recent fast dumps were taped at about 13000 k/s. The sdlt is rated at 16000 k/s. I'd say you had tape system problems fixed by physical movement or reboot. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Dramatic reduction in backup time
bis 15.8. bin ich nicht erreichbar. in dringenden fällen senden sie ihre nachricht bitte an mailto:[EMAIL PROTECTED], vielen dank.
Re: Dramatic reduction in backup time
Yes, it's the exact same tape drive I've been using extensively for testing, and all that time it had been sitting in the same position on the floor. I moved it on Monday, and then amanda took off like a lightning bolt. Wow, that's something I'll be classing as very weird, but very good. I was impressed by the 9 hours it took to do backups, but now I'm speechless... I've introduced a new tape for tonight's backup run. Will see what it tells me tomorrow. Thanks very much for your help! Jon LaBadie wrote: On Thu, Aug 03, 2006 at 08:25:43AM -0700, Joe Donner (sent by Nabble.com) wrote: Well, I may have lied a bit when saying that nothing had changed... What did change was that I moved the server from temporarily sitting on the floor to where it will now stay full-time. So it was a shutdown, unplug the external tape drive and other devices, and then plug them all back in. Also, one of the little screws which connects the SCSI cable to the back of the server has long ago broken off and gone missing. So it's only attached by one screw. Well, do you agree with me that it is still backing up the same amount of data and all the DLEs? It certainly looks that way from the mail reports. I'm a bit worried because it's looking too good to be true. I also don't see how it can dump 130-odd gigabytes of data within a bit more than 3 hours?? Thanks for your help on this. Jon LaBadie wrote: On Thu, Aug 03, 2006 at 02:46:06AM -0700, Joe Donner (sent by Nabble.com) wrote: That was definitely not the case. The holding disk has been empty all this time, except on 31 July. And after I ran amflush it was empty again. What I don't understand is the increase in dump time and tape time? They both more than doubled in speed! How is that possible? Olivier Nicole wrote: I honestly haven't changed anything. The only thing that happened was that I had to run amflush on July 31, because for some reason the amanda-related services on the backup server seemed to have hung (but that's an entirely different issue). That si just a wilkd guess, but how about the amflush has freed space on your holding disk that had been wasted for ages? Holding disk issues were going to be my guess also. When the run time (wall clock) and tape time (taper is active) match as the first two: Run Time (hrs:min) 9:43 Dump Time (hrs:min)6:21 Tape Time (hrs:min)9:23 Run Time (hrs:min) 9:43 Dump Time (hrs:min)6:17 Tape Time (hrs:min)9:23 it generally means your dumps are going straight to tape. Contrast that with the last two where time for taping the same amount of data is greatly lower than total run time. Run Time (hrs:min) 4:03 Dump Time (hrs:min)3:12 Tape Time (hrs:min)1:17 Run Time (hrs:min) 4:27 Dump Time (hrs:min)3:37 Tape Time (hrs:min)1:16 However, if the dumps were going straight to tape then I would expect the dump time (cumulative time for dumping of each DLE - thus can be run time if DLEs dump in parallel) to match tape time. So it would appear the dumps were going to the holding disk but were severely constrained by slow tapeing. I wonder about the halving of dump time also. There may still have been a problem with the disk system. Did anyone change any scsi cables or terminators. Or maybe the just jiggled things back there doing other work? Are you using that SDLT drive for which you reported a tapetype back in early June? If so, you have had a problem since then. In June your tapetype showed 2200 k/s. Similarly, your recent slow dumps had a tapeing speed of about 2500 and 1800 k/s. Your more recent fast dumps were taped at about 13000 k/s. The sdlt is rated at 16000 k/s. I'd say you had tape system problems fixed by physical movement or reboot. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax) -- View this message in context: http://www.nabble.com/Dramatic-reduction-in-backup-time-tf2044425.html#a5635442 Sent from the Amanda - Users forum at Nabble.com.
Re: Dramatic reduction in backup time
--On August 3, 2006 9:05:03 AM -0700 Joe Donner (sent by Nabble.com) [EMAIL PROTECTED] wrote: Yes, it's the exact same tape drive I've been using extensively for testing, and all that time it had been sitting in the same position on the floor. I moved it on Monday, and then amanda took off like a lightning bolt. Wow, that's something I'll be classing as very weird, but very good. I was impressed by the 9 hours it took to do backups, but now I'm speechless... I've introduced a new tape for tonight's backup run. Will see what it tells me tomorrow. Thanks very much for your help! Yeah it sounds VERY much like a marginal SCSI cablewhat OS do you have? Sometimes termination issues will show up in dmesg, also dmesg will usually show the speed at which the device negotiatesit is shown elsewhere too depending on your OS.
Re: Dramatic reduction in backup time
Yes, it's the exact same tape drive I've been using extensively for testing, and all that time it had been sitting in the same position on the floor. I moved it on Monday, and then amanda took off like a lightning bolt. Wow, that's something I'll be classing as very weird, but very good. I was impressed by the 9 hours it took to do backups, but now I'm speechless... I've introduced a new tape for tonight's backup run. Will see what it tells me tomorrow. Thanks very much for your help! Yeah it sounds VERY much like a marginal SCSI cablewhat OS do you have? Sometimes termination issues will show up in dmesg, also dmesg will usually show the speed at which the device negotiatesit is shown elsewhere too depending on your OS. The time sounds right do start doing a test of your tape drive, using all the SCSI adapter bios tools to see what it reports, and then trying to stuff the tape with data and see how fast it can take it. Olivier
