Re: [Bacula-users] Big problems with my Bacula.....
On Wednesday 07 September 2005 12:56, Philipp Steinkrueger wrote: > Hi Kern, > > >Perhaps it didn't drop the database but it did drop each table -- > > otherwise, how can the example from the Catalog Maintenance chapter of > > the manual work? > > > >mysqldump -f --opt bacula > bacula.sql > >mysql bacula < bacula.sql > >rm -f bacula.sql > > because of the --opt parameter in the mysqldump command which adds > drop-commands into bacula.sql which > are performed when you reinsert bacula.sql and so the tables are droped... > > >>what might have happend is the following: when you reload the database > >>by dumping it and > >>restoring it, autoincrement values may have been renumberd. usually the > >>autoincrement column > >>is defined as a key and due to this would not be allowed to be not > >> unique. > > > >Can you explain this or give an example? I don't see your point but would > >like to understand it, because a dump followed by a single restore should > >never create a condition that would cause Bacula to fail, otherwise there > > is a *big* problem. > > allright. first, this is based on speculation, because i dont have > enough time to read the bacula code. you > have to confirm or deny if the following is possible with bacula. > lets assume we have two tables. the first tables consists of two > columns, one of them is an autoincrement > column. the table would look like this after sometime: > > 324 fsdfd > 325 fsasr4g > 326 24325 > > now the other tables consists of two columns too, but there are no > autoincrement columns. the content > could look like this: > > 324 file1 > 325 file2 > 326 file3 > > if there is some relationship between the tables, lets say that the > second tables content is created based on the values > of the first tables content, then something could happend resulting in > affects described by christian. > if you dump the database and reload it into the server, there are > chances that the autoincrement values are > renumberd. i cant find a reference for that at mysql.com at the moment, > but i am pretty sure i've read > something like this and the problem is de facto discussed in severel > forums. i could not reproduce this > with my mysql 4.1 server, but perhaps its an mysql 3.2 issue, dont know. This should not happen because when you dump the tables using the options specified above (or perhaps any options), the dump that mysql creates causes the tables to be put back *exactly* as they were. It explicitly specifies the Ids it wants for each INSERT so that any references between tables remain valid. > > anyway, if the autoincrement value is renumberd and bacula is performing > some action which > creates the content of table two, it looks into table one for "fsdfd" > and picks up the > value, which used to be 324 but is 1 after the dump-reload-procedure. > now its going to insert this into the second table, but > there is allready a row with id 1, and so it will complain about > duplicate rows. Although Bacula uses autoincrement, there is nothing in the code that cares what value is used for the Id. Of course, once the Id value is returned, it may be stored in other tables, so the Id cannot change unless Bacula explicitly changes the records itself (usually simply deletes unwanted records, but unless there is a bug, it also deletes all references to those deleted records). > perhaps the unproofed assumption of renumberd autoincrement values is > not even needed. if you dump and restore > without dropping first, you could mess up the content, too, producing > relation-problems like this... If you restore without dropping first, depending how MySQL does the restore, it will either totally mess up the database (duplicating records) or reject pretty much everything in the restore -- there are some tables that don't use keys if I remember right, so those tables would be messed up. At that point, anything could happen when trying to run Bacula since the database will not be consistent from a Bacula point of view. Anyway, I hope this doesn't happen to other users. If I were sure of the problem, I would document it ... > > with this argumentation one could perhaps even try to explain why > christians problem did not rise immediatly, but after two days. > > > best regards, > philipp --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Big problems with my Bacula.....
Philipp Steinkrueger <[EMAIL PROTECTED]> wrote:
>
> if you dump the database and reload it into the server,
> there are chances that the autoincrement values are renumberd.
> i cant find a reference for that at mysql.com at the moment,
> but i am pretty sure i've read something like this and the problem is de
facto discussed in severel forums. i could not reproduce this with my
mysql 4.1 server, but perhaps its an mysql 3.2 issue, dont know.
FWIW, I have been dealing with this type of problem with
MySQL 4.0, trying to copy a table from Microsoft SQL
into MySQL using MS's DTS utility. The target table has an
auto-increment key, and MySQL will assign the next number in
the old sequence even if you do a "delete from table;" and wipe
it clean. I tried to insert a row with the auto-incremented
field's value set to 1 into the blank table after the above delete,
and that worked as expected (setting the key to 1). However, any
insert into the table that doesn't specify the value of the key
will pick up where the old key from the deleted data left off.
Since a picture is worth a thousand words, here's a picture of
table 'table1':
mysql> create table table1 (
-> key1 int(10) not null auto_increment primary key,
-> field1 char(15) not null
-> );
[Throw some data into the table.]
key1 (auto-increment) field1
--
1 One
2 Two
3 Three
mysql> delete from table1;
[We now have a blank table.]
mysql> insert into table1 values ('1','NewOne');
mysql> insert into table1 (field1) values ('NewTwo');
mysql> insert into table1 (field1) values ('NewThree');
One would expect the results to be the same as the above
table, but in reality what you get is:
key1 (auto-increment) field1
--
1 NewOne
4 NewTwo
5 NewThree
I don't know if the database restore is doing the same thing,
but my guess is that it is. The workaround is to drop the
entire table and then recreate it from scratch, which seems
to reset the auto_increment index whereas simply deleting
everything from the table doesn't.
Just figured that I'd mention it, since I was just dealing with
this unexpected MySQL 4.0 behavior working on something completely
unrelated to Bacula.
Oh, I guess that I should do an intro. I'm a new Bacula user,
who has suffered with ARCserve 9.0x on Linux for too many
years now. I'm sure that many of you know the pain of
dealing with that package, particularly the bundled Ingres
database that's nearly impossible to shut down without
total database corruption. Whoever wrote "ARGHserve" in
the Bacula web site testimonials said it all! In any case,
I'm running ARCserve for weekly tapes and disk incrementals
on about two dozen servers, and am running Bacula side-by-side
(on another server) to make second backups of a half dozen of
these systems onto a pair of LaCie 1TB USB2 disks. Once I
get Bacula tweaked and have confidence that it's working
properly, I'll install a copy of the Bacula SD onto the
ARCserve box and liberate the tape changer as the last
step of freeing ourselves from CA's pile of toss software.
-Arthur
-
Arthur Emerson III Email: [EMAIL PROTECTED]
Network Administrator InterNIC: AE81
Mount Saint Mary College MaBell: (845) 561-0800 Ext. 3109
330 Powell Ave.Fax:(845) 562-6762
Newburgh, NY 12550SneakerNet: Aquinas Hall Room 13
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Big problems with my Bacula.....
Hello, Am 07.09.2005 schrieb Philipp Steinkrueger: > Hi Kern, > > > >Perhaps it didn't drop the database but it did drop each table -- > >otherwise, how can the example from the Catalog Maintenance chapter of the > >manual work? > > > >mysqldump -f --opt bacula > bacula.sql > >mysql bacula < bacula.sql > >rm -f bacula.sql > > > > > > > because of the --opt parameter in the mysqldump command which adds > drop-commands into bacula.sql which > are performed when you reinsert bacula.sql and so the tables are droped... > > >>what might have happend is the following: when you reload the database > >>by dumping it and > >>restoring it, autoincrement values may have been renumberd. usually the > >>autoincrement column > >>is defined as a key and due to this would not be allowed to be not unique. > >> > >> > > > >Can you explain this or give an example? I don't see your point but would > >like to understand it, because a dump followed by a single restore should > >never create a condition that would cause Bacula to fail, otherwise there > >is a *big* problem. > > > > > > > allright. first, this is based on speculation, because i dont have > enough time to read the bacula code. you > have to confirm or deny if the following is possible with bacula. > lets assume we have two tables. the first tables consists of two > columns, one of them is an autoincrement > column. the table would look like this after sometime: > > 324 fsdfd > 325 fsasr4g > 326 24325 > > now the other tables consists of two columns too, but there are no > autoincrement columns. the content > could look like this: > > 324 file1 > 325 file2 > 326 file3 > > if there is some relationship between the tables, lets say that the > second tables content is created based on the values > of the first tables content, then something could happend resulting in > affects described by christian. > if you dump the database and reload it into the server, there are > chances that the autoincrement values are > renumberd. i cant find a reference for that at mysql.com at the moment, > but i am pretty sure i've read > something like this and the problem is de facto discussed in severel > forums. i could not reproduce this > with my mysql 4.1 server, but perhaps its an mysql 3.2 issue, dont know. > > anyway, if the autoincrement value is renumberd and bacula is performing > some action which > creates the content of table two, it looks into table one for "fsdfd" > and picks up the > value, which used to be 324 but is 1 after the dump-reload-procedure. > now its going to insert this into the second table, but > there is allready a row with id 1, and so it will complain about > duplicate rows. > perhaps the unproofed assumption of renumberd autoincrement values is > not even needed. if you dump and restore > without dropping first, you could mess up the content, too, producing > relation-problems like this... Very nice explanation - but you're wrong. I just made a "mysqldump bacula File -p > bacula-file.sql". when you check "describe File", you'll see that "FileId" is "auto_increment". When you check the dump, that column "FileId" is also set. "auto_increment" is only used, if you INSERT a dataset WITHOUT any value for the column "FileId". But you can set a value on your own explicitely. > with this argumentation one could perhaps even try to explain why > christians problem did not rise immediatly, but after two days. Greets, Thomas --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Big problems with my Bacula.....
Hi Kern, Perhaps it didn't drop the database but it did drop each table -- otherwise, how can the example from the Catalog Maintenance chapter of the manual work? mysqldump -f --opt bacula > bacula.sql mysql bacula < bacula.sql rm -f bacula.sql because of the --opt parameter in the mysqldump command which adds drop-commands into bacula.sql which are performed when you reinsert bacula.sql and so the tables are droped... what might have happend is the following: when you reload the database by dumping it and restoring it, autoincrement values may have been renumberd. usually the autoincrement column is defined as a key and due to this would not be allowed to be not unique. Can you explain this or give an example? I don't see your point but would like to understand it, because a dump followed by a single restore should never create a condition that would cause Bacula to fail, otherwise there is a *big* problem. allright. first, this is based on speculation, because i dont have enough time to read the bacula code. you have to confirm or deny if the following is possible with bacula. lets assume we have two tables. the first tables consists of two columns, one of them is an autoincrement column. the table would look like this after sometime: 324 fsdfd 325 fsasr4g 326 24325 now the other tables consists of two columns too, but there are no autoincrement columns. the content could look like this: 324 file1 325 file2 326 file3 if there is some relationship between the tables, lets say that the second tables content is created based on the values of the first tables content, then something could happend resulting in affects described by christian. if you dump the database and reload it into the server, there are chances that the autoincrement values are renumberd. i cant find a reference for that at mysql.com at the moment, but i am pretty sure i've read something like this and the problem is de facto discussed in severel forums. i could not reproduce this with my mysql 4.1 server, but perhaps its an mysql 3.2 issue, dont know. anyway, if the autoincrement value is renumberd and bacula is performing some action which creates the content of table two, it looks into table one for "fsdfd" and picks up the value, which used to be 324 but is 1 after the dump-reload-procedure. now its going to insert this into the second table, but there is allready a row with id 1, and so it will complain about duplicate rows. perhaps the unproofed assumption of renumberd autoincrement values is not even needed. if you dump and restore without dropping first, you could mess up the content, too, producing relation-problems like this... with this argumentation one could perhaps even try to explain why christians problem did not rise immediatly, but after two days. best regards, philipp --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Big problems with my Bacula.....
On Tuesday 06 September 2005 17:26, Philipp Steinkrueger wrote: > Hi, > > Kern wrote: > > Hmmm. It looks like MySQL may have changed the behavior of their > > dump/restore, > > > which used to delete everything before doing a restore. If you did not > > explicitly delete your database before doing the restore, you probably > > unknowingly duplicated all the records -- not very good. > > afaik it was never a default to drop the database automatically before > inserting a dump, Perhaps it didn't drop the database but it did drop each table -- otherwise, how can the example from the Catalog Maintenance chapter of the manual work? mysqldump -f --opt bacula > bacula.sql mysql bacula < bacula.sql rm -f bacula.sql I'm sure that worked because I tried it before writing the chapter. If it doesn't drop the tables, then it must be very cleaver about the inserts. > but > anyway i dont think that this really happend, because he writes that > bacula is complaining about > duplicate entries which means that bacula wants to insert something and > that would be a duplicate. Yes, I cannot argue this point as I am not really sure what is going on because Christian did not show the actual error message. Bacula does not care if there are duplicate entries in the File table, as far as I remember, and when it does insert an entry in that table, the FileId of NULL is used. > if he had duplicated the content of the database when i inserted the > dump again, then mysql would > have complained during the restore of the dump. this happend to me for > dozens of time, i am sure > and thats why i am pretty sure that automatic dropping of database was > never a default. > > what might have happend is the following: when you reload the database > by dumping it and > restoring it, autoincrement values may have been renumberd. usually the > autoincrement column > is defined as a key and due to this would not be allowed to be not unique. Can you explain this or give an example? I don't see your point but would like to understand it, because a dump followed by a single restore should never create a condition that would cause Bacula to fail, otherwise there is a *big* problem. Best regards, Kern --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Big problems with my Bacula.....
Hi, Kern wrote: > Hmmm. It looks like MySQL may have changed the behavior of their dump/restore, > which used to delete everything before doing a restore. If you did not > explicitly delete your database before doing the restore, you probably > unknowingly duplicated all the records -- not very good. afaik it was never a default to drop the database automatically before inserting a dump, but anyway i dont think that this really happend, because he writes that bacula is complaining about duplicate entries which means that bacula wants to insert something and that would be a duplicate. if he had duplicated the content of the database when i inserted the dump again, then mysql would have complained during the restore of the dump. this happend to me for dozens of time, i am sure and thats why i am pretty sure that automatic dropping of database was never a default. what might have happend is the following: when you reload the database by dumping it and restoring it, autoincrement values may have been renumberd. usually the autoincrement column is defined as a key and due to this would not be allowed to be not unique. regards, philipp --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Big problems with my Bacula.....
Kern Sibbald wrote:
> On Tuesday 06 September 2005 08:49, Masopust Christian wrote:
>>Hello all,
>>Bacula run fine till last weekend. Since Sunday every job fails with
>>messages that entries to database ("INSERT INTO FILE (..") could not be
>>made because of "Duplicate entries"
>>
>>First i thought that i caused this problem myself as i run a "mysqldump" of
>>the whole bacual-db last week and after that i reloaded id (maybe dumb, but
>>i heard that this could decrease size of db a little as mine is above 8GB).
>
> Hmmm. It looks like MySQL may have changed the behavior of their
> dump/restore,
> which used to delete everything before doing a restore. If you did not
> explicitly delete your database before doing the restore, you probably
> unknowingly duplicated all the records -- not very good.
Unless I'm missing something, there is no mysqlrestore utility, and if
loading a dump into mysql has ever cleared the database first, it's news
to me.
Even using the deprecated BACKUP TABLE and RESTORE TABLE commands, which
work only on MyISAM tables, a RESTORE TABLE will fail if the table
already contains data (or, I think, if it exists at all).
That said, inserting a row that already exists but has a unique primary
key SHOULD fail rather than creating a duplicate row.
--
Phil Stracchino [EMAIL PROTECTED]
Renaissance Man, Unix generalist, Perl hacker
Mobile: 603-216-7037 Landline: 603-886-3518
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Big problems with my Bacula.....
On Tuesday 06 September 2005 08:49, Masopust Christian wrote:
> Hello all,
>
> my configuration is as follows:
>
> - Director and Storage at FedoraCore 3 system, Database Mysql 4.1.12,
>Backup to Disk (2 RAIDs with 2.6TB)
> - Clients are Linux, SUNs, Windows
>
> Bacula run fine till last weekend. Since Sunday every job fails with
> messages that entries to database ("INSERT INTO FILE (..") could not be
> made because of "Duplicate entries"
>
> First i thought that i caused this problem myself as i run a "mysqldump" of
> the whole bacual-db last week and after that i reloaded id (maybe dumb, but
> i heard that this could decrease size of db a little as mine is above 8GB).
>
> But i couldn't imagine that this causes my problems now because backup runs
> fine after the dump-reload for 2 days...
>
> so, any idea what happening here?
Hmmm. It looks like MySQL may have changed the behavior of their dump/restore,
which used to delete everything before doing a restore. If you did not
explicitly delete your database before doing the restore, you probably
unknowingly duplicated all the records -- not very good.
Your best bet is probably to make a copy of what you currently have (just as a
safeguard) and then delete the database and re-create it with the mysqldump
you have. Hopefully that should get things working again with the least
effort and loss of data.
>
> thanks a lot,
> chris
>
> P.S.: btw, would it be better to have more catalogs when size of 1 catalog
> is as big is mine is?
It is hard to say if it would be better or not to have multiple databases.
Bacula should handle it quite fine -- with the one caveat that when you use
bconsole, you will have to explicitly tell it what database you want to work
with -- this can be a bit more to remember. You also need to be careful to
back all the databases up. Whether or not the extra administrative effort is
justified by possibly faster access, I don't know. If you do this, I
recommend starting with one small second database and experiment with backup,
restore, and queries until you are really sure you know what you are getting
into.
Kern
>
>
>
> ---
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Big problems with my Bacula.....
Hello,
Am 06.09.2005 schrieb Arno Lehmann:
> Hi,
>
> Masopust Christian wrote:
>
> >Hello all,
> >
> >my configuration is as follows:
> >
> > - Director and Storage at FedoraCore 3 system, Database Mysql 4.1.12,
> > Backup to Disk (2 RAIDs with 2.6TB)
> > - Clients are Linux, SUNs, Windows
> >
> >Bacula run fine till last weekend. Since Sunday every job fails with
> >messages
> >that entries to database ("INSERT INTO FILE (..") could not be made
> >because
> >of "Duplicate entries"
>
> So the catalog is broken. Bad, but you should be able to correct it...
>
> >First i thought that i caused this problem myself as i run a "mysqldump" of
> >the whole bacual-db last week and after that i reloaded id (maybe dumb,
> >but i
> >heard that this could decrease size of db a little as mine is above 8GB).
>
> I don't know if this is necessary or useful, but that might have caused
> the problems.
It is sometimes necessary, that the database should be compacted some
day. I do it sometimes - but I realized, that I only get a few megabytes
in free space after re-importing the mysqldump-ed database then.
> >But i couldn't imagine that this causes my problems now because backup
> >runs fine
> >after the dump-reload for 2 days...
> >
> >so, any idea what happening here?
>
> Have you tried the dbcheck program to repair the database?
> I suggest to make sure that bacula is not running when you modify the
> database.
>
> Be aware that the database check ca take very long.
>
> You could also start with a new, completely empty catalog, and reinsert
> your existing volumes using bscan.
>
>
> >thanks a lot,
> >chris
> >
> >P.S.: btw, would it be better to have more catalogs when size of 1 catalog
> >is
> > as big is mine is?
> >
>
> I don't know, but I'm quite sure that using more than one catalog can
> result in some difficulties with you bacula setup.
The only thing what can be done to reduce the size of the database, is
using the "right" values for "Volume Retention", "File Retention" and
"Job Retention". For example, if you make a weekly change backup with 4
pools, why should be e.g. "Volume Retention" bigger than 28? Any higher
value is for nothing, because the tapes are already overwritten and you
cant get the data, so why storing volume information of data, which you
do not have anymore?
The same with "File -" and "Job Retention". Why store information about
jobs and files which cant be restored, 'cos the tapes have been already
overwritten?
Dont be to aggressive in this values - that you dont abolish datasets
which are still required.
If you adapt these values for your needs - look in the manual - you can
compact the database automatically.
One second reason is, that you maybe backup directories with a LOTS of
files - which obviously needs also a lots of entries in the database.
Check it, maybe you backup a news-dir (would be really crazy) or any
other dir, which contains a lots of files and does not have to be
backuped.
Another issue can be, that you use sqllite maybe - but I read that you
dump it with mysqldump. This idea is only for showing possible reasons
for it. ;-)) Dont beat me.
HTH,
Thomas
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Big problems with my Bacula.....
Hi,
Masopust Christian wrote:
Hello all,
my configuration is as follows:
- Director and Storage at FedoraCore 3 system, Database Mysql 4.1.12,
Backup to Disk (2 RAIDs with 2.6TB)
- Clients are Linux, SUNs, Windows
Bacula run fine till last weekend. Since Sunday every job fails with messages
that entries to database ("INSERT INTO FILE (..") could not be made because
of "Duplicate entries"
So the catalog is broken. Bad, but you should be able to correct it...
First i thought that i caused this problem myself as i run a "mysqldump" of
the whole bacual-db last week and after that i reloaded id (maybe dumb, but i
heard that this could decrease size of db a little as mine is above 8GB).
I don't know if this is necessary or useful, but that might have caused
the problems.
But i couldn't imagine that this causes my problems now because backup runs fine
after the dump-reload for 2 days...
so, any idea what happening here?
Have you tried the dbcheck program to repair the database?
I suggest to make sure that bacula is not running when you modify the
database.
Be aware that the database check ca take very long.
You could also start with a new, completely empty catalog, and reinsert
your existing volumes using bscan.
thanks a lot,
chris
P.S.: btw, would it be better to have more catalogs when size of 1 catalog is
as big is mine is?
I don't know, but I'm quite sure that using more than one catalog can
result in some difficulties with you bacula setup.
Arno
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
--
IT-Service Lehmann[EMAIL PROTECTED]
Arno Lehmann http://www.its-lehmann.de
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
