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.
> > 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,
--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
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.
bis 15.8. bin ich nicht erreichbar. in dringenden fällen senden sie ihre
nachricht bitte an mailto:[EMAIL PROTECTED], vielen dank.
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 shu
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 ma
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 tap
> 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.
> 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
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.co
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
$ am
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 p
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
> 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 acce
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 B
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 U
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 c
>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 a
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 ha
> "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
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
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
* 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 server
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
25 matches
Mail list logo
