Ah, I see you found the solution...
On 9/1/2006 12:47 AM, Arunav Mandal wrote:
> Probally while creating database at first we should have used MAX_ROWS and
> AVG_ROW_LENGTH options.
probably... any real-life values for AVG_ROW_LENGTH? I offer 111...
Arno
>
> http://jeremy.zawodny.com/blog/arc
On Friday 01 September 2006 00:51, Marco wrote:
> Just an idea:
>
> I did not build v1.38.11 and v1.38.8 myself but installed the debian
> packages. During the downgrade I noticed that there were changes concerning
> sqlite and sqlite3. I have not take a closer look on this because I don't
> under
Now it is at Avg_row_length: 105. Anyway the file tends to get huge last
time it went up to 18G.
Arunav.
- Original Message -
From: "Arno Lehmann" <[EMAIL PROTECTED]>
To:
Sent: Friday, September 01, 2006 12:58 AM
Subject: Re: [Bacula-users] Mysql tables 'File' is full new mail
> Ah,
Ah, I see you found the solution...
On 9/1/2006 12:47 AM, Arunav Mandal wrote:
> Probally while creating database at first we should have used MAX_ROWS and
> AVG_ROW_LENGTH options.
probably... any real-life values for AVG_ROW_LENGTH? I offer 111...
Arno
>
> http://jeremy.zawodny.com/blog/arc
Hello,
On 9/1/2006 12:51 AM, Marco wrote:
> Just an idea:
>
> I did not build v1.38.11 and v1.38.8 myself but installed the debian
> packages. During the downgrade I noticed that there were changes concerning
> sqlite and sqlite3. I have not take a closer look on this because I don't
> understand
Just an idea:
I did not build v1.38.11 and v1.38.8 myself but installed the debian
packages. During the downgrade I noticed that there were changes concerning
sqlite and sqlite3. I have not take a closer look on this because I don't
understand much about it anyway. But maybe you could check whethe
Probally while creating database at first we should have used MAX_ROWS and
AVG_ROW_LENGTH options.
http://jeremy.zawodny.com/blog/archives/000796.html
Arunav.
- Original Message -
From: "Arunav Mandal" <[EMAIL PROTECTED]>
To: "Arunav Mandal" <[EMAIL PROTECTED]>;
Sent: Friday, Septe
I am altering the table now with
alter table File max_rows = 2000;
Some backups failed I guess other old backups are safe.
Arunav.
- Original Message -
From: "Arunav Mandal" <[EMAIL PROTECTED]>
To:
Sent: Friday, September 01, 2006 12:34 AM
Subject: [Bacula-users] Mysql tables
Kern Sibbald wrote:
> On Thursday 31 August 2006 19:49, Marco wrote:
>> Maybe that helps:
>
> Yes, I can now see what you are complaining about. I would like to see a
> second Full save on version 1.38.11 to exclude the possibility that some
> other process was hogging your machine. I would also
I am getting some errors now like this
01-Sep 00:26 bacula-dir: sql_create.c:732 INSERT INTO File
(FileIndex,JobId,PathId,FilenameId,LStat,MD5) VALUES (3,179,14,34,'MC EGi
EHJ C E H A BAA BAA I BE9gKM BE91M9 BE91M9 A A C','0')
01-Sep 00:26 bacula-dir: backup-pip.2006-09-01_00.24.02 Fatal error:
sq
I am getting some errors now like this
01-Sep 00:26 bacula-dir: sql_create.c:732 INSERT INTO File
(FileIndex,JobId,PathId,FilenameId,LStat,MD5) VALUES (3,179,14,34,'MC EGi
EHJ C E H A BAA BAA I BE9gKM BE91M9 BE91M9 A A C','0')
01-Sep 00:26 bacula-dir: backup-pip.2006-09-01_00.24.02 Fatal error:
I´m editing DirStartUp.py.
I want to write a script that can check if the
termination job was:
Termination: Backup OK -- with warnings
I capture this:
if job.JobStatus == "e":
job.JobReport="Non-fatal Error\n"
elif job.JobStatus == "E":
job.JobReport="Termited with erro
First: Sorry for the trouble I made by posting it to the bugtracker.
Then.
Item 1: Filesystemwatch triggered backup.
Date: 31 August 2006
Origin: Jesper Krogh <[EMAIL PROTECTED]>
Status: Unimplemented, depends probably on "client initiated backups"
What: With inotify and similar fi
On Thursday 31 August 2006 19:49, Marco wrote:
> Maybe that helps:
Yes, I can now see what you are complaining about. I would like to see a
second Full save on version 1.38.11 to exclude the possibility that some
other process was hogging your machine. I would also like to see a Full
backup ma
Maybe that helps:
1-Aug 16:26 server1-dir: Bacula 1.38.8 (14Apr06): 31-Aug-2006 16:26:48
JobId: 1
Job:Server.2006-08-31_14.59.55
Backup Level: Full
Client: "server-fd"
i486-pc-linux-gnu,debian,testing/unstable
FileSet:
Kern Sibbald wrote:
> Unfortunately, I don't have enough information to answer this question.
> I've read that some people are having performance problems with the Win32
> version, but I haven't seen any hard data comparing equal filesets before
> and after (or after upgrade and then after downgr
On Thursday 31 August 2006 17:28, Marco wrote:
> Hello,
>
> I was very disappointed about the performance of backups after upgrading
> from 1.38.5 to 1.38.11. The rates dropped to 10% of before.
>
> After downgrading to 1.38.8 the performance is good again.
>
> In which version was the change?
>
Did you upgrade and downgrade every agent?
ZK
--- Marco <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I was very disappointed about the performance of
> backups after upgrading
> from 1.38.5 to 1.38.11. The rates dropped to 10% of
> before.
>
> After downgrading to 1.38.8 the performance is good
On Thursday 31 August 2006 16:55, Jeffrey L. Taylor wrote:
> I am trying to move from 1.38.11 to 1.39.20 and found a MySQL schema
> version mismatch. Is there a update_mysql_tables_9_to_10 script
> planned?
A script with that name will be published *after* the release. At the current
time, and
Hello,
I was very disappointed about the performance of backups after upgrading
from 1.38.5 to 1.38.11. The rates dropped to 10% of before.
After downgrading to 1.38.8 the performance is good again.
In which version was the change?
Can we expect the former performance for future versions?
Rega
>John Drescher wrote:
>
> > Are you sure that the new database is indexed properly? Does it take
> > an unreasonably long time to generate the file list for a restore?
If
> > so this is a sign that the database needs indexed.
>
> The restore time is quite ok. It's the backup that takes extremely
Hi all,
I am testing a short job retention period (minutes) on a client, but
only incremental jobs are being removed when I prune, the full jobs
remain. This is the same whether the prune is done manually in the
console or automatically at the end of a job. I get this in my
production setup whi
And is also listed in http://www.k12opensource.com/ under Programs ->
Backing Up Data :-)
On 8/29/06, Bill Moran <[EMAIL PROTECTED]> wrote:
> In response to "Dan Langille" <[EMAIL PROTECTED]>:
>
> > In this article: http://www.ecommercetimes.com/story/52670.html only
> > two applications are ment
I am trying to move from 1.38.11 to 1.39.20 and found a MySQL schema
version mismatch. Is there a update_mysql_tables_9_to_10 script
planned?
TIA,
Jeffrey
-
Using Tomcat but need to do more? Need to support web services, s
Hi all,
(Apologies if this is a duplicate, my first post
didn't come through.)
I am testing a short job retention period (minutes) on
a client, but only incremental jobs are being removed
when I prune, the full jobs remain. This is the same
whether the prune is done manually in the console or
aut
I haven't seen such a situation before, but I think
you can do it like this:
1. Back up as you always do.
2. After the job is done, dump the catalog from
database to disk.
3. Write the dumped catalog to two CDs/DVDs (you keep
one, the customer keeps the other) and store them
properly. Testing it o
On 31 Aug 2006 at 11:33, Alexander Pfeiffer wrote:
> Hi List,
>
> we've to plan a backup, which cause some "headache"...
>
> To backup 2 TB of data. The data/tapes should be available for 15 years.
Include in the plan, tape verification and/or migration. Two
reasons: software changes, so you
Hi List,
we've to plan a backup, which cause some "headache"...
To backup 2 TB of data. The data/tapes should be available for 15 years.
Full backup every sunday, inc daily.
In my opion it' s no good idea to set the retention time to 15 years.
That will blow up the database and will "kill" th
28 matches
Mail list logo
