SearchFAQMemberlist Log in
Reply to topic Page 1 of 1
damaged database (was Re: possible bug found)
Author Message
Post damaged database (was Re: possible bug found) 
Hi All,
Kern is right... I should have never changed those MediaIds... I
actually remember changing a few other things such as renaming the
Default pool to Weekly and resetting the auto_increment value on Media
and Pool tables. I also remember changing something about PoolId. In
hind-sight, I don't know what I was thinking (probably just being too
picky as always)... It sounds like I hosed my database. I am so worried
about this... Is there anyway to restore my database? Btw, these changes
were made when I originally setup bacula... So, I cannot just restore
the database from a previous dumpfile... The only way that I can forsee
restoring the database is to do the following:

1) backup the current database to a dumpfile
2) drop the current database
3) recreate the database using the initial bacula sql scripts provided
with the distribution
4) bscan in all of my tapes

... Am I wrong? I hope so, because this sounds like a grueling
process... Basically, is there a better way to fix my database, such as
using some sql-hackery?

My setup is:
MySQL 4.1.20-1
Bacula 2.0.1 (Current Pools=Weekly, Scratch, Migrate, Archive)
RHEL 4 AS

Regards,
Mike

Kern Sibbald wrote:
On Thursday 15 March 2007 04:38, maseda < at > un... wrote:

Upon running a migration job, bacula asked me to load one of my
cleaning tapes... Then, I updated the MediaId in the Media table to
correspond with the tape that bacula should have been looking for...
This caused bacula to successfully complete the migration job...I think
bacula should have been looking for a specific VolumeName *not*
MediaId... I like bacula, but this is just wrong... Btw, this problem
occured because I changed some of my MediaIds a while back (I can't
help it sql is fun and I'm a control freak Very Happy)... But still, i think
bacula should have asked me to load tape "MSR100L3" or whatever... Ya
know?


If you modified a MediaId in the Media table and you don't understand the full
details of how the database is organized and linked together (e.g. where to
find *all* references to the MediaId), you have probably damaged your
database.

While certain fields can be modified directly via SQL, MediaIds are not one.
For the record, I discourage all users from doing similar things, and I can
assure you, it is not something that I would personally do.

To the best of my knowledge the only place Bacula ever asks for a MediaId is
when it asks you to select a particular Volume during the update command (and
possibly some other ones).

If you decide to respond to this with a bit more concrete information, please
read the Support page on the bacula web site (www.bacula.org -> Support)
first.



Post damaged database (was Re: possible bug found) 
Ok.. I have found all references to MediaId... The following sql
statements were executed:
select MediaId, JobId from JobMedia;
select MediaId from Media;
select MediaId from CDImages;
select MediaId from LocationLog;

Since I also changed PoolId, I did:
select PoolId from Pool;
select PoolId from Job;
select PoolId from Media;
select PoolId,JobId from Job;

I will search through the output of these commands and see if I can
bring the database back to a sane state... Am I on the right track?
Thx,
M

Mike Seda wrote:
Hi All,
Kern is right... I should have never changed those MediaIds... I
actually remember changing a few other things such as renaming the
Default pool to Weekly and resetting the auto_increment value on Media
and Pool tables. I also remember changing something about PoolId. In
hind-sight, I don't know what I was thinking (probably just being too
picky as always)... It sounds like I hosed my database. I am so worried
about this... Is there anyway to restore my database? Btw, these changes
were made when I originally setup bacula... So, I cannot just restore
the database from a previous dumpfile... The only way that I can forsee
restoring the database is to do the following:

1) backup the current database to a dumpfile
2) drop the current database
3) recreate the database using the initial bacula sql scripts provided
with the distribution
4) bscan in all of my tapes

... Am I wrong? I hope so, because this sounds like a grueling
process... Basically, is there a better way to fix my database, such as
using some sql-hackery?

My setup is:
MySQL 4.1.20-1
Bacula 2.0.1 (Current Pools=Weekly, Scratch, Migrate, Archive)
RHEL 4 AS

Regards,
Mike


Kern Sibbald wrote:

On Thursday 15 March 2007 04:38, maseda < at > un... wrote:


