Hi Marc,
I have to open this case back :-D. I found in ur script got this line:
mysqldump -u $MYSQLUSER -p$MYSQLPASSWD $DB -e -a -c --add-drop-table
--add-locks -F -l $TMPDIR/db_exports/$DB.sql
May I know if I dont want to lock all tables ( -l )and around insert
statement ( --add-locks ), can
Jon LaBadie wrote:
Amrecover, not amrestore, would be the command to extract a directory
tree from that holding disk (or tape).
If that is what you used, and you were unable to see the index of files
in the dump, was the record parameter set to yes when the dump was
made. No index is
Linda Pahdoco wrote:
Jon LaBadie wrote:
Amrecover, not amrestore, would be the command to extract a directory
tree from that holding disk (or tape).
If that is what you used, and you were unable to see the index of files
in the dump, was the record parameter set to yes when the dump was
Jean-Francois Malouin wrote:
* Jean-Louis Martineau [EMAIL PROTECTED] [20071030 10:40]:
This bug is fixed in 2.5.3alpha, but the patch was not backported to
2.5.2p1.
Can you try the attached patch?
Looks like the patch did it.
amadmin now reports correctly and amfetchdump can
Is there anyway of changing the default blocksize for writing to tape
(LTO3) from 32k to 2MB without re-compiling?
Thanks
On Thursday 01 November 2007 11:34:43 Krahn, Anderson wrote:
Is there anyway of changing the default blocksize for writing to tape
(LTO3) from 32k to 2MB without re-compiling?
Use the 'blocksize' tapetype parameter in amanda.conf.
--Ian
--
Zmanda: Open Source Backup and Recovery.
I'm manually extracting the files now based on the clues you all gave
me. I'll come back to what broke once I get the customer back up.
Thank you all for your suggestions. As usual - you're very helpful. :)
LP
I have a user who is complaining that when amanda backups are running,
the server he is access is 100% busy with gzipping the amanda backup
that it is sending to the backup server and the server is too slow for
him to do his stuff on.
I've tried to look up how to configure the client but
* Ian Turner [EMAIL PROTECTED] [20071101 10:54]:
On Thursday 01 November 2007 11:34:43 Krahn, Anderson wrote:
Is there anyway of changing the default blocksize for writing to tape
(LTO3) from 32k to 2MB without re-compiling?
Use the 'blocksize' tapetype parameter in amanda.conf.
what
Don,
The easiest way is to lower the priority of the amandad daemon that runs on
the client. If you are using xinetd, you can just add a nice entry to the
amandad service. If you are using BSD inetd, you can use the nice program;
change the command from amanda dgram udp wait
amandabackup
On Thursday 01 November 2007 13:41:46 Jean-Francois Malouin wrote:
what happens with the previously written tapes?
can they still be read?
It should not be a problem. Reading tapes with a smaller blocksize should
never cause trouble. Reading tapes with a larger blocksize than that
specified
Ok, I added:
nice= 15
to my /etc/xinetd.d/amanda configuration file and will see how that goes.
Thanks for the tip!
Don
Ian Turner wrote:
Don,
The easiest way is to lower the priority of the amandad daemon that runs on
the client. If you are using xinetd, you
How is it possible in Amanda to ensure the best network usuage?
For instance I have 2 interfaces on for qa and prd both are 100MB full.
However there are times by watching snmp graphs that our interefaces are
not fully used in fact they have peaked at 70megabits per sec. Is there
a way to tell
Krahn,
The 'interface' section in amanda.conf is one of the most frequently
misunderstood parts of Amanda configuration. The name is quite misleading,
and almost never means what people think it should.
First of all, I should start by saying that Amanda does nothing to restrict
the speed,
On Tue, Oct 30, 2007 at 12:21:32PM -0400, Chris Hoogendyk wrote:
On another backup list I monitor, there was an instance of someone who had
their system change time on October 28th. Two issues came out of this. One
is that they may have failed to patch their system for the 2007 statutory
15 matches
Mail list logo
