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
> > 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
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! 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
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
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
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 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
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
> 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
Dramatic reduction in backup time
Dear all, Something really strange has happened to my amanda setup. I'm inclined to feel impressed, but don't know whether this in fact points to something being wrong. If you compare run times, dump times, tape times, average dump rate and average tape write rate for the four different dates below, you'll see that suddenly amanda has shown a dramatic increase in performance (so to speak) even though the amount of data in question hasn't changed that much at all. 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). Extracts from the amanda mail report after each amdump (I'm doing full backups with each run at the moment): July 26 Estimate Time (hrs:min)0:04 Run Time (hrs:min) 9:43 Dump Time (hrs:min)6:21 6:21 0:00 Output Size (meg) 56974.256974.20.0 Original Size (meg)136759.4 136759.40.0 Avg Compressed Size (%)41.7 41.7-- Filesystems Dumped 106106 0 Avg Dump Rate (k/s) 2549.2 2549.2-- Tape Time (hrs:min)9:23 9:23 0:00 Tape Size (meg) 56974.356974.30.0 Tape Used (%) 36.5 36.50.0 Filesystems Taped 106106 0 Avg Tp Write Rate (k/s) 1727.5 1727.5-- July 27 Estimate Time (hrs:min)0:04 Run Time (hrs:min) 9:43 Dump Time (hrs:min)6:17 6:17 0:00 Output Size (meg) 57089.057089.00.0 Original Size (meg)137013.6 137013.60.0 Avg Compressed Size (%)41.7 41.7-- Filesystems Dumped 106106 0 Avg Dump Rate (k/s) 2587.5 2587.5-- Tape Time (hrs:min)9:23 9:23 0:00 Tape Size (meg) 57089.157089.10.0 Tape Used (%) 36.6 36.60.0 Filesystems Taped 106106 0 Avg Tp Write Rate (k/s) 1730.2 1730.2-- July 31 Estimate Time (hrs:min)0:04 Run Time (hrs:min) 4:03 Dump Time (hrs:min)3:12 3:12 0:00 Output Size (meg) 57265.857265.80.0 Original Size (meg)137495.9 137495.90.0 Avg Compressed Size (%)41.6 41.6-- Filesystems Dumped 109109 0 Avg Dump Rate (k/s) 5079.1 5079.1-- Tape Time (hrs:min)1:17 1:17 0:00 Tape Size (meg) 57265.957265.90.0 Tape Used (%) 36.7 36.70.0 Filesystems Taped 109109 0 Avg Tp Write Rate (k/s) 12695.612695.6-- August 1 Estimate Time (hrs:min)0:04 Run Time (hrs:min) 4:27 Dump Time (hrs:min)3:37 3:37 0:00 Output Size (meg) 57887.157887.10.0 Original Size (meg)139210.7 139210.70.0 Avg Compressed Size (%)41.6 41.6-- Filesystems Dumped 106106 0 Avg Dump Rate (k/s) 4562.9 4562.9-- Tape Time (hrs:min)1:16 1:16 0:00 Tape Size (meg) 57887.257887.20.0 Tape Used (%) 37.1 37.10.0 Filesystems Taped 106106 0 Avg Tp Write Rate (k/s) 12951.412951.4-- -- View this message in context: http://www.nabble.com/Dramatic-reduction-in-backup-time-tf2044425.html#a5628905 Sent from the Amanda - Users forum at Nabble.com.
Re: advice to optimise backup time
Frederic Medery wrote: thanks for the replies !! There's no bandwidth limit. Maybe not by the physical network, but maybe you have weird parameters in amanda.conf. where can I find the dumpers and number of jobs info ? A nice overview of all this in generated by "amplot": $ cd ~amanda/config $ amplot -e amdump.1 $ amplot -e amdump.* -- Paul
Re: advice to optimise backup time
thanks for the replies !! There's no bandwidth limit. where can I find the dumpers and number of jobs info ? For the SW compression in vary depending of the server/parition. reg, Frederic Medery System Administrator LexUM, University of Montreal Brian Cuttler wrote: Frederic, What are the tuning parameters ? Are you bumping into an amanda imposed bandwidth limit ? What are the settings for max dumpers and number of jobs you can run at one time for each client ? What level of SW compression are you using ? On Fri, Jul 09, 2004 at 10:22:46AM -0400, Joshua Baker-LePain wrote: On Fri, 9 Jul 2004 at 9:27am, Frederic Medery wrote We have more and more prob with the backup : it takes more then 14 h. It's not amanda fault just the amount of data. :-) How much per night? For now we have a backup server with a amanda partition with 18 GB connected to a IBM LTO Ultrium 3581 tape Charger (7 tapes). The Hardware compression is off (sofware compression is used). Now we have GB network and faster server with losts of RAM and HD spaces and I want to install Amanda on our prod server which have the largest amount of data. so is-ti better (faster backup) to have : hardware or software compression ? A larger amanda partition ? More holding space is going to give you the biggest boost. Software vs. hardware compression with regards to speed depends on your hardware -- if the CPUs can compress the data as fast as the disk/network can take it, then it isn't going to slow you down. Also note that, with your LTO drive, you can turn on hardware compression *and* use software compression on selected DLEs if you so choose. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: advice to optimise backup time
Frederic Medery wrote: is there another amanda tweaks to speed up the backup process ? Careful study of amplot graphs helps you point out bottlenecks quickly. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: advice to optimise backup time
> More holding space is going to give you the biggest boost. And be sure to have fast holding disks. LTO drives eat data at 20-30MB/s if your disk can send it that fast; in my setup (currently 400GB/night, and struggling to finish in 24h!), I've only two IDE holding disks, and the combined accesses of a few dumpers and the taper makes my writing speed drop to around 4MB/s. Alex -- Alexander Jolk / BUF Compagnie tel +33-1 42 68 18 28 / fax +33-1 42 68 18 29
Re: advice to optimise backup time
Frederic, What are the tuning parameters ? Are you bumping into an amanda imposed bandwidth limit ? What are the settings for max dumpers and number of jobs you can run at one time for each client ? What level of SW compression are you using ? On Fri, Jul 09, 2004 at 10:22:46AM -0400, Joshua Baker-LePain wrote: > On Fri, 9 Jul 2004 at 9:27am, Frederic Medery wrote > > > We have more and more prob with the backup : it takes more then 14 h. > > > > It's not amanda fault just the amount of data. :-) > > How much per night? > > > For now we have a backup server with a amanda partition with 18 GB > > connected to a IBM LTO Ultrium 3581 tape Charger (7 tapes). The Hardware > > compression is off (sofware compression is used). > > > > Now we have GB network and faster server with losts of RAM and HD spaces > > and I want to install Amanda on our prod server which have the largest > > amount of data. > > > > so is-ti better (faster backup) to have : > > hardware or software compression ? > > A larger amanda partition ? > > > More holding space is going to give you the biggest boost. Software vs. > hardware compression with regards to speed depends on your hardware -- if > the CPUs can compress the data as fast as the disk/network can take it, > then it isn't going to slow you down. > > Also note that, with your LTO drive, you can turn on hardware compression > *and* use software compression on selected DLEs if you so choose. > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: advice to optimise backup time
On Fri, 9 Jul 2004 at 9:27am, Frederic Medery wrote > We have more and more prob with the backup : it takes more then 14 h. > > It's not amanda fault just the amount of data. :-) How much per night? > For now we have a backup server with a amanda partition with 18 GB > connected to a IBM LTO Ultrium 3581 tape Charger (7 tapes). The Hardware > compression is off (sofware compression is used). > > Now we have GB network and faster server with losts of RAM and HD spaces > and I want to install Amanda on our prod server which have the largest > amount of data. > > so is-ti better (faster backup) to have : > hardware or software compression ? > A larger amanda partition ? > More holding space is going to give you the biggest boost. Software vs. hardware compression with regards to speed depends on your hardware -- if the CPUs can compress the data as fast as the disk/network can take it, then it isn't going to slow you down. Also note that, with your LTO drive, you can turn on hardware compression *and* use software compression on selected DLEs if you so choose. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
advice to optimise backup time
Hello, We have more and more prob with the backup : it takes more then 14 h. It's not amanda fault just the amount of data. :-) For now we have a backup server with a amanda partition with 18 GB connected to a IBM LTO Ultrium 3581 tape Charger (7 tapes). The Hardware compression is off (sofware compression is used). Now we have GB network and faster server with losts of RAM and HD spaces and I want to install Amanda on our prod server which have the largest amount of data. so is-ti better (faster backup) to have : hardware or software compression ? A larger amanda partition ? is there another amanda tweaks to speed up the backup process ? Thanks a lot -- Frederic Medery System Administrator LexUM, University of Montreal
Re: Backup time
>The Bandwith I put in the amanda config is 5000 kbitsec ... The bandwidth number in Amanda has very little to do with how fast it will actually transfer data (which is confusing, to put it mildly :-). When Amanda estimates how large each dump is, it also looks at how fast they ran in the past and estimates how much bandwidth this dump will take. When driver is deciding on whether to start a new dump, it compares the estimated bandwidth plus the estimated bandwidths of all running dumps on the same "interface" (another confusing term) and will not start the dump if it would exceed the bandwidth number you've entered. But once a given dump starts, Amanda goes as fast as it can and lets the OS and hardware do any flow control. Think of the interfaces and bandwidth as another limiting factor to starting a new dump, just like holding disks and the space they have allocated. >Olivier Collet John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Backup time
Olivier Collet wrote: > > Hello, > > First I would like to thanks everybody in this mailing list. Everytime I saw such problem it was network interface full-duplex issue. What speed do you have by pulling data from the client to the backup server with regular ftp (or scp) ? > > I have a doubt. I launched the backup yesterday at 18:00 and today it is > 10:35 and it is still not done! I have put 'only' three servers in this > backup as a test. Is it normal it is so slow ? How can I tell the backup > is still going on ? > The Bandwith I put in the amanda config is 5000 kbitsec, the network is > 100 Mbits. What also is strange is I run snmp deamon on amanda server, and > I read the info in cricket, and it shows me it uses not more than 2 > Mbit/sec.Is this normal or am I missing something ? > Thanks > > regards > > Olivier Collet -- Yuri Pismerov, TUCOWS.COM INC. (416) 535-0123 ext. 1352 S/MIME Cryptographic Signature
Re: Backup time
> "Olivier" == Olivier Collet <[EMAIL PROTECTED]> writes: Olivier> I have a doubt. I launched the backup yesterday at 18:00 and today it is Olivier> 10:35 and it is still not done! I have put 'only' three servers in this Olivier> backup as a test. Is it normal it is so slow ? How can I tell the backup Olivier> is still going on ? You can run `amstatus' (see `man amstatus' for details). You might be having the same problem I did as a new Amanda user -- I was backing up the holiding disk! Check to make sure this is not the case. Ben
Re: Backup time
Olivier Is amanda doing compression? I backed up some really slow Suns and doing local compression totally killed the performance of the backup. Also the first time you do a backup of a system it does a level 0 (full) backup. Also I find its better to add one server a day to amanda so you don't end up with with a huge backup cycle at the start, but that's just my preference. -- Martin Hepworth Senior Systems Administrator Solid State Logic Ltd +44 (0)1865 842300 Olivier Collet wrote: > > Hello, > > First I would like to thanks everybody in this mailing list. > > I have a doubt. I launched the backup yesterday at 18:00 and today it is > 10:35 and it is still not done! I have put 'only' three servers in this > backup as a test. Is it normal it is so slow ? How can I tell the backup > is still going on ? > The Bandwith I put in the amanda config is 5000 kbitsec, the network is > 100 Mbits. What also is strange is I run snmp deamon on amanda server, and > I read the info in cricket, and it shows me it uses not more than 2 > Mbit/sec.Is this normal or am I missing something ? > Thanks > > regards > > Olivier Collet ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **
Re: Backup time
Euh, A lot actually. Thanks for the tips. I see what happend now. Hard to be a newbie sometimes -- Olivier Collet On Wed, 7 Mar 2001, Gerhard den Hollander wrote: > * Olivier Collet <[EMAIL PROTECTED]> (Wed, Mar 07, 2001 at 10:39:21AM >+0100) > > Hello, > > > > First I would like to thanks everybody in this mailing list. > > > > > > I have a doubt. I launched the backup yesterday at 18:00 and today it is > > 10:35 and it is still not done! I have put 'only' three servers in this > > backup as a test. Is it normal it is so slow ? How can I tell the backup > > is still going on ? > > The Bandwith I put in the amanda config is 5000 kbitsec, the network is > > 100 Mbits. What also is strange is I run snmp deamon on amanda server, and > > I read the info in cricket, and it shows me it uses not more than 2 > > Mbit/sec.Is this normal or am I missing something ? > > Thanks > > > what does amstatus yourconfig tell you (on the server) ? > > > > regards > > > > Olivier Collet > > > > > > > > > Currently listening to: 09 - The Nile Song > > Gerhard, <@jasongeo.com> == The Acoustic Motorbiker == >
Re: Backup time
* Olivier Collet <[EMAIL PROTECTED]> (Wed, Mar 07, 2001 at 10:39:21AM +0100) > Hello, > > First I would like to thanks everybody in this mailing list. > > > I have a doubt. I launched the backup yesterday at 18:00 and today it is > 10:35 and it is still not done! I have put 'only' three servers in this > backup as a test. Is it normal it is so slow ? How can I tell the backup > is still going on ? > The Bandwith I put in the amanda config is 5000 kbitsec, the network is > 100 Mbits. What also is strange is I run snmp deamon on amanda server, and > I read the info in cricket, and it shows me it uses not more than 2 > Mbit/sec.Is this normal or am I missing something ? > Thanks what does amstatus yourconfig tell you (on the server) ? > > regards > > Olivier Collet > > > > Currently listening to: 09 - The Nile Song Gerhard, <@jasongeo.com> == The Acoustic Motorbiker == -- __O If your watch is wound, wound to run, it will =`\<, If your time is due, due to come, it will (=)/(=) Living this life, is like trying to learn latin in a chines firedrill
Backup time
Hello, First I would like to thanks everybody in this mailing list. I have a doubt. I launched the backup yesterday at 18:00 and today it is 10:35 and it is still not done! I have put 'only' three servers in this backup as a test. Is it normal it is so slow ? How can I tell the backup is still going on ? The Bandwith I put in the amanda config is 5000 kbitsec, the network is 100 Mbits. What also is strange is I run snmp deamon on amanda server, and I read the info in cricket, and it shows me it uses not more than 2 Mbit/sec.Is this normal or am I missing something ? Thanks regards Olivier Collet