Upon running a migration job, bacula asked me to load one of my
cleaning tapes... Then, I updated the MediaId in the Media table to
correspond with the tape that bacula should have been looking for...
This caused bacula to successfully complete the migration job...I think
bacula should have been looking for a specific VolumeName *not*
MediaId... I like bacula, but this is just wrong... Btw, this problem
occured because I changed some of my MediaIds a while back (I can't
help it sql is fun and I'm a control freak Very Happy)... But still, i think
bacula should have asked me to load tape "MSR100L3" or whatever... Ya
know?


If you modified a MediaId in the Media table and you don't understand the full
details of how the database is organized and linked together (e.g. where to
find *all* references to the MediaId), you have probably damaged your
database.

While certain fields can be modified directly via SQL, MediaIds are not one.
For the record, I discourage all users from doing similar things, and I can
assure you, it is not something that I would personally do.

To the best of my knowledge the only place Bacula ever asks for a MediaId is
when it asks you to select a particular Volume during the update command (and
possibly some other ones).

If you decide to respond to this with a bit more concrete information, please
read the Support page on the bacula web site (www.bacula.org -> Support)
first.





-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users


Post damaged database (was Re: possible bug found) 
On Thursday 15 March 2007 16:17, Mike Seda wrote:
Ok.. I have found all references to MediaId... The following sql
statements were executed:
select MediaId, JobId from JobMedia;
select MediaId from Media;
select MediaId from CDImages;
select MediaId from LocationLog;

Since I also changed PoolId, I did:
select PoolId from Pool;
select PoolId from Job;
select PoolId from Media;
select PoolId,JobId from Job;

I will search through the output of these commands and see if I can
bring the database back to a sane state... Am I on the right track?

Judging by your previous email, the database is probably in a very
inconsistent state, as you have mentioned. Unless you remember *exactly* all
the changes that you made, it will be very difficult to properly undo them.

My personal approach would probably be to go the conservative route:

1. Make a listing of all the Volumes and Jobs in the current database for
future reference.
2. Save an "archival" copy of the current database.
3. Create a new clean database,
4. Add new Volumes to the new database
5. Do a Full backup of everything.

Then hope you don't need anything from the old database.

If you do need something from the old database, there are several
possibilities:
1. Temporarily restore the old database, and attempt a restore crossing your
fingers.
2. If the above fails, attempt to manually reset the mediaIds in the old
temporarily restored database as you propose doing (I personally wouldn't do
this).
3. Scan in the needed volumes into the new "clean" database -- terribly time
consuming.

At some point manually recycle the old Volumes when they would have been
automatically recycled, and start re-using them in the new catalog.

Good luck.

Kern

Thx,
M

Mike Seda wrote:
Hi All,
Kern is right... I should have never changed those MediaIds... I
actually remember changing a few other things such as renaming the
Default pool to Weekly and resetting the auto_increment value on Media
and Pool tables. I also remember changing something about PoolId. In
hind-sight, I don't know what I was thinking (probably just being too
picky as always)... It sounds like I hosed my database. I am so worried
about this... Is there anyway to restore my database? Btw, these changes
were made when I originally setup bacula... So, I cannot just restore
the database from a previous dumpfile... The only way that I can forsee
restoring the database is to do the following:

1) backup the current database to a dumpfile
2) drop the current database
3) recreate the database using the initial bacula sql scripts provided
with the distribution
4) bscan in all of my tapes

... Am I wrong? I hope so, because this sounds like a grueling
process... Basically, is there a better way to fix my database, such as
using some sql-hackery?

My setup is:
MySQL 4.1.20-1
Bacula 2.0.1 (Current Pools=Weekly, Scratch, Migrate, Archive)
RHEL 4 AS

Regards,
Mike

Kern Sibbald wrote:
On Thursday 15 March 2007 04:38, maseda < at > un... wrote:
Upon running a migration job, bacula asked me to load one of my
cleaning tapes... Then, I updated the MediaId in the Media table to
correspond with the tape that bacula should have been looking for...
This caused bacula to successfully complete the migration job...I think
bacula should have been looking for a specific VolumeName *not*
MediaId... I like bacula, but this is just wrong... Btw, this problem
occured because I changed some of my MediaIds a while back (I can't
help it sql is fun and I'm a control freak Very Happy)... But still, i think
bacula should have asked me to load tape "MSR100L3" or whatever... Ya
know?

If you modified a MediaId in the Media table and you don't understand
the full details of how the database is organized and linked together
(e.g. where to find *all* references to the MediaId), you have probably
damaged your database.

While certain fields can be modified directly via SQL, MediaIds are not
one. For the record, I discourage all users from doing similar things,
and I can assure you, it is not something that I would personally do.

To the best of my knowledge the only place Bacula ever asks for a
MediaId is when it asks you to select a particular Volume during the
update command (and possibly some other ones).

If you decide to respond to this with a bit more concrete information,
please read the Support page on the bacula web site (www.bacula.org ->
Support) first.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users

Post damaged database (was Re: possible bug found) 
Hi Kern,
Thanks for these tips... I didn't see them until just now... I actually
fixed the database already based on documented changes that I had stored
in my Wiki and bacula emails (containing JobId and VolumeName)... I
verified the changes by doing a few restores and the aforementioned
double migration jobs (that seemed to be the ultimate test)... I learned
my lesson... Your support has been above and beyond the call of duty...
You (and the entire bacula community) are great... Cool Btw, I have
turned on Binary Logging in MySQL so that I can replay the logs in the
future.
Thx,
Mike

Kern Sibbald wrote:
On Thursday 15 March 2007 16:17, Mike Seda wrote:

Ok.. I have found all references to MediaId... The following sql
statements were executed:
select MediaId, JobId from JobMedia;
select MediaId from Media;
select MediaId from CDImages;
select MediaId from LocationLog;

Since I also changed PoolId, I did:
select PoolId from Pool;
select PoolId from Job;
select PoolId from Media;
select PoolId,JobId from Job;

I will search through the output of these commands and see if I can
bring the database back to a sane state... Am I on the right track?


Judging by your previous email, the database is probably in a very
inconsistent state, as you have mentioned. Unless you remember *exactly* all
the changes that you made, it will be very difficult to properly undo them.

My personal approach would probably be to go the conservative route:

1. Make a listing of all the Volumes and Jobs in the current database for
future reference.
2. Save an "archival" copy of the current database.
3. Create a new clean database,
4. Add new Volumes to the new database
5. Do a Full backup of everything.

Then hope you don't need anything from the old database.

If you do need something from the old database, there are several
possibilities:
1. Temporarily restore the old database, and attempt a restore crossing your
fingers.
2. If the above fails, attempt to manually reset the mediaIds in the old
temporarily restored database as you propose doing (I personally wouldn't do
this).
3. Scan in the needed volumes into the new "clean" database -- terribly time
consuming.

At some point manually recycle the old Volumes when they would have been
automatically recycled, and start re-using them in the new catalog.

Good luck.

Kern




Thx,
M

Mike Seda wrote:

Hi All,
Kern is right... I should have never changed those MediaIds... I
actually remember changing a few other things such as renaming the
Default pool to Weekly and resetting the auto_increment value on Media
and Pool tables. I also remember changing something about PoolId. In
hind-sight, I don't know what I was thinking (probably just being too
picky as always)... It sounds like I hosed my database. I am so worried
about this... Is there anyway to restore my database? Btw, these changes
were made when I originally setup bacula... So, I cannot just restore
the database from a previous dumpfile... The only way that I can forsee
restoring the database is to do the following:

1) backup the current database to a dumpfile
2) drop the current database
3) recreate the database using the initial bacula sql scripts provided
with the distribution
4) bscan in all of my tapes

... Am I wrong? I hope so, because this sounds like a grueling
process... Basically, is there a better way to fix my database, such as
using some sql-hackery?

My setup is:
MySQL 4.1.20-1
Bacula 2.0.1 (Current Pools=Weekly, Scratch, Migrate, Archive)
RHEL 4 AS

Regards,
Mike

Kern Sibbald wrote:

On Thursday 15 March 2007 04:38, maseda < at > un... wrote:

Upon running a migration job, bacula asked me to load one of my
cleaning tapes... Then, I updated the MediaId in the Media table to
correspond with the tape that bacula should have been looking for...
This caused bacula to successfully complete the migration job...I think
bacula should have been looking for a specific VolumeName *not*
MediaId... I like bacula, but this is just wrong... Btw, this problem
occured because I changed some of my MediaIds a while back (I can't
help it sql is fun and I'm a control freak Very Happy)... But still, i think
bacula should have asked me to load tape "MSR100L3" or whatever... Ya
know?

If you modified a MediaId in the Media table and you don't understand
the full details of how the database is organized and linked together
(e.g. where to find *all* references to the MediaId), you have probably
damaged your database.

While certain fields can be modified directly via SQL, MediaIds are not
one. For the record, I discourage all users from doing similar things,
and I can assure you, it is not something that I would personally do.

To the best of my knowledge the only place Bacula ever asks for a
MediaId is when it asks you to select a particular Volume during the
update command (and possibly some other ones).

If you decide to respond to this with a bit more concrete information,
please read the Support page on the bacula web site (www.bacula.org ->
Support) first.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users


Display posts from previous:
Reply to topic Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
  


Magic SEO URL for phpBB